Drupal's Site-Building Direction Isn't Settled Yet. Here's How to Build Anyway.

If you build Drupal sites without writing much custom code, the current direction of Drupal site building is confusing.

Layout Builder is stable and included in Drupal Core. Single Directory Components, usually called SDCs, are also in Core. But Layout Builder cannot use those components directly. Paragraphs is still one of the most widely installed contributed modules. Canvas uses SDCs natively and ships with Drupal CMS, but it is still a contributed module. UI Patterns can connect SDCs to Layout Builder, but UI Patterns and Canvas have had compatibility problems. Display Builder offers another SDC-based approach, but it is still in beta.

That leaves site builders with a simple question: What exactly are we supposed to build with?

I have taught Drupal site building to over 50,000 people for 15 years, including teaching Layout Builder at Drupal Camps around the U.S. (this is the highest viewed video for any session that year).

I still believe visual site building is one of Drupal’s strengths. But after researching the Drupal 11 and Drupal 12 roadmaps, I don't think we can pretend there is one clear, settled direction.

There isn’t. Not yet.

Drupal Core and Drupal CMS are now different products

The first thing we need to understand is that Drupal Core and Drupal CMS no longer have the same purpose.

The official Drupal Core strategy describes Core as a platform for people building customized CMS solutions. Drupal Core provides the entities, fields, configuration, rendering, APIs, and other foundation pieces.

Drupal CMS is the assembled product. It combines Core with contributed modules, recipes, an improved administrative interface, Canvas, and other tools intended to help agencies and professional site builders deliver sites faster.

The Drupal CMS strategy says this plainly. It also says the Drupal CMS strategy does not define the Drupal Core strategy.

That is a substantial change in how we should think about Drupal.

For years, I have encouraged people to begin with Core whenever possible. Core modules generally provided the clearest commitment to upgrades, compatibility, and long-term maintenance.

That advice still has value, but "Core first" can no longer mean "Core only" (and never really has... to get Layout Builder functional in Drupal 10 and 11 without SDCs requires at least 8 contributed modules).

The product Drupal wants most new users to experience is Drupal CMS. Canvas is part of that product even though Canvas is not part of Drupal Core.

Why this split isn't necessarily a bad thing

Before I go further, I should give the other side of this a fair hearing.

It's easy to read the Core and Drupal CMS separation as drift, or as Drupal losing the plot. I don't think that's what's happening.

Core carries obligations that a product can't carry. Backward compatibility. Long deprecation cycles. Semantic versioning promises. Security coverage for years. Those obligations are the reason we can upgrade Drupal sites the way we do, and they're also the reason Core moves slowly. That's the trade, and it's a trade I want Core to keep making.

Drupal CMS doesn't carry those same constraints. It can ship, watch what breaks, and adjust. That's how a product is supposed to behave. Asking Core to move at product speed would mean giving up the guarantees that make Core worth standing on.

So the split isn't confusion. It's specialization.

“Still a contributed module” is not automatically a warning label.

I've been guilty of treating "it's contrib" as a strike against a module. It isn't, and Drupal's own history says so.

Views spent years in contrib before it became the backbone of Core's listing system. Media started as contributed Media Entity work and was pulled in afterward. Content Moderation grew out of Workbench Moderation. Layout Builder itself is downstream of years of contributed experimentation in Panels, Panelizer, and Display Suite.

That's Drupal's normal path. Ideas get proven under real project pressure in contrib, and the parts that survive get absorbed into Core with the guarantees attached. Canvas being contrib today isn’t evidence that it is unserious. Contrib has historically been where many of Drupal’s most important ideas were proven.

That pattern is a pattern, not a promise.

Plenty of excellent contributed modules never reached Core. Some took a decade. Some got overtaken by a different approach while they waited. Pathauto and Token have been essential to nearly every Drupal site I've built for fifteen years, and neither is in Core.

So "it's on the contrib-to-Core path" doesn't mean "this will be in Core." It means the path exists.

What I'd actually evaluate isn't Core versus contrib. It's this:

• Who maintains it, and are they funded?
• Is the storage format stable, or will my saved layouts break?
• Is there a stated upgrade commitment between versions?
• What happens to my work if this project stalls?

Canvas answers most of those well. Display Builder answers some of them. Layout Builder answers all of them and always has, which is exactly why it's still the conservative choice.

Layout Builder is not being removed from Drupal 12

Let’s clear up one important concern.

As of July 2026, Layout Builder is not scheduled for removal from Drupal 12. It remains a stable Core module, and Drupal 12 development includes work to keep its APIs compatible.

