Lb config recipes

14. Configuration Export & Recipes

When to Use

When deploying Layout Builder configuration across environments, creating reusable layout patterns, or managing LB config in version control.

Steps

Export Layout Builder Config

# Export all config
drush cex

# LB config stored in entity_view_display
# Example: config/sync/core.entity_view_display.node.article.default.yml

Review Exported Config

# core.entity_view_display.node.article.default.yml
uuid: abc-123
langcode: en
status: true
dependencies:
  config:
    - field.field.node.article.body
    - node.type.article
  module:
    - layout_builder
    - user
third_party_settings:
  layout_builder:
    enabled: true
    allow_custom: false
    sections:
      - layout_id: layout_twocol_section
        layout_settings:
          label: ''
        components:
          - uuid: component-uuid-1
            region: first
            configuration:
              id: 'field_block:node:article:body'
              # ... full block config
            weight: 0

Create Recipe for Reusable Pattern

# recipes/article_layout/recipe.yml
name: 'Article Two-Column Layout'
description: 'Applies two-column layout to article content type'
type: Content
recipes:
  - core/recipes/article_with_body
install:
  - layout_builder
config:
  import:
    core.entity_view_display.node.article.default: '*'

Import on Target Environment

# Import all config
drush cim

# Or apply recipe
drush recipe recipes/article_layout

Handle Inline Blocks
Inline blocks stored as content (in block_content entities), not config
Default layouts can include inline blocks via serialized data in config
Per-entity overrides with inline blocks require content sync (not config-only)

Decision Points

At this point...	If...	Then...
Planning export	Using defaults only	Clean config export, no content dependencies
Planning export	Using overrides with inline blocks	Need content sync (structure_sync, default_content, migrate)
Creating recipe	Layout for single bundle	Include entity_view_display config in recipe
Creating recipe	Layout for multiple bundles	Include all relevant view displays or use config actions
Version control	UUIDs change on re-export	Not an issue — UUIDs in component config, not entity config UUID
Multi-environment	Different inline block IDs	Use serialized blocks in defaults, avoid per-entity overrides in recipes

Common Mistakes

Forgetting dependencies → LB config depends on fields, entity types, modules. Export dependencies or target import fails
Not testing import on fresh site → Test recipe on clean install to verify all dependencies included
Mixing config and content → Defaults are config (exportable). Overrides are content (harder to deploy). Document which is used
Hardcoding UUIDs → Component UUIDs can be arbitrary. Don't depend on specific UUID values in custom code
Ignoring inline block complexity → Inline blocks in defaults use serialized data (portable). In overrides, they're separate entities (not portable via config)
Not using recipes for distribution → Recipes make LB config reusable across sites. Don't manually copy YAML files
Exporting with overrides enabled → allow_custom: true in config affects all environments. Consider per-environment config splits