Problem/Motivation
The 'label' and 'category' keys are required.
This came up in #3392572: Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts and #3450760: Add missing 'label' key to navigation.layouts.yml. There was a thought to make the two keys required in the annotation to attribute conversion in #3420983: Convert Layout plugin discovery to attributes, per #2 and #17:
I think we should consider a BC layer where we add a label for unlabelled layouts and trigger a deprecation.
, but then it was kicked back to be done in #3392572: Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts, and finally decided to do a separate follow up, which is this issue.
The most direct way to address would be to make the Layout attribute label and category properties required, but some considerations:
- Are there uses cases where layout plugin derivers provide label or category?
- CategorizingPluginManagerTrait::processDefinitionCategory() provides a default category of the provider module name or machine name when the plugin definition is an array. Layout plugin definitions are objects, not arrays, but something similar can be implemented so that the same default category is assigned to the plugin definition when the plugin manager processes the definition
Steps to reproduce
Proposed resolution
- Add label to any current existing core layouts without one
- Trigger deprecation on any layouts that do not have a label
- In LayoutPluginManger:: processDefinition(), add a default category of the plugin provider (see CategorizingPluginManagerTrait::processDefinitionCategory())
- Investigate whether there are use cases for derivers providing plugin labels