Problem/Motivation
While working on the Layout Library module, I discovered that Layout Builder is basically incompatible with any layout storage strategy except for its two built-in ones, which are "defaults" (storing a layout in an entity view display) and "overrides" (storing a layout in a field on a content entity).
The problem comes down to the getRuntimeSections() method of \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay:
protected function getRuntimeSections(FieldableEntityInterface $entity) {
if ($this->isOverridable() && !$entity->get('layout_builder__layout')->isEmpty()) {
return $entity->get('layout_builder__layout')->getSections();
}
return $this->getSections();
}
This code is rooting around in internal implementation details of both the defaults and overrides storage plugins. It is completely unaware of any other layout storage strategy -- which, as I understand it, was the entire point of making layout storage pluggable in the first place -- yet it pretty much controls how layout-able entities are rendered. This code kinda renders the entire idea of "section storage plugins" moot.
Proposed resolution
getRuntimeSections() needs to relax. I'm not 100% sure how to best approach this, but the thinking right now is that it should try to retrieve layout sections from, well, the layout section storage plugin system. That is -- it should try to get layout information from the actual section storage plugins, via their plugin manager.
Remaining tasks
Discuss, implement, iterate, and finally figure it out and commit it with tests. Party time!
User interface changes
TBD, but unlikely.
API changes
TBD, but hopefully none.
Data model changes
TBD, hopefully none.