Drupal 11 will also receive support until at least the middle or latter part of 2028. Existing Layout Builder sites are not about to stop working simply because Drupal 12 is released.

That is the good news.

The less reassuring news is that Layout Builder no longer appears to be receiving Drupal’s primary site-building investment.

Layout Builder still has long-running issues involving:

• Translation
• Section reordering
• Changing a section after it has been created
• Inline-block management
• Revision behavior
• Visibility controls
• Large and confusing block lists
• Default layouts and per-content overrides

Drupal Core’s own page-building improvement plan acknowledges that site builders often need several contributed modules to make Layout Builder suitable for production (as noted above). Those additions introduce their own maintenance and compatibility concerns.

Layout Builder works. But the polished experience site builders expected never completely arrived in Core.

And then there's Paragraphs

Paragraphs isn't something I use. I've never built a production site on it, and I've never taught it. My work has centered on Layout Builder and Core display tools. So take what follows as an honest survey of the landscape rather than as advice from a practitioner.

For a very large share of the Drupal sites running right now, Paragraphs is the answer. It's one of the most widely installed contributed modules in Drupal's history, with over 255,000 reported installs. Walk into a nonprofit, a university department, or a city government site built in the last eight years and you're more likely to find Paragraphs than Layout Builder.

If that's your site, the question isn't academic.

Why so many teams landed there

Paragraphs solved a specific problem well. Instead of one enormous WYSIWYG body field, editors pick from a defined set of component types, each with real fields behind it. Content stays structured. Editors get flexibility without getting a blank canvas.

That last part is why Paragraphs stuck in government and nonprofit work especially. When you have forty content editors of wildly varying skill, a constrained set of approved paragraph types is a feature, not a limitation. Layout Builder's freedom is exactly what those teams don't want.

The long term cost is well documented though as well. Paragraph types multiply. Nested paragraphs get expensive to render and painful to migrate. Every new layout variant becomes a modeling exercise. Teams who've lived with a large paragraph library for five years know what that maintenance load feels like.

Paragraphs doesn't use SDC, and that turns out to be the point.

Paragraphs has no SDC integration. None. There's no "render with a component" setting in the module, no component discovery, nothing.

Paragraphs is a content entity type. It defines storage and editing. It has no opinion about markup at all. Rendering happens somewhere else entirely, in Manage Display, view modes, field formatters, and Twig. Paragraphs doesn't own that layer, so there's nothing for it to integrate.

Which means connecting Paragraphs to SDC is something you do at the display layer, and there are already several ways to do it:

• Plain Twig. In paragraph--hero.html.twig, include your component and pass the fields as props. No contributed modules required. This works on any Drupal 11 site today.
• UI Patterns 2. Expose components as layouts and select one on the paragraph type's Manage display page, then map fields to props through the UI. The ui_patterns_paragraphs submodule adds data sources for Paragraphs behaviors and host entity values.
• SDC Display. A lighter contributed option that adds a render-with-component setting directly in Manage Display.
• Display Builder. Paragraphs are entities, so entity display building applies in principle. Given the unresolved questions above, I'd treat that as theoretical for now.

Here's what that means in light of this diagram I keep coming back to:

Structured Drupal content
          ↓
A display-building tool
          ↓
An SDC component
          ↓
Rendered HTML and CSS

A well-structured Paragraphs site already has the first layer of that diagram working in production at scale. SDC can be introduced at the presentation layer without changing the stored paragraph content.

The paragraph entity is the structured content. The SDC is the presentation. The thing in the middle is a mapping you configured, and you can change it. You can move from hand-written Twig to UI Patterns without touching a single stored paragraph. The data doesn't know or care.

And it's a genuinely better position than a Layout Builder site carrying thousands of per-node overrides. Those overrides store layout structure and block configuration inside the content itself. Paragraphs itself never coupled storage to a particular rendering system, so it never accumulated that debt.

I don't say this as a Paragraphs advocate. I've never built on it. But if the question is which existing approach is best positioned to survive whatever happens with Canvas, Display Builder, and Layout Builder, the honest answer isn't the Core module. It's the one that stayed out of the rendering business.

Where Paragraphs sits in the current picture

Paragraphs is a fourth unsettled question, and it's the one affecting the most existing sites.

The Display Builder team has openly discussed how Paragraphs and Display Builder should relate, and it isn't resolved. Three approaches have been identified: keep Paragraphs for content entry while Display Builder handles layout, replace Paragraphs once component locking is complete, or embed Paragraphs inside Display Builder layouts. That third option has been identified but not implemented, blocked on architectural complexity.

