Layout builder cannot recover on missing layout

Created on 18 March 2021, over 3 years ago
Updated 19 July 2024, 4 months ago

Problem/Motivation

After renaming a layout, or after switching to a branch where a given layout does not exist, any attempt to fix the layout configuration will fail.

Steps to reproduce

Create a custom layout.
Create a layout builder configuration using that custom layout.
Remove or rename the custom layout.
Attempt to edit the layout builder configuration form, OR try to use "drush cim" to revert to a configuration where this layout was not used.

Expected: Layout builder config can be repaired.
Actual: Error.

The "layout_xyz" plugin does not exist. Valid plugin IDs for Drupal\Core\Layout\LayoutPluginManager are: ...

Proposed resolution

Use try/catch in strategic places to recover from this.

Remaining tasks

See tags

User interface changes

API changes

Data model changes

Release notes snippet

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
Layout builderΒ  β†’

Last updated 2 days ago

Created by

πŸ‡©πŸ‡ͺGermany donquixote

Live updates comments and jobs are added and updated live.
  • Blocks-Layouts

    Blocks and Layouts Initiative. See the #2811175 Add layouts to Drupal issue.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¦πŸ‡ΊAustralia alex.skrypnyk Melbourne

    This is potentially related to https://www.drupal.org/project/drupal/issues/2860346 πŸ› Reset plugin discovery when a module/theme is installed Needs work

    The definitions are cached during a theme install.

    If a theme provides custom layouts and has configuration objects that use those layouts (like `entity_view_display`), the layouts plugin definitions will already be cached and newly installed layouts will not have a chance to be discovered during the process of the theme installation.

    Adding a cache tag that depends on installed extensions resolve this issue.

    In LayoutPluginManager:
    $this->setCacheBackend($cache_backend, $type, ['config:core.extension']);

    Patch attached.

  • πŸ‡§πŸ‡ͺBelgium herved

    For me #20 doesn't work.
    I have a theme that is already installed, and some configs using it (in config_sync).
    When I change a layout machine name and attempt to clear cache and config import, it fails.
    #16 and #3 are working though.

  • πŸ‡¨πŸ‡­Switzerland boregar

    #20 worked for me on a fresh install with CivicTheme 1.6.2 on Drupal Core 10.2.3. Thanks!

  • πŸ‡ΊπŸ‡ΈUnited States Kristen Pol Santa Cruz, CA, USA

    I used patch #20 on Drupal 10.3.0 and CivicTheme 1.7.1 and the fatal error went away.

  • πŸ‡ΊπŸ‡ΈUnited States Kristen Pol Santa Cruz, CA, USA

    It would be great if someone wanted to review the different approach in #20, update the issue summary, and add tests :)

Production build 0.71.5 2024