Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points

acbramley → closed merge request !4171

Discussed this with @DanielVeza and we agreed to reduce the scope somewhat.

The configurable block to replace the existing field block work can be done separately as that's going to present some major UX challenges that we'll likely need a few rounds of testing on.

Added 📌 [PP-1] Move away from derivatives for FieldBlock and instead use block settings Postponed to split that out into its own separate issue and refined the scope/proposed resolution here.

I've just had to implement something for a client - the goal was to (almost) completely hide the complex content field block label/formatter settings from site editors who are using layout builder on a single entity, while still allowing site builders to configure defaults for those settings.

We wound up with a custom field block plugin that takes its ::build() formatter settings from a dedicated 'layout_builder' view mode on the entity, and does not add elements for those in ::form etc. That works nicely and re-uses existing mechanisms.

It would have been great to take those formatter settings from configured display settings on the current view mode, but baked-in core assumptions make that hard:

• Layout Builder hides and unsets the fields list in Manage Display.
• It is not possible to configure disabled fields in Manage Display – 🐛 Lost user input when attempting to configure disabled fields on entity displays Needs work

For site builders, it would be no great leap if they could just configure defaults where they normally would for the entity display, and maybe there is a permission or other toggle associated with layout builder block configuration that either:

• Hides the configuration and uses those existing defaults, or
• Shows the configuration, populated by those defaults

What happens if somebody turns that flag off on a site with legacy layout builder content?

The expectation is that if you wanted the new mode, you'd configure all the blocks for the new approach, then toggle off legacy mode.

OK so legacy mode means "keep existing layout builder block instance config", and the new configured layout builder block is available to configure and use whether that is checked or not? The issue summary implies that's only available if legacy mode is checked.

Can sites keep using existing editor-configured blocks, while adding and using some preconfigured blocks? I can see this being a slow transition for sites with limited resources but lots of existing content.

Yeah that's the plan.

When you switch off legacy mode, the list of blocks shown in the 'choose block' list will draw from the preconfigured ones only.

The content will remain as is. 📌 [PP-1] Move away from derivatives for FieldBlock and instead use block settings Postponed will likely have a more interesting migration path.

OK and when you switch off legacy mode, existing legacy block instances will remain in the layout, but you wont be able to add new legacy blocks. Gotcha.

I discussed this issue with @catch and got inspired to try if we could try to create a runtime BC layer for the block derivatives. I started writing a PoC for the field blocks because they had more complex derivatives. It's not pretty for sure but wanted to post it here for visibility.

#18 is very clever indeed, I can't think through all the implications yet, but if we can drop the derivatives and shim the new plugin, and then also encourage people to change their layout config, that would be amazing - can fix both the performance and UX issues much, much quicker that way.

#18 very neat

So … should we continue #18? 😄

Yes it would be ideal - being able to just drop the existing plugin on existing sites (or at minimum have a killswitch for it which any site can safely turn on) makes the entire process easier, so it's just... all the other bits to do here.

Just wanted to add that the new navigation layout builder may also be able to use this instead of the hard-coded list of allowed blocks. https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/navig...

As @trackleft2 mentioned, the navigation module would also benefit from this work. That's being tracked in 📌 Provide a way for other modules to flag block plugin implementations as 'navigation safe' Active .

Although I wonder if the proposed resolution here would cover our use case. The use case for the navigation module is one where we want developers working on new blocks to opt-in their block to be used for Navigation. We currently do this in navigation module by implementing hook_plugin_filter_TYPE__CONSUMER_alter, and filtering out all blocks except a hardcoded list of exceptions. 📌 Provide a way for other modules to flag block plugin implementations as 'navigation safe' Active is currently looking at using a hook to be able to add / alter that hardcoded list. Would the proposed resolution here solve for our problem as well?

I'm removing the blocker tag because since it was added, we've decided to use LB minimally in Drupal CMS. It would still be nice to have, but since 📌 Provide a way for other modules to flag block plugin implementations as 'navigation safe' Active is fixed, the only thing this really affects is dashboard config. Since we are shipping with a default config, exposure to users will be quite minimal.