Using Drupal Layout Builder for Consistent Page Layouts Without Custom Twig

Problem: editors need flexible pages but developers want version‑controlled markup

When a content team asks for the ability to rearrange sections, add promotional blocks, or change column widths on a per‑node basis, the traditional answer is to create a new Twig template or a custom block plugin. That approach works, but it ties layout changes to code deployments, makes it hard for non‑technical editors to experiment, and can lead to a proliferation of template files that are difficult to maintain.

Thesis: Layout Builder lets site builders assemble pages visually while still benefiting from Drupal’s caching and configuration management

By enabling the core Layout Builder and Layout Builder Discovery modules, you can define a default layout for a content type, override it on individual nodes, and have Drupal automatically generate the appropriate cache contexts and tags. The layout itself is stored as configuration, which means it can be exported, version‑controlled, and deployed alongside code—without writing a single line of Twig.

Section 1: Enabling and configuring Layout Builder

1. Ensure you have the layout_builder and layout_discovery modules enabled. Run this command as a user with the "administer modules" permission:

drush en layout_builder layout_discovery -y

1. Navigate to Structure → Content types → [your type] → Manage display. Click the "Use Layout Builder" checkbox and save.
2. Click "Manage Layout" for the default layout. You’ll see a blank canvas where you can add sections.
3. Add a section (e.g., a two‑column layout) by clicking the "+ Section" button, choosing a column pattern, and then placing blocks inside each column. For a quick test, add the "Most recent content" block to the left column and the "Node title" field to the right column.
4. Save the layout. Drupal will create a configuration entity like layout_builder.layout__article__default.yml (the name varies by content type).

Section 2: Overriding layouts on individual nodes

Once the default layout is in place, editors can still customize a specific node:

1. Edit a node of the configured type.
2. Click the "Layout" tab (appears after Layout Builder is enabled).
3. Choose "Override layout" and then modify sections, add or remove blocks, or change column widths.
4. Save the node. The override is stored as a separate configuration entity, e.g., layout_builder.layout__article__node__123.yml.

Because overrides are configuration, they can be exported with drush cex and imported to other environments, ensuring that a one‑off design tweak made on staging can be reproduced in production.

Worked example: adding a promotional banner

Suppose you want a banner that appears only on nodes tagged with the "promo" term.

1. Create a custom block (or use the core "Custom block" library) that contains your banner markup.
2. Enable the block’s visibility setting to "Show if the following conditions match" → "Taxonomy term" → "promo".
3. Return to the Layout Builder interface for the content type, add a new full‑width section at the top, and place the custom block inside it.
4. Save the layout. Nodes with the promo term will now render the banner; nodes without it will not.

To verify that the banner appears as expected, view a node that has the promo term and confirm the block renders in the top section. Then edit a node without the term and confirm the banner is absent.

Trade‑off: performance and debugging considerations

While Layout Builder reduces the need for custom Twig, it introduces a few operational trade‑offs:

• Render overhead: Deeply nested sections or many blocks per region increase the amount of PHP executed during page build. On high‑traffic pages, monitor response times (e.g., with drush qd or New Relic) and consider enabling Drupal’s internal page cache or a reverse proxy like Varnish.
• Configuration‑centric debugging: Layout overrides are not visible as template files; they live in the active config store. To inspect an override, export the relevant config (drush cget layout_builder.layout__article__node__123) or view the YAML under config/sync after a drush cex. If you need to revert an edit, you can delete the override config or re‑apply the default layout via the UI.
• Multi‑developer conflicts: Because layout configuration lives in the same sync folder as other site settings, concurrent edits can cause merge conflicts. Adopt a config‑split strategy (e.g., separating dev/, staging/, prod/) or use feature modules to lock layout configuration to specific environments.

Actionable closing

If your team needs a way for editors to compose pages without waiting for a developer to write Twig, start by enabling Layout Builder on a single content type. Define a sensible default layout, test the automatic cache invalidation by editing a field and observing the change appear without a manual cache clear, and then experiment with per‑node overrides. Keep an eye on render times and use configuration export to track layout changes in version control. With these steps, you gain the flexibility of a drag‑and‑drop builder while retaining the reliability and deployability of Drupal’s configuration system.