Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts

The root cause for this error is, that label and category are empty, but expected to be a string.
I had a look what this is caused by and it's:
layout_builder_blank provided by layout_builder module.

It happens when calling LayoutPluginManager::getLayoutOptions() for example to get the sorted options for a layout selection select (#options).

Perhaps we should throw an exception, if no label and category are given by a layout.yml?

Like the existing InvalidPluginDefinitionException here:

/**
   * {@inheritdoc}
   */
  public function processDefinition(&$definition, $plugin_id) {
    parent::processDefinition($definition, $plugin_id);

    if (!$definition instanceof LayoutDefinition) {
      throw new InvalidPluginDefinitionException($plugin_id, sprintf('The "%s" layout definition must extend %s', $plugin_id, LayoutDefinition::class));
    }

Here's a screenshot of the layout definition that's being sorted:

Any ideas?

Patch for Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php). error

#8 fixed the deprecated code error for me on the Paragraphs manage form display, although I don't see any empty layout settings except the default one that shows up after installing layout builder (and field layout?):

<option value="layout_builder_blank"></option>

But then I didn't get that same deprecated function error on another more vanilla D10 instance, so I'm not sure what's going on.

Patch in #8 with coding standards fixed.

Believe #6 was going the right track. Think there is a bug where label/category are empty. Think the fix should be there.

Possible duplicate of 🐛 strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated Needs work

#8 and #10 are nice quickfixed but shouldn't the blank layout better get sorted out generally for

  public function getLayoutOptions()

?

Can the subsystem maintainer give an answer perhaps?

Indeed I think 🐛 strnatcasecmp(): Passing null to parameter #1 ($string) of type string is deprecated Closed: duplicate is a duplicate and here's a contrib case where a workaround is already in place that I think shouldn't be needed: 🐛 layout_builder_blank must not be disabled Fixed

The following class should either implement all Plugin requirements like label and group or be removed before such calls, shouldn't it?

<?php

namespace Drupal\layout_builder\Plugin\Layout;

use Drupal\Core\Layout\LayoutDefault;

/**
 * Provides a layout plugin that produces no output.
 *
 * @see \Drupal\layout_builder\Field\LayoutSectionItemList::removeSection()
 * @see \Drupal\layout_builder\SectionListTrait::addBlankSection()
 * @see \Drupal\layout_builder\SectionListTrait::hasBlankSection()
 *
 * @internal
 *   This layout plugin is intended for internal use by Layout Builder only.
 *
 * @Layout(
 *   id = "layout_builder_blank",
 * )
 */
class BlankLayout extends LayoutDefault {

  /**
   * {@inheritdoc}
   */
  public function build(array $regions) {
    // Return no output.
    return [];
  }

}

I updated the issue summary, so that the steps and root cause should be clearer now.

It seems as like the LayoutPluginManager (DI-injected by $container->get('plugin.manager.core.layout'),) is entirely missing FilteredPluginManagerTrait, so that its alterations are never being called:

This is not entirely true. The plugin manager uses FilteredPluginManagerTrait but the getSortedDefinitions() method that is indirectly called from getLayoutOptions() does not use the getFilteredDefinitions() method to retrieve the layout definitions.

I will create a MR with a fix for this. But I'm not sure about unintended side effects so input from the subsystem maintainer(s) is still appreciated.

@ricovandevin thank you!

This is not entirely true. The plugin manager uses FilteredPluginManagerTrait but the getSortedDefinitions() method that is indirectly called from getLayoutOptions() does not use the getFilteredDefinitions() method to retrieve the layout definitions.

Absolutely. That was just an idea what kind of issue might cause this. Technically it was definitely not the correct final anwser, just a pointer into that direction ;)

Thanks for your help and clarification! Let's see what the tests say.

just a pointer into that direction ;)

@Anybody It absolutely pointer me in the direction of getFilteredDefinitions()! :-)

Apparently I cannot edit the MR. So hereby a patch that makes getSortedDefinitions() use the getFilteredDefinitions() method.

Triggering tests...

I was a bit too fast on this. The patch in #22 is not solving the issue. Must have missed a cache rebuild when testing this earlier.

@ricovandevin just create a separate MR, I think?

