Problem/Motivation
Probably a bit of an edge-case, but I've found that Layout Builder Style (LBS) selections are sometimes not saved/applied if the block form in question includes an
Inline Entity Form →
(IEF) complex widget. I suspect the same would hold true for the simple widget, but haven't explicitly tested that.
The set-up: I have a custom block type called Cards whose sole job is to be a container for Card entities. The child entities are styled based on a required 'Card Type' Layout Builder Style selection. The Cards block has a single entity reference revisions field that uses the complex IEF widget to add child Card entities. If I add Card block (inline) to a layout AND interact with the IEF widget in any way (add, remove or duplicate entities), any style selections/changes I also make are not saved.
At the moment I'm using
microcode →
for the Card entities, but I've also tried other entity types (paragraphs,
micro-content →
, other custom blocks) with the same result.
Steps to reproduce
Given the set-up above:
- Add a new page (with layout overrides enabled)
- Go to Layout
- Add a Cards block
- Create a couple Card entities via the IEF widget
- Select a Card Type (the Layout Builder Style)
- Click 'Add block'.
The selected Card Type style class does not appear in the block wrapper markup.
If I then 'Configure' the block, the Card Type I selected is gone. I can then re-select the Card Type and, provided I don't make any changes via the IEF widget, I can 'Update' the block and the selected style's class appears in the markup.
Proposed resolution
Not sure yet. Initial debugging indicates that the Layout Builder Styles submit handler _layout_builder_styles_submit_block_form() is never called in these cases. My first inclination was that IEF is doing something that interferes with the Layout Builder Styles submit handler, and that may well be the case. But this comment from layout_builder_styles.module made me wonder if LBS should be doing something to get ahead of other modules that might also interact with submit handlers:
// Our submit handler must execute before the default one, because the
// default handler stores the section & component data in the tempstore
// and we need to update those objects before that happens.
array_unshift($form['#submit'], '_layout_builder_styles_submit_block_form');
I'll provide more information as time allows to dig further, but thought I'd go ahead and post in case anyone has insights or runs into this.
Remaining tasks
Figure out what's going on.
User interface changes
?
API changes
?
Data model changes
?