What Should Drupal Authoring Look Like? (Beyond Paragraphs and Canvas)

“If we could design the ideal Drupal authoring experience from scratch today, what would it look like?”

That's the question I keep coming back to, and the one that prompted this article. I'm convinced it's more interesting than Paragraphs vs. Layout Builder vs. Canvas, particularly in the context of decoupled Drupal.

Because Drupal has never really had a shortage of ways to build pages.

For years, many of us have relied on Paragraphs to create structured, reusable content components. Others have adopted Layout Builder to give editors more control over page composition. And now Drupal Canvas is pushing the experience further toward visual page building.

They are different approaches, created at different moments, but they are all trying to solve some version of the same problem:

How do we give editors enough flexibility to build great digital experiences without giving up the structure and guardrails that make a CMS valuable?

Finding the right abstraction for editors and devs

Developers and editors tend to look at page building very differently.

As developers, we think about things like structured data, schemas, reusable components, APIs, design systems, validation, permissions and maintainability.

Editors are trying to publish a page. They want to see what they're building, move things around, understand what the final result will look like without switching between five different screens or constantly clicking Preview.

Neither perspective is wrong, but the challenge is finding the right abstraction and alignment between them.

Give editors too little control and every landing page becomes a developer request. Give them complete freedom and eventually your carefully designed system becomes a collection of one-off pages.

The ideal authoring experience probably lives somewhere in the middle.

Paragraphs got a lot right

There's a reason Paragraphs became such a common approach to building Drupal sites.

It maps nicely to the way many development teams already think about component-based systems.

A Hero is a Paragraph. A CTA is a Paragraph. A Card Grid is a Paragraph.

Editors compose pages from a predefined collection of components, while developers maintain control over what those components can do.

That gives us something extremely valuable: flexibility with guardrails.

But the editing experience isn't necessarily the same as the experience being created.

An editor may be building a highly visual landing page through a mostly form-based interface. They understand the structure of the page, but they still have to mentally translate that structure into what visitors will eventually see.

This is something we've been experimenting with for a while at Octahedroid. In Drupal as a Composable CMS: The Next Generation of Structured Content, we documented some of our earlier experiments combining Paragraphs, visual composition and React components.

Layout Builder moved composition closer to the editor

Layout Builder introduced another important idea: editors shouldn't only manage content; they should be able to influence layout.

That brings the authoring experience closer to the final page, but it also introduces another set of questions:

• How much control should editors have?
• Who defines available layouts?
• How tightly should layout be connected to the design system?
• When does flexibility become complexity?

These aren't really Drupal-specific problems. Every modern CMS that introduces visual composition eventually has to answer them.

Canvas pushes Drupal further toward visual authoring

Drupal Canvas makes the direction even more interesting.

Instead of treating visual page building as something layered onto the traditional Drupal editing experience, Canvas moves visual composition much closer to the center of authoring.

That's a significant shift. And I think it's worth paying attention to even if Canvas isn't the answer for every Drupal project.

At DrupalCon Chicago this year, Canvas was one of the areas where we saw significant progress. But, as I wrote in our DrupalCon Chicago 2026 recap, the relationship between these new authoring experiences and decoupled Drupal still feels like an unfinished story.

Because visual editing alone isn't the entire problem. There are still questions around structured content, reusable entities, relationships, design-system governance, permissions, workflows and increasingly AI-assisted authoring.

And decoupled Drupal makes all of this harder to ignore.

Decoupled makes the authoring problem more obvious

Decoupled architectures gave developers enormous flexibility.

Drupal can manage structured content while React, Next.js or another frontend framework controls presentation.

From an engineering perspective, that's powerful.

From an editorial perspective, we sometimes made things worse.

The CMS knows about the content. The frontend knows how that content is rendered. The design system knows what components exist.

And the editor somehow has to operate across those boundaries.

Preview becomes something we have to rebuild. Visual editing becomes something we have to integrate. Component definitions can exist in multiple places.

