Layout builder cannot recover on missing layout

Created on 18 March 2021, almost 4 years ago
Updated 16 July 2023, over 1 year ago

NOTE: For us this problem occurs with Drupal 8.9.13. I have not confirmed yet if it happens in 9.x.

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 1 day 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

Merge Requests

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 :)

  • First commit to issue fork.
  • Pipeline finished with Failed
    6 days ago
    Total: 405s
    #409568
  • Pipeline finished with Failed
    6 days ago
    Total: 114s
    #409582
Production build 0.71.5 2024