9 posts tagged with "drupal-11"

Four Kitchens has been making the same argument for years in slightly different forms: editors do better work when the CMS stops acting like a developer control panel and starts acting like a task-focused workplace. That sounds obvious, but most Drupal and WordPress admin experiences still expose too much structure, too many options, and too little guidance at the moment editors actually need it.

The useful part is not the visual style. It is the pattern library underneath: role-based entry points, constrained navigation, strong preview loops, and governance signals embedded in the authoring flow instead of buried in documentation. Those patterns translate cleanly into both Drupal 10/11 and WordPress, even though the implementation details are different.

Drupal core is not just experimenting with a new sidebar. It is steadily moving the admin experience from Toolbar toward Navigation, and that has real consequences for Drupal 10/11 teams that maintain custom admin UX, contrib-heavy stacks, and site-builder training materials.

The timeline matters. Navigation was introduced as an experimental module in Drupal 10.3.0 on June 21, 2024. It became stable in Drupal 11.3.0 on August 4, 2025. Then, on March 3, 2026, core issue work landed to add Navigation to the Standard install profile and Drupal recipes so new installs move toward the new admin model by default.

That does not mean Toolbar is gone today. Core's own issue queue still treats accessibility as the blocker before a full replacement. The practical reading for developers is: the direction is decided, but production rollout still depends on unresolved keyboard and assistive-technology gaps.

display_builder 1.0.0-beta3 shipped on March 3, 2026 with Drupal support declared as ^11.3.3 and 15 resolved issues since beta2. This is still beta software, but the release is now concrete enough to evaluate for real site-building programs.

For Drupal teams, the key question is not "is this interesting?" but "where does this fit against Layout Builder in production architecture and migration sequencing?"

For WordPress teams, this review is still relevant: agencies running both WordPress and Drupal can use this as a pattern for how to evaluate visual-builder adoption risk before committing editor workflows and CI policy.

What Beta3 Actually Delivers​

From the release notes and changelog, Beta3 contains critical fixes for slot movement and JSON:API compatibility.

# Example SDC Mapping in Display Builder
id: my_component
label: Hero Section
slots:
  title:
    label: Title
  image:
    label: Background Image

The Unified Render Pipeline​

Display Builder's model is intentionally "unified": entity display building, page layout, and Views display surfaces are presented through a single builder approach. This reduces architectural fragmentation and ensures that your SDC components behave identically regardless of where they are placed in the CMS ecosystem.

Need an Enterprise Drupal Architect who specializes in UI Suite and visual builder implementations? View my Open Source work on Project Context Connector or connect with me on LinkedIn.

Workflow Impact for Drupal 10/11 Site Builders​

Display Builder's model is intentionally "unified": entity display building, page layout, and Views display surfaces are presented through a single builder approach, implemented by sub-modules (display_builder_entity_view, display_builder_page_layout, display_builder_views).

Operationally, that can reduce context-switching between:

• Entity display configuration
• Block layout administration
• Views display composition

The architecture also stores builder state in configuration (third-party settings / display extenders), which is favorable for config-export discipline and environment promotion when teams already run config-driven deployments.

Layout Architecture: Strong Direction, Non-Trivial Tradeoffs​

The "Migration from Layout Builder" documentation is explicit about current conversion boundaries:

• SDC-based layouts/components map cleanly.
• Non-SDC layouts are flattened (no full structural conversion).
• "Extra field" conversion is incomplete (placeholder behavior).
• Block titles are not imported in the same way because wrapper template behavior differs.

A second critical architecture detail: Display Builder rendering does not rely on block.html.twig and field.html.twig in the same way, so modules depending on hook_preprocess_block and hook_preprocess_field side effects can behave differently.

That is not a minor footnote. It is a direct compatibility surface you must test before rollout if your stack relies on preprocess-driven alterations.

Migration Risk Assessment (Practical)​

Risk is moderate-to-high for existing Layout Builder-heavy estates unless you preflight with a structured test matrix.

Highest-risk zones:

• Complex legacy layout plugins that are not SDC-based.
• Sites with many entity display overrides and custom block behaviors.
• Module/theme customizations that depend on preprocess hooks at block/field wrapper level.
• Editorial teams requiring strict fidelity with existing block titles and wrapper semantics.

Lower-risk zones:

• New Drupal 11.3+ builds designed around UI Suite + SDC from day one.
• Teams that can keep Layout Builder and Display Builder installed in parallel during validation.
• Projects with robust config QA and visual regression checks.

Recommended Adoption Pattern​

Use a phased adoption model:

1. Pilot on one content type + one Views display.
2. Export config diffs and inspect third-party settings changes.
3. Run regression on preprocess-dependent modules/themes.
4. Validate override behavior and rollback logs in editor workflows.
5. Expand scope only after parity acceptance criteria are met.

If your Drupal stack also powers WordPress-facing delivery teams (shared design system, shared QA/release governance), treat this as a cross-CMS governance event: update component contracts, definition-of-done, and release checklists before broad rollout.

Bottom Line​

1.0.0-beta3 is a substantive beta, not a marketing-only increment. The module is advancing quickly and already exposes a coherent architecture for unified display building in Drupal.

But migration is not "free." The main risk is architectural mismatch with legacy Layout Builder assumptions, especially around non-SDC layouts and preprocess-driven wrapper behavior. Teams that test those boundaries early can adopt with controlled risk. Teams that skip that work will absorb the risk in production.

Sources​

• Display Builder project page (Drupal.org)
• display_builder 1.0.0-beta3 release notes and changelog
• Display Builder documentation
• Migration from Layout Builder (Display Builder docs)
• Configuration model (Display Builder docs)
• Views integration docs
• display_builder 1.0.x commit log (Drupal code)

GraphQL for Drupal 5.0.0-beta2 (tagged on February 19, 2026) is a meaningful beta step: it fixes a cacheability metadata gap in current:user query results and adds node preview URL support in route-based entity resolution.

A new public code search service now targets Drupal contrib projects compatible with Drupal 10+, with a UI at search.drupal-api.dev and an API at api.tresbien.tech. For maintainers and upgrade teams, this is immediately useful: you can query real contrib code patterns before writing migrations, patches, or architecture decisions.

One missing cache tag can quietly force expensive rebuilds on every request. A February 2026 report described exactly that pattern behind a 4.2-second Drupal product page.

Drupal 11 ships with jQuery 4. jQuery 4 removes $.type(). Slick Carousel uses $.type(). The result is a fatal JavaScript error that kills every carousel on the page. I tracked down the exact failure chain and the fix.

Drupal 11.1 does not break public APIs, but custom entity code can still break during upgrades because entity type definitions moved to attributes, some entity-related routes are deprecated for Drupal 12, and entity reference formatter output changed in access-sensitive contexts. If you maintain custom entities, treat Drupal 11.1 as a migration checkpoint, not just a patch-level bump.

If your team is still on Drupal 10.4.x, treat Drupal 11 migration as active incident prevention, not roadmap hygiene: Drupal.org now flags 10.4.x security support as ended, and current supported lines are newer. The fastest safe path is to clear the high-impact change records first, then move to supported 10.5/10.6 and 11.x targets in one controlled sequence.