8 posts tagged with "Drupal CMS"

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.

Pantheon announced on March 6, 2026 that new sites created from the Drupal CMS upstream now use Drupal CMS 2. This is not a blanket platform upgrade: Pantheon explicitly says existing Drupal CMS sites are not auto-updated, and Drupal 10/11 upstream sites are not affected.

That split matters operationally. Teams can misread this as "new upstream available, apply update everywhere." For managed portfolios, that interpretation is risky.

The important point: this is not a patch-level update. Treat it as a controlled migration.

What Actually Changed​

From Pantheon and Drupal.org sources:

• Pantheon updated the Drupal CMS upstream to version 2 for newly created sites.
• Existing Drupal CMS sites require deliberate upgrade work and validation.
• CMS 2 introduces architectural shifts, including Canvas as default editing UX and the Byte site template.
• Pantheon's Drupal CMS guidance flags concrete break risks for 1.x to 2.0 upgrades.

The important point: this is not a patch-level update. Treat it as a controlled migration.

Breaking-Change Surface You Need to Map First​

Pantheon's own Drupal CMS doc calls out the highest-risk breaks for CMS 1.x sites, including theme removal and recipe package splits.

# Update sequencing for Drupal CMS 2
composer require drupal/cms:^2 -W
composer require drupal/site_template_helper:^1
vendor/bin/drush theme:enable byte
vendor/bin/drush theme:set-default byte
vendor/bin/drush cr

• drupal_cms_olivero is removed and replaced by byte; post-upgrade, unresolved theme config can trigger missing theme errors.
• Several content-type recipe packages are replaced by drupal_cms_site_template_base.
• Composer plugin allowlist requirements change (drupal/site_template_helper must be explicitly allowed), or Integrated Composer builds can fail.
• automatic_updates is marked obsolete and should be uninstalled after upgrade.

For managed Drupal teams, the real blast radius is usually:

• Theme dependency assumptions in custom front-end work.
• Content model dependencies on replaced recipe packages.
• CI/CD breakage from Composer allow-plugins drift.
• Inconsistent environments if Dev is upgraded but promotion criteria are weak.

Update Sequencing for Managed Teams​

The safest order is environment-first and evidence-driven:

1. Classify sites by upstream: Drupal CMS vs Drupal 10/11 core upstreams.
2. For Drupal CMS 1.x sites, branch to Multidev first; do not start in Dev/Test/Live.
3. Inventory content using recipe-provided types (Blog, News, Events, etc.) before any package removals.
4. Update composer.json constraints from ^1 to ^2, apply package replacements, and update allow-plugins.
5. Run DB updates and config validation in Multidev; switch theme to byte before declaring success.
6. Validate editor workflows (Canvas, content creation, revisions), not just homepage rendering.
7. Merge to Dev only with explicit rollback criteria and owner sign-off.

This sequencing aligns with Pantheon's Multidev-first guidance and reduces production surprise.

The Integration Test Gate: Beyond Code Success​

A successful build artifact does not guarantee a successful Drupal CMS 2 site. Because CMS 2 relies heavily on recipes and configuration-as-code, you must validate the Canvas editor experience and the integrity of the Byte theme mappings in Multidev before merging any code to production.

Need an Enterprise Drupal Architect who specializes in Pantheon upstream migrations and CI/CD optimization? View my Open Source work on Project Context Connector or connect with me on LinkedIn.

Deployment Checklist​

Use this as a release gate before promotion:

• Upstream classification documented per site (CMS upstream vs Drupal 10/11 upstream).
• Dependency diff approved (composer.lock + removed packages + plugin allowlist updates).
• Theme migration completed and verified (drupal_cms_olivero references removed, byte active as intended).
• Content integrity check completed for replaced content-type recipes.
• Drush update + cache rebuild + watchdog checks clean in Multidev.
• Editor smoke tests passed (create/edit/publish, media, menus, forms).
• Config export/import cycle passes without unexpected drift.
• Rollback path tested (known-good tag + DB backup + owner on-call).

If one item is missing, delay promotion. CMS 2 adoption is optional per-site, outage time is not.

WordPress and Cross-CMS Relevance​

WordPress teams on Pantheon are not directly impacted by this Drupal CMS upstream change. But multi-CMS platform teams should still adopt the same discipline:

• classify by upstream/product line,
• avoid "one update policy for all sites",
• enforce environment-gated promotion with explicit rollback checks.

That process is reusable across Drupal and WordPress estates, even when only one CMS has breaking changes.

Bottom Line​

Pantheon's Drupal CMS 2 upstream update is a positive move for new builds, but for existing managed Drupal estates it is a migration event, not a maintenance click. The teams that avoid incidents will be the ones that map the breaking surface early, run Multidev-first sequencing, and enforce a release gate that checks content and editor workflows, not only code deploy success.

Sources​

• Pantheon release note (March 6, 2026): Upstream update for Drupal CMS 2 now available
• Pantheon docs: Drupal CMS on Pantheon (includes 1.x to 2.0 upgrade warnings and recommended steps)
• Drupal.org: Drupal CMS releases
• Drupal.org: cms 2.0.0 release notes
• Pantheon docs: WordPress and Drupal Core Updates

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)

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.

The Drupal CMS survey callout published on February 23, 2026 is timely and worth acting on. But teams should submit feedback with release context in mind: Drupal core 11.3.0 is current, Drupal 10.5.x is the transitional supported line, and Drupal CMS 2.x is the active stream.

The best use of this survey is to report friction that blocks real launches, not generic wishlist items.

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.

Drupal CMS recipes are the most practical building block for AI-driven site assembly: they translate a plan into installable modules and configuration with one apply step. I built a small recipe package and a PHP blueprint helper to test how well this works in practice.