Canvas's relationship to Paragraphs is similarly in progress. Contributed bridges have appeared, including modules that expose existing paragraph entities as Canvas components so teams don't have to rebuild a large library from scratch. Those are early-stage projects with small install counts. They're worth watching. I wouldn't stake a migration plan on one yet.

So if you're on Paragraphs today, the same conclusion applies that applies everywhere else in this article: there's no announced deprecation, no forced move, and no documented migration path either.

What I'd say to a team that uses Paragraphs

I want to be careful here, because this isn't my area of practice. But three things follow directly from what the rest of this article establishes.

Audit your paragraph types for layout logic. The architectural advantage above only holds for paragraph types that store content. A paragraph type holding a heading, body text, and an image reference is portable to anything. A paragraph type whose entire purpose is "three-column section with a background color option" is layout logic wearing a content costume, and it carries the same migration cost as a Layout Builder override. Most large paragraph libraries have both kinds. Knowing which are which is the most useful hour you can spend before any builder decision.

Nothing is forcing your hand. Paragraphs is actively maintained and Drupal 11 compatible. There's no deadline here. The pressure you're feeling is the same ambient pressure everyone else in this article is feeling, and it isn't the same thing as a deprecation notice.

The bridges are the thing to watch. If a Paragraphs-to-Canvas or Paragraphs-to-Display-Builder path matures into something maintained and stable, the calculus changes fast. Right now those projects are young. Track them. Don't bet a redesign on them.

Bottom Line: Teams who kept their content in fields and entities have options. Teams who encoded their design system into their content structure have a rebuild ahead of them regardless of which builder eventually wins.

That's true for Paragraphs sites, Layout Builder sites, and it will be true for Canvas sites too.

Core is discussing Layout Builder’s long-term future

There is no approved plan to remove Layout Builder, but Core leadership is discussing how Layout Builder, Block Layout, and Canvas should eventually be reconciled.

The official reconciliation issue describes the duplication directly:

• Block Layout controls theme regions.
• Layout Builder controls entity displays and per-entity overrides.
• Canvas is moving into pages, content templates, and global site regions.

One proposal suggests that Layout Builder overrides could eventually move to contrib. Another considers whether Layout Builder’s entity-display functionality might also move while selected Canvas infrastructure comes into Core.

These are proposals, not decisions.

Still, site builders should pay attention. The discussion shows that Layout Builder’s long-term place in Core is not guaranteed simply because it is there today.

For Drupal 12, Layout Builder is safe.

Beyond Drupal 12, its position is unsettled.

Canvas is Drupal CMS’s direction

Canvas has the strongest institutional momentum.

It is the default visual editing experience in Drupal CMS 2.0. It discovers SDCs directly, provides drag-and-drop page composition, and supports Content Templates for laying out node displays.

Canvas 1.8 also includes translation support and entity-reference props. Its published roadmap includes editing structured Drupal content directly inside Canvas, restricted slots, improved image handling, advanced workflows, and eventually Canvas-native list and form builders.

You can review those plans on the Canvas roadmap.

Canvas is especially strong for landing pages. Editors can compose headings, text, images, calls to action, layouts, and other components in one visual interface.

Content Templates extend that idea to structured content. A site builder can create a template for an Article view mode and map entity fields into compatible component props.

That is promising, but Canvas does not yet replace everything Drupal’s display system can do.

Current limitations include incomplete support for entity types beyond nodes, differences in how fields and slots work, less direct use of traditional field formatters, and gaps around some Views and contextual-block behavior.

Canvas now has stable, security-covered releases, but its capabilities, integrations, and place in Drupal’s wider display architecture are still evolving.

SDC is the safest investment

The clearest part of Drupal’s site-building direction is not a builder. It is SDC.

Single Directory Components are now part of Drupal Core’s rendering system. Canvas uses them. UI Patterns uses them. Display Builder uses them. Custom themes and modules can use them directly.

That makes SDC the best place to put your long-term frontend investment.

A well-designed component contains:

• A clear component schema
• Declared props
• Declared slots
• Twig markup
• Component CSS
• Optional JavaScript

The component should not care whether its data came from Canvas, Layout Builder, a View, a node template, or a custom block.

Think of it this way:

Structured Drupal content
          ↓
A display-building tool
          ↓
An SDC component
          ↓
Rendered HTML and CSS

The display-building tool may change. The component should survive. 

That is the part I would standardize on today.

What about UI Patterns?

UI Patterns 2 provides the missing connection between SDC and traditional Drupal display tools.

It can expose components in:

• Layout Builder
• Block Layout
• Manage Display
• Field formatters
• Views

That sounds like the exact solution many of us need.

Unfortunately, UI Patterns and Canvas have both modified Drupal’s component discovery system. Their changes have not always worked safely together. Some problems have been fixed, but compatibility concerns remain.

The UI Suite team described Canvas compatibility as a priority in its April 2026 project update.

I would not currently assume that adding Canvas and UI Patterns to the same production site is trouble-free. Test the exact versions and enabled submodules carefully before committing to that combination.

Sharing the same component standard does not automatically make two component-management systems compatible.

Display Builder offers a fourth approach

Display Builder is being developed by the UI Suite team. It is based on SDC and UI Patterns and is aimed directly at Drupal site builders.

Its goals are broad. Display Builder intends to replace:

• Layout Builder for entity displays
• Block Layout for page structure
• Parts of the Views display interface

Display Builder integrates deeply with Drupal fields, field formatters, tokens, referenced entities, and other familiar site-building systems.

That makes it particularly interesting for experienced Drupal site builders. Canvas currently offers the better content-editor experience, while Display Builder offers deeper access to Drupal’s existing display tools.

However, Display Builder is still beta. It does not yet have a supported stable release.

I would experiment with it. I would not yet make it the unquestioned standard for every production project or every beginner training course.

What should site builders do now?

Here is the practical approach I recommend.

1. Keep content structured

Use content types, fields, media, taxonomy, and entity references for meaningful content.

Do not hide all essential content inside builder-specific blocks or component configuration.

Structured content is easier to query, migrate, translate, reuse, and present through a different builder later.

2. Learn SDC

SDC is the common language shared by the competing approaches.

Learn how to define props, slots, variants, Twig markup, CSS, and component schemas. Treat those schemas like APIs. Once a component is in use, changing its contract can affect stored layouts and templates.

3. Use Layout Builder or Paragraphs where it already works

There is no reason to rebuild a working Layout Builder site simply because Canvas exists.

Layout Builder remains supported in Drupal 11 and Drupal 12. Default layouts for content-type view modes remain a valid site-building technique.

I would be more cautious about creating hundreds or thousands of unique per-node overrides. Those will be harder to move if Drupal eventually provides a migration path to another builder.

4. Use Canvas for the work it handles well

Canvas is a strong option for landing pages and visually composed marketing pages.

Test Content Templates with real content before replacing Layout Builder displays. Include translations, revisions, moderation, Views blocks, entity references, and multi-value fields in that test.

A page that looks good in a demo is only the beginning. The full editorial process matters.

5. Choose one component integration system

For now, avoid building a project that depends equally on Canvas, UI Patterns, Display Builder, and Layout Builder.

Choose the primary approach intentionally:

• Layout Builder for a conservative Core-centered project
• Paragraphs if you're already using it
• Canvas for a Drupal CMS and editor-centered project
• UI Patterns plus Display Builder for a design-system and site-builder-centered project

Trying to combine every approach gives you more dependencies without giving you a settled standard.

How I plan to teach this

I've never described one page builder as “the Drupal way.”  I've leaned towards Layout Builder Core and Contrib because a Site Builder could build with it without depending on a themer with custom block types, Layout Builder and some CSS. That said, moving forward, I'll continue to teach the pieces that survive the builders:

1. Content modeling
2. Fields and entity references
3. View modes
4. Field formatters
5. Configuration management
6. SDC components
7. Builder-specific composition

Students should understand which layer they are working in.

Layout Builder, Paragraphs, Canvas, and Display Builder can all arrange a page. They do not store configuration in the same way, offer the same Drupal integrations, or have the same upgrade promises.

That distinction matters.

My conclusion

Drupal has standardized its component format, but it has not standardized its site-building interface.

Layout Builder remains the stable Core option. Paragraphs is widely used and heavily supported. Canvas is the primary direction for Drupal CMS. Display Builder is developing into a serious site-builder-focused alternative.

For now, the safest long-term architecture is:

Structured content
+ stable SDC components
+ one intentionally selected builder

I wish the answer were cleaner. Site builders deserve a clear commitment, a documented migration path, and enough stability to invest in a workflow without wondering whether the next major initiative will leave it behind.

We do not have that complete answer yet.

But we can protect our work by building on the parts Drupal is clearly carrying forward: structured content and Single Directory Components.

Start there. Keep the builder replaceable.