The more decoupled the architecture becomes, the easier it is for the authoring experience itself to become decoupled.

We've spent quite a bit of time working on this particular problem.

In The Modern Content Editor's Experience in Decoupled Drupal, we explored how visual editing and modern editorial workflows can close some of this gap.

And Real-Time Content Preview in Decoupled Drupal goes deeper into one piece that I think is essential: editors should be able to see the actual frontend while they're working, even when Drupal isn't rendering it.

But preview solves only part of the problem.

Maybe the CMS shouldn't own the entire authoring experience

What if the authoring experience didn't have to be completely coupled to the CMS?

Imagine an authoring layer that understands the design system and the components available to an editor.

It knows:

• which components can be used.
• which properties they expose.
• where they can be placed.
• which content can come from the CMS.
• how components relate to structured entities.
• what the page will actually look like.

The CMS can continue doing what it does well: content modeling, entities, relationships, permissions, workflows and APIs.

The frontend can continue doing what it does well: rendering experiences.

And the authoring layer can focus specifically on composition and editorial experience.

For a decoupled architecture, that separation starts to make a lot of sense, but it also raises an interesting possibility.

If the authoring experience isn't inherently tied to Drupal's rendering layer, does it even need to be tied exclusively to Drupal? Could the same design system and authoring experience work with Drupal, Contentful, Sanity, WordPress or even non-CMS content sources?

That's a much bigger question.

And then there's AI

In my previous post, AI Is the New UI — What Does That Mean for Drupal Canvas?, I explored whether conversational interfaces could eventually replace some of the visual interfaces we're building today.

I still think AI will fundamentally change authoring, but I'm less convinced that means removing the interface.

AI could instead become another way of interacting with the same structured system. An editor could drag a Hero component onto a page, or ask:

“Add a hero using the product launch image, make the headline more concise and add the primary CTA.”

Both interactions could produce the same underlying structured configuration.

AI shouldn't need to generate arbitrary markup every time someone wants to change a page. It can operate within the same component definitions, schemas and guardrails that humans use through the visual interface.

In that model, visual editing and AI are two ways of interacting with the same system, instead of competing interfaces.

So what should the ideal authoring experience look like?

I don't think I have the complete answer, but there are a few things I increasingly think belong together:

Structured content.

Content should remain meaningful outside the page where it happens to appear.

Reusable components.

The design system should define what editors can compose instead of allowing arbitrary markup.

Visual composition.

Editors should be able to understand the page while they're building it.

Guardrails.

Flexibility shouldn't mean abandoning accessibility, brand consistency or maintainability.

Live preview.

Preview shouldn't feel like a separate application bolted onto the CMS.

Decoupled data.

Components should be able to consume content from entities, relationships and potentially multiple data sources.

AI-assisted authoring.

AI should help editors compose and modify structured experiences without bypassing the underlying system.

And perhaps most importantly:

The authoring experience shouldn't dictate where the content has to live.

What Is Your Drupal Team Doing Today?

This is where I'd really like to hear from people building actual Drupal projects. How are you building pages today?

Paragraphs? Layout Builder? Drupal Canvas? Something custom?

If you're using Canvas in production, what's working well? What challenges are you running into?

For decoupled Drupal projects, how are you handling visual editing and preview?

What functionality have you had to build yourself?

Have you found other tools or approaches that solve parts of this problem particularly well?

And finally:

If you could design the ideal Drupal authoring experience from scratch today, what would it look like?

I'd love to hear what people are learning from real projects.

What the Ideal Authoring Experience Needs?

1. Structured content.
2. Reusable components.
3. Visual composition.
4. Guardrails.
5. Live preview.
6. Decoupled data.
7. AI-assisted authoring.
8. Independent content.

4 Questions for Drupal Teams

1. How are you building Drupal pages today? Paragraphs? Layout Builder? Canvas? Something custom?
2. If you're running Canvas in production, what's working and what isn't?
3. For decoupled projects, how are you handling visual editing and preview?
4. If you could design the ideal authoring experience from scratch, what would it look like?