Better Headless with Magnolia

There are a lot of headless CMS out there, and they are good at what they do. They are fast to set up and do straightforward API integrations with modern frontend technology.

But Magnolia stands out simply because it's just so much more than a typical headless CMS. It's actually a headless DXP.

2023 was a fascinating year in the headless CMS space – it was the year of the visual page editing experience. On my radar, Contentful, Builder, Netlify, Vercel, and Uniform all made plays in this space. Remember when headless CMS originally came on the scene back in 2013 or so, the mantra was "separation of content and presentation", and COPE - create once, publish everywhere. This was noble and good, but they just took it a little too far. In practice, it meant that the editing experience was just long forms, and editors were supposed to just enter content with no context and no visual experience.

Meanwhile at Magnolia - while we've fully embraced headless techniques - we've also continuously provided a visual editing experience that authors appreciate and rely on.

For the last few years it's been trivial for us to position ourselves in the market - "we're the fully headless CMS with a visual page editor." Mic drop. Well, we have to get off our laurels and get into more detail on why we are still the best headless CMS for big projects.

So let's take a look at some of the key features of a CMS that has focussed on Visual Editing since its inception, and which continue to set us apart.

In a nutshell, Magnolia's USP is that it combines batteries-included DXP power and features with the agility, flexibility and frontend focus of headless CMS.

What does this mean in concrete terms?

In Magnolia, the visual editing experience is not only about creative composing and high-fidelity preview, it is the stage for its most powerful features. It's true that with the headless approach, developers can integrate anything in the frontend with code. That's one of the reasons headless has become so popular.

But a huge part of CMS/DXP projects is to bring this capability to non-technical users. This is what Magnolila does in its integrated visual authoring experience.

Marketers can define audience segments based on OOTB traits like country or whether the user is a repeat visitor, campaign query strings (like Google UTM parameters), browsing behaviour on the site, or any custom traits that are provisioned for a CDP or marketing automation tools that the project uses. Then authors can target content variants to any of those segments directly in the visual page editing experience.

Once set up, authors can preview how every page will look for every segment or combination of traits.

The content delivery API serves the personalised content so that developers can easily create personalised experiences without any special logic, it is ready to render.

Enterprises can have 10s, 100s, or even 1000s of websites. Orchestrating content and translations is one of the hallmarks (and main pains) of enterprise projects. While there are some common patterns, most enterprises have unique requirements based on their content and experience strategies. A strength of our Multisite capabilities is the ability to easily reuse content, templates or configuration across multiple sites. This avoids duplication and its attendant problems.

For sites requiring multiple languages but the same content structure, customers should go withr the "single tree" site approach. Each page, or content item has translations for each supported language.

For customers with different content structures per language, they can take the multi-tree approach, one tree for each language. This is pure flexibility, but can be harder to maintain

Live Copy combines the best of both approaches. Authors create the primary "master" content (in multiple languages) in a single tree. Then new sites can be created (For example for each hotel in a chain) with links to the master content. Each site can choose where to have custom content - and where to have Live Copies, so that they are always up to date with any changes on the master content.

As with personalization, its trivial for frontend developers to work with multi-site and live-copy powered content. The content delivery API gives developers the correct content, ready to render.

Magnolia's visual editor has an elegant approach for developers to define which components of a page are also rendered on subpages. This is typically used for the header and footer area of a page or digital experience.

It can also be used for sidebars, extras, or any kind of section content. For example an author adds a promotion to a top section page, and now that promotion is included on every subpage of that section page.

For the developer - its the same story as before - the Delivery API prepares and delivers the content with any. inheritance applied. So the developer just needs to render it as is.

The Campaign Management app leverages the visual editing UI to enable authors to edit and maintain fragments of content (In this case something like a banner). Authors can then place campaign manager "slot" components on the pages of the website. Those slot components will then display one of the banner fragments based on scheduling or other factors.

Note that this is an example of another powerful Magnolia feature. Besides the stock "Pages App", developers can provision additional apps that include the Visual Page Editor UI. Another example of a use-case for this is managing content from different channels in different apps - like a digital signage channel.

Well you might expect this from a product called Magnolia. But did you know that most headless CMS do not support organising content in trees? By tree, I mean a set of nested directories (folders) that store the content, just like pretty much every software system out there- like Windows and Mac OS, Google drive, Evernote, Wiki's etc. And even the ones that do support folders, often don't allow you to order the items in that folder. And they call it a content management system?

Of course it can also be valuable to treat content as a list, and of course Magnolia does that to - but our customers mostly organise their content in trees, since it is so intuitive.

And the Content Delivery and Content Management API support working with hierarchical content.

One way to look at these features is that they are all unique and pragmatic use cases of content reuse and content flows. Your marketers want to leverage the right content in the right place at the right time. True to the COPE best practices, you can orchestrate content so that there are no maintenance headaches associated with duplicated content. You can create one content item, and publish it everywhere - not just to other channels and devices, but also within a channel or experience. Have another look at the features above, notice how each one is controlling content flows.

None of the other headless CMS have these authoring features.

If you aren't giving your marketing team features like this, in a UI they can use, you're putting the business at a disadvantage.

Developers get all of the above features OOTB, they don't need to recreate them or spend time integrating a custom tool. So they can get started on the actual project right away.

Magnolia development stands out from the crowd with its "infrastructure as code" approach. In Magnolia, developers don't need to configure things by hand in the GUI. Developers control the features by lean YAML configuration files in a git repository: transparent, great for cooperation, and ready to deploy at any time. It's the way developers are used to working. Magnolia instantly picks up every change to the configuration. This configuration-based approach is great for agencies and system integrators as it is trivial to re-use in-house design systems and best practices across many projects. And it makes it fast to start new projects.

With Magnolia's approach to headless, you can use your in-house or any off-the-shelf React, Angular and Vue component libraries with no modification. Developers just define the editing forms, and the content that authors enter in the forms will automatically be passed in as the components "props".

This CLI tool for developers further accelerates their work by enabling them to jumpstart headless projects and automates daily tasks for projects in NextJS, React, Angular or Vue. It helps developers create the components that authors will use in the visual editor.

Of course there is much more to Magnolia - but I wanted to focus on these things most closely related to headless and visual editing.

I hope that this blog has made you excited to try one of these features.

If you are curious what we have been up to lately with the developer experience of Magnolia - check out our recent roundup: What's new in Magnolia headless