Security releaseUmbraco backoffice advisory CVE-2026-41205 — managed clients already patched.Read the advisory
websitesupport.io
All articles
Platform updatesDrupalExperience Builder

Drupal's Experience Builder goes stable — what changes for content teams

Drupal 11.2 ships Experience Builder as a stable, default-on visual page-building layer. Here's what it actually changes for editors, and what site builders need to configure first.

T
Tomasz Nowak
Front-end lead
14 Aug 20265 min read
DRUPAL 11.2 · EXPERIENCE BUILDER

Drupal 11.2 ships Experience Builder (XB) as stable — a drag-and-drop, component-based page building layer that sits on top of Drupal's existing field and paragraph system. It's the most significant change to the Drupal editorial experience in years, and it changes who can build a page without changing what the page is built from underneath.

What's actually new

  • A visual canvas for assembling pages from reusable components, with live preview as you edit
  • Components are still standard Drupal render elements underneath — Twig templates, not a parallel system
  • Component-level permissions, so you can control which roles can place which components where
  • Works alongside Layout Builder and paragraphs rather than replacing them outright
  • Component markup is accessible by default when built from the core component starter kit

What this means for content teams

The practical effect is fewer developer tickets for routine page assembly. A marketing team can build a landing page from an approved component library — hero, stat band, testimonial, CTA — without waiting on a sprint slot for a one-off page. For organisations that have felt bottlenecked on simple page requests, this is a genuine, measurable win.

What we're watching before recommending a wide rollout

Experience Builder is only as good as the component library behind it. Opening the full kit to every editor on day one tends to produce component sprawl — five slightly different hero variants within a month, accessibility regressions in anything pulled in from a third-party recipe, and pages that drift from brand guidelines because nothing stopped them from doing so.

The rollouts that work well start with a small, curated, accessibility-checked component set and expand deliberately, with component-level permissions used to keep editorial freedom bounded rather than unlimited. That curation step is easy to skip and expensive to fix retroactively once fifty pages depend on an uncontrolled component.

Planning an Experience Builder rollout?

We audit and curate the component library, set sensible permissions, and check accessibility before it reaches your editorial team — rather than after.

See Drupal support

Stay ahead of the next release

Security alerts, platform updates and industry analysis — straight to your inbox.

We respect your privacy and only send essential updates.