Updated the MR. Had to "get push access" first.

There are two lines in which definitions are loaded. Replaced both by the filtered version. Patch attached for use with Composer.

Thanks @ricovandevin that looks promising, let's wait what the tests say. By the way I think to prove this, we should add a simple test which calls $layoutPluginManager->getLayoutOptions() and ensures only the expected layouts are included?

Agree on the tests but #26 also had an existing test failure.

Thanks for the patch. It works on D10.1

The patch didn't work to resolve the error. I ended up trying a different approach, which seems to have resolved the issue.

Can you elaborate on why the patch didn't work to resolve the error? I just tested it locally on 10.1.x and the error was resolved. Is it not working in 11.x then?

#26 works in Drupal 10.2.1 with php 8.1.27

Micro-nit fix for #30: changing "null" to "NULL"

Same problem in drupal 10.2.2 comment #33 was very useful to me

Reroll #30

@Anybody:

Thanks for the detailed analysis in the issue summary. I agree that casting to string or using the null-coalesce operator would be fixing the symptom instead of the root cause.

The problem with using getFilteredDefinitions() in LayoutPluginManager is that you are specifying $consumer that works for this case, but that Core class can be used anywhere in Drupal. When the block module calls getSortedDefinitions(), why should it invoke the hook from the layout_builder module? Related: when I search for getFilteredDefinitions(), I find that it is called in a few placed in the layout_builder module.

I think you missed one point: LayoutDefinition::getCategory() declares its return type as string|\Drupal\Core\StringTranslation\TranslatableMarkup. It is not allowed to return null. So adding a category to the BlankLayout plugin annotations is the correct fix.

I will prepare a merge request that does that. I will also add any other annotations that seem to be required, and make the @param comment for getSortedDefinitions() more specific.

On second thought, the @param comment for getSortedDefinitions() comes from the interface, so it is not so easy to make it more specific. Maybe we should, but not for just this plugin type.

I added annotations for label and category. I considered adding a description, since getDescription() has the same return type declaration, but the annotation class specifically says that $description is optional. And then there is $templatePath. (shrug)

I am updating the steps to reproduce and the proposed resolution in the issue summary.

I am also attaching a patch for convenience.

I am removing the "Needs tests" issue tag. I do not think we need to test this.

BTW, @longwave commented in #3316811-8: strnatcasecmp(): Passing null to parameter #1 ($string) of type string is deprecated → :

It appears there is a plugin with a NULL label somewhere, it would be good to know exactly which plugin that is, and whether it is a core issue, or contrib or custom code.

benjifisher → credited tawellman → .

In #3315678-27: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated → , @tawellman posted a stack trace that showed the (core, experimental) field_layout module. Using that, I can reproduce the error using just Drupal core. I am updating the steps to reproduce in the issue summary here, closing the other issue as a duplicate, and giving credit to @tawellman on this issue.

It might be appropriate to give credit to some of the others who commented on that issue.

Reading through the patches it is unclear which solution is recommended. The patches seem quite different for example #40 is different from those that precede it and the MR. Which MR is the one to use?

smustgrave → changed the visibility of the branch sorted-definitions-safety to hidden.

smustgrave → changed the visibility of the branch 11.x to hidden.

smustgrave → changed the visibility of the branch 3392572-deprecated-function-strnatcasecmp to hidden.

Looking at the MR and the proposal to add missing annotation seems straightforward.

Not sure this needs a follow up to catch these later? Not tagging as I'm not sure.

📌 Convert Layout plugin discovery to attributes Active will change this anyway, so I suggest we make the label and category properties required over there.

If we believe layout_builder_plugin_filter_layout_alter() is not being called I think we at least need a followup to investigate that.

In further testing, I noticed that I can reproduce the problem using the Standard profile if I enable the field_layout and layout_builder modules.

I also noticed what @Anybody meant in the issue summary:

This should also solve the side-effect of layout_builder_blank appearing in selects!

With 11.x, I do not see that option, but if I fix the plugin annotations and visit /admin/structure/types/manage/article/form-display, then layout_builder_blank appears in the Layout settings form near the bottom of the page. I think this counts as a regression, which means we cannot defer it to a follow-up issue. I am reverting the issue title to what it was before Comment #47 and removing the tag for a follow-up. While I am at it, I am changing the issue priority.

I already updated MR 6533. I think this is the least disruptive fix: call getFilteredDefinitions() in LayoutPluginManager::getLayoutOptions(). The only problem is that we do not know which $consumer to pass as the first argument, so I just use $this->getType(). This ends up invoking both hook_plugin_filter_layout_alter and hook_plugin_filter_layout__layout_alter.

We should consider other approaches:

1. Add an optional parameter to LayoutPluginManager::getLayoutOptions() and pass it to getFilteredDefinitions(), using $this->getType() as a fallback.
2. Make $consumer optional, and invoke just the first hook if it is not provided.

I will mention these options in the issue summary. Maybe the safest approach is to use the current fix and then implement (1) in a follow-up.

#10 works for my on core 10.1.8, but also using on a few other projects. Need this patch in order to create new panels page.

So this still in review to decided on the approach and what can be a follow up, least that's how I read the last part of #50.

Dear promoters,
I have incorporated patch #10. It works for. I would like to take this opportunity to thank all the staff from the bottom of my heart for their work here in this community.

Opened 📌 Explore additional approaches to handle missing ID or Category in layout plugin Active to explore additional approaches. But agree with @benjifisher that the current MR does fix the error here.

I think we should be adding test coverage of the changes to getLayoutOptions().

@alexpott:

Thanks for the review!

I do not know the plugin system as well as I would like. I guess the @ingroup plugin_translatable in Drupal\Core\Layout\Annotation\Layout is what tells us that the annotation should be translatable? I could not find the documentation for that. But I added a commit with what I think you meant.

I started to add a test to Drupal\Tests\Core\Layout\LayoutPluginManagerTest, but as soon as I call getLayoutOptions() from that test, I get a ServiceNotFoundException for the theme.manager service. This comes from FilteredPluginManagerTrait:

      protected function themeManager() {
        if (property_exists($this, 'themeManager') && $this->themeManager instanceof ThemeManagerInterface) {
          return $this->themeManager;
        }

        return \Drupal::service('theme.manager');
      }

The problem is that Drupal\Core\Layout\LayoutPluginManager does not have a $themeManager property. It does have a $themeHandler property, which it uses, but just to add some confusion the constructor has the misleading comment

       * @param \Drupal\Core\Extension\ThemeHandlerInterface $theme_handler
       *   The theme handler to invoke the alter hook with.

I think we should inject the theme.manager service into LayoutPluginManager. That seems outside the scope of this bug-fix issue. I am not sure how best to manage the scope, but here are some options:

• In this issue, just add the annotations. Accept the regression ("Blank layout" appears in the list) for now, and fix it in a follow-up issue after injecting the theme.manager service.
• Add test coverage as part of this module, but use a kernel test instead of a unit test. Can kernel tests go in core/tests/Drupal/Tests/Core? If not, where do we put the test?
• Postpone this issue on the one to inject the theme.manager service.

The code proposed in the MR did not solve the deprecated issues for me.

In our case we moved the 'Block Description' outside of the Form Display of a bunch of block types.

We didn't know that disabling Block Description would result in lots of Blocks with empty Admin Labels.

As a result, when we click to "Create a new block" in Layout Builder, lots of "Deprecated" messages are being logged:

Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Block\BlockManager->Drupal\Core\Plugin\{closure}() (line 95 of /var/www/web/core/lib/Drupal/Core/Plugin/CategorizingPluginManagerTrait.php)
#0 /var/www/web/core/includes/bootstrap.inc(164): _drupal_error_handler_real(8192, 'strnatcasecmp()...', '/var/www/web/co...', 95)
#1 [internal function]: _drupal_error_handler(8192, 'strnatcasecmp()...', '/var/www/web/co...', 95)
#2 /var/www/web/core/lib/Drupal/Core/Plugin/CategorizingPluginManagerTrait.php(95): strnatcasecmp('', NULL)
#3 [internal function]: Drupal\Core\Block\BlockManager->Drupal\Core\Plugin\{closure}(Array, Array)
#4 /var/www/web/core/lib/Drupal/Core/Plugin/CategorizingPluginManagerTrait.php(96): uasort(Array, Object(Closure))
#5 /var/www/web/core/lib/Drupal/Core/Block/BlockManager.php(76): Drupal\Core\Block\BlockManager->traitGetSortedDefinitions(Array, 'admin_label')
#6 /var/www/web/core/lib/Drupal/Core/Plugin/CategorizingPluginManagerTrait.php(105): Drupal\Core\Block\BlockManager->getSortedDefinitions(Array, 'label')
#7 /var/www/web/core/modules/layout_builder/src/Controller/ChooseBlockController.php(181): Drupal\Core\Block\BlockManager->getGroupedDefinitions(Array)
#8 /var/www/web/modules/contrib/layout_builder_restrictions/src/Controller/ChooseBlockController.php(42): Drupal\layout_builder\Controller\ChooseBlockController->inlineBlockList(Object(Drupal\layout_builder\Plugin\SectionStorage\OverridesSectionStorage), 0, 'blb_region_col_...')
#9 [internal function]: Drupal\layout_builder_restrictions\Controller\ChooseBlockController->inlineBlockList(Object(Drupal\layout_builder\Plugin\SectionStorage\OverridesSectionStorage), '0', 'blb_region_col_...')
#10 /var/www/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#11 /var/www/web/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#12 /var/www/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#13 /var/www/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#14 /var/www/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#15 /var/www/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#16 /var/www/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /var/www/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /var/www/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/www/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /var/www/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#28 {main}

The patch suggested here: https://www.drupal.org/project/drupal/issues/3316811#comment-14796459 🐛 strnatcasecmp(): Passing null to parameter #1 ($string) of type string is deprecated Closed: duplicate does solve our issues.

@carolpettirosi:

Your problem is different from the one in this issue: your stack trace shows that strnatcasecmp() was called in core/lib/Drupal/Core/Plugin/CategorizingPluginManagerTrait.php. This issue deals with the same function called in core/lib/Drupal/Core/Layout/LayoutPluginManager.php.

Just as we have been discussing on this issue, you should look at the stack trace and decide what is the right place to fix the error. It is easy to add ?? '' whenever you use strnatcasecmp(), but that may be hiding the real problem instead of fixing it.

The function strnatcasecmp() is used many times in the codebase:

$ grep --recursive --count strnatcasecmp core | grep -v :0$ | sort
core/lib/Drupal/Component/Utility/SortArray.php:1
core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php:1
core/lib/Drupal/Core/Datetime/Entity/DateFormat.php:1
core/lib/Drupal/Core/Entity/EntityDisplayModeBase.php:1
core/lib/Drupal/Core/Language/Language.php:1
core/lib/Drupal/Core/Layout/LayoutPluginManager.php:2
core/lib/Drupal/Core/Plugin/CategorizingPluginManagerTrait.php:2
core/lib/Drupal/Core/Plugin/DefaultLazyPluginCollection.php:1
core/lib/Drupal/Core/Test/TestDiscovery.php:2
core/modules/config/src/Form/ConfigSingleExportForm.php:1
core/modules/config/src/Form/ConfigSingleImportForm.php:1
core/modules/config_translation/src/Controller/ConfigTranslationEntityListBuilder.php:1
core/modules/config_translation/src/Controller/ConfigTranslationMapperList.php:1
core/modules/filter/src/FilterPluginCollection.php:1
core/modules/help/src/Plugin/HelpSection/HelpTopicSection.php:1
core/modules/shortcut/src/Entity/Shortcut.php:1
core/modules/system/src/Entity/Action.php:1
core/modules/workspaces/src/WorkspaceRepository.php:1
core/node_modules/@cspell/dict-cpp/dict/cpp-legacy.txt:1
core/node_modules/@cspell/dict-cpp/dict/cpp.txt:1
core/node_modules/@cspell/dict-php/dict/php.txt:1

Let's not try to handle all of them in this issue.

Tested on core 10.2.4 and works.
Error message no longer displaying.
Used patch created from MR https://git.drupalcode.org/project/drupal/-/merge_requests/6533.patch
See attached.

Hi @ pasan.gamage No luck for me at all. I used this patch #61. Any comments or how I will make it work? Thanks!

Error message
Deprecated function: strnatcasecmp(): Passing null to parameter #1 ($string1) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).
Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).
Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).
Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).
Deprecated function: strnatcasecmp(): Passing null to parameter #1 ($string1) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).

@smethawee:

Did you clear caches after applying the patch?

Do you have any custom or contrib modules that define layouts using PHP classes? The patch fixes core/modules/layout_builder/src/Plugin/Layout/BlankLayout.php, but you might have files like mymodule/src/Plugin/Layout/MyLayout.php with the same problem.

Thank you for your asked @benjifisher

Yes, I did drush cr after applied the path. and No, I don't have any custom or contrib modules hat define layouts using PHP classes.
So I need to working on it to work out.

Thanks!

Per #17 📌 Convert Layout plugin discovery to attributes Active on 📌 Convert Layout plugin discovery to attributes Active , labels should be added to all existing layout plugin definitions that are missing them (including a new on in Navigation), and deprecation warning triggered for contrib/custom plugins missing labels (and categories, as well. Blocking this issue on 📌 Convert Layout plugin discovery to attributes Active for the Layout attribute class to get in.

Is there a reason we don't quickly fix this with a change like in the merge request or #10? A more complicated change could be done in a follow-up. For now, we should do a simple, reliable change that fixes the deprecation message.

Since 📌 Convert Layout plugin discovery to attributes Active is Fixed, we can un-postpone this issue.

It looks as though the MR has some conflicts that need to be resolved, so I am setting the status back to NW, not NR.

Merge request has been rebased.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

@Liam Morland: I had a look at your commits. It looks as though you switched from attributes to annotations, reversing the change from 📌 Convert Layout plugin discovery to attributes Active . Let's stick with attributes.

I updated the MR and added some test coverage, as requested in Comment #55. I hope it is enough: in a unit test, I confirm that the alter() methods from the module handler and the theme manager are called, with the expected arguments, during the execution of getLayoutOptions(). I could also add a kernel test that confirms the expected effect on the result of getLayoutOptions().

I am also updating the Proposed resolution section of the issue summary.

Hiding patches for clarity.

Added a super nitpicky :void return

But appears the thread for adding test coverage has been addressed.

I skimmed the issue summary and at first thought the proposed resolution was a set of options. It is really the implemented solution. I also confirmed the problem exits in 10.2 and 11.x. I read the comments and didn't find any unanswered questions.

I looked at the MR and made one small suggestion.

What this does need is a title update to something sensible for the git log. Maybe 'Get layout options only for filtered layout plugins"? I am not sure though.

Update credit

@quietone:

Thanks to you and @smustgrave for the updates to the MR.

The original title is just the error message we are fixing, Except for the "in LayoutPluginManager" at the end, it is an error message that comes up a lot (as some of the comments on this issue remind us). I agree that the title (and the commit message) should be more specific.

It is a little tricky since this issue makes two changes: the first change fixes the error, and the second change fixes a regression caused by the first change. I am updating the title to mention both, and I am reusing some text from the doc block of the test I added.

While testing this issue, I noticed that the experimental navigation module adds a layout option with a category but no label, so I added 🐛 Add missing 'label' key to navigation.layouts.yml Active .

I added 📌 Make $consumer optional in Drupal\Core\Plugin\FilteredPluginManagerTrait::getFilteredDefinitions() Active as a follow-up issue. I am updating (shortening) the "Proposed resolution" section of the issue summary here: since this issue is RTBC, I assume for now that we agree that should be done in a follow-up issue, not as part of this one. For the record, here is the alternative I suggested, now also removed from the issue summary:

Add an optional parameter to LayoutPluginManager::getLayoutOptions() and pass it to getFilteredDefinitions(), using $this->getType() as a fallback.

There was follow up work needed from [#3420983} to make label and category properties required (see #65 🐛 Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts RTBC ). The thought was to do it in this issue, but if it's out of scope here, I think a new follow up needs to be created to address that.

One thought is that perhaps category does not need to be required, but we can follow the approach in Drupal\Core\Plugin\CategorizingPluginManagerTrait\processDefinitionCategory(), where the fallback category is the provider name.