[meta] Improve the "Expose all fields as blocks to Layout Builder" feature

First of all, thank you for the excellent write up @rkoller and thanks to the UX team for evaluating this so thoroughly.

This sparked an idea which is basically the opposite of all of this, hindsight is 20/20 after all 😅

I think this should have been a feature flag, not configuration (see ✨ Add an API for feature flags Active )

We used configuration out of convenience, which turned into requiring a config form, upgrade path, config form tests and upgrade path tests. I don't think any of this was particularly necessary. The behavior when the checkbox is checked is undesirable, we simply added all those layers to keep BC and allow people to switch. However, if we continue with this then how do we eventually deprecate that functionality? It seems very challenging.

Instead, we could/should swap this configuration flag for a feature flag and ditch the settings form entirely. We would need to work out the ins and outs of how feature flag modules (this seems to be the consensus of how the feature flag API should work) are deprecated and communicated first, but I think that is a better path to go down than making this "Expose all fields as blocks to Layout Builder" setting more user friendly.

that is an interesting idea @acbramley! i would have two questions in regards of the feature flag api.

• what is the estimated timeline for getting that api into core? it doesn't look it would be ready for 10.3.0 and with 🐛 Reduce the number of field blocks created for entities (possibly to zero) Fixed already in core the problems outlined in issue summary for this issue would still apply to users for the time being until feature flags get in?
• and how would the feature flag work in the context of this feature? sites pre 10.3.0 would behave like the checkbox is ticked while sites after 10.3.0 would behave like the checkbox is unticked? if that assumption is correct, the only problem is see is the transition and upgrade from 10.2.x to 10.3.x. Currently you have the configuration page that sticks to the ticked state after the upgrade and the user/admin has to manually untick and switch the behavior. with a feature flag in place that option wouldn't (?) be available and the behavior would change with the upgrade to 10.3.0? isn't then there the danger of blocks being removed from layouts automatically as outlined in the change record?

@rkoller great questions.

what is the estimated timeline for getting that api into core?

The good thing about the solution design is that there's nothing we really need to do for the API - it already exists (modules). So mainly we just need to confirm how these things should be formatted. I.e how the module name should be constructed, and how we convey the information about the feature flag - e.g should we use a module description, hook help, or something else.

and how would the feature flag work in the context of this feature?

It would essentially replace the config check with a moduleExists check. All the current behaviours of upgrades vs new sites would be the same. Instead of setting the config in the upgrade path, we'd enable the module. New sites wouldn't have the module enabled by default so they would default to the new behaviour, etc.

Added 📌 Replace "Expose all fields as blocks to Layout Builder" configuration with feature flag Active

Using a feature flag module is definitely an interesting way of doing this.

When I think feature flags though, I'm thinking things which are experimental and might be merged in some day, because that's how web browsers like Chromium treat them, I think that'll mean a lot of people will already have that expectation. What we have here though doesn't quite fit that expectation, where we've added this option not as something which might one day be "on by default" but almost the opposite, to remove something which was causing problems.

Maybe before going ahead with this being a feature flag we should wait to see what we determine their purpose to be?

thank you @acabremley!

The good thing about the solution design is that there's nothing we really need to do for the API - it already exists (modules). So mainly we just need to confirm how these things should be formatted. I.e how the module name should be constructed, and how we convey the information about the feature flag - e.g should we use a module description, hook help, or something else.

that sounds way less complex and controversial than i've initially thought. i was slightly worried it might become a rather long going issue before an initial approach could get in. awesome!

It would essentially replace the config check with a moduleExists check. All the current behaviours of upgrades vs new sites would be the same. Instead of setting the config in the upgrade path, we'd enable the module. New sites wouldn't have the module enabled by default so they would default to the new behaviour, etc.

so the module would be the "switch" the equivalent to the current "checkbox" . but then the manual step before enabling the module for existing sites upgrading from 10.2 to 10.3 would still be necessary to make sure that it doesn't comes to an unintended removal of blocks in layout builder like in the example from the issue summary: "For example, if you have Layout Builder enabled on a Node bundle (Content type), and that bundle's display is using field blocks for the User entity (e.g the Author's name), but Layout Builder is not enabled for the User bundle, then that field block would no longer exist after disabling this setting." . but the danger for that case happening would be still imminent isnt it? so it might be necessary and an idea that those "feature flag" modules come along with a confirmation step pointing to potential issues the person installing has to be aware of and has to take care of before proceeding? that information step could be either informational like in the current example (where the preperational step might be too complex) or if possible that confirmation step might contain a configuration option that changes something? so that in some less complex cases the user would be able to alter something in place within the confirmation step preparing the site before going on?

re #7 and a good point @aaronmchale made. i wonder aside the fact to clearly define what the functionality should exactly do maybe also being mindful not to already use the current suggested name as the working label. i haven't paid close attention to the name yet but the example where feature flags is actually used for activating highly experimental features could be definitely misleading and creating wrong expectations. perhaps it should be considered to find a different name which describes the functionality better. maybe having a bulleted list outlining what the feature actually does might be helpful ideating on a suggestion which might be a better less misleading fit?

And I've added the feature flags api issue also as a related issue

but then the manual step before enabling the module for existing sites upgrading from 10.2 to 10.3 would still be necessary

No, there will be an automated upgrade path to enable the module for existing sites.

that those "feature flag" modules come along with a confirmation step pointing to potential issues the person installing has to be aware of and has to take care of before proceeding

I'm hoping that we can communicate this in the module description and/or help topics

WRT. what feature flags are/should/can be used for, I think it's very flexible. This would potentially be the first one in core, we can have that discussion in the other issues imo.

Part of me feels like, if we go down the feature flag route, it still has the same problem that the current checkbox does, in that a on/off checkbox is not really the best way to communicating the two options. So I'm leaning more towards that, whether we have this as a feature flag or not, it may be better to still have a form with the two radio buttons.

Is the Layout Builder Expose All Field Blocks (Deprecated) module the form feature flag modules will be presented to the users?

From a functional code perspective it looks like a clean approach. but on the other hand from a usability and end users point of view for one it feels like concepts are mixed here. on /admin/modules you usually have full fledged modules, technically those feature flag modules are in line with that but still they contain a single functionality that is getting discontinued and you are able to switch on and off deliberately. if you have several functions across core getting feature flags then the modules list quickly gets crowded. but the big worry i have is that folks probably won't read the description for the feature flag module nor they will be able to easily distinguish between a module and a feature flag module. And having a description for each state contained in that description makes it sort of lengthy and hard to grasp. by applying a radio button pattern like aaron suggested would mitigate that problem. when you install the feature flag module you get a linkThe Layout Builder Expose All Field Blocks module is deprecated. (more information) on the confirmation step pointing to https://www.drupal.org/node/3223395#s-layout-builder-expose-all-field-bl... → . if you search on that page for "layout" there is no match. The implications and the background about the why is not that clear to the user imho. and i think some of the points in the proposed resolution in this issue still apply at least in part and it might still be worth the thought implementing at least some of them?
Overall I wonder if it would make sense to add a new local task to the extend page and move all available feature flag module over there. To separate regular modules from feature flags? and on the tab for feature flags dont apply the checkbox pattern but instead introduce a new pattern where each of the listed feature flag modules has two radio buttons instead. makes the labeling easier more concise and clear?

I never followed this discussion, so I'm not entirely certain it's related by I have a suspicion it is. After upgrading to 10.3, I accepted the proposition and disabled the module. I was immediately greeted with "Entity view display 'xxx': Component 'yyy' was disabled because its settings depend on removed dependencies." warnings. A terrible excuse of an error message because it doesn't even try to identify the issue but by adding a debug printout, the actual dependencies are from Layout Builder, hence my suspicion. These views don't use Layout Builder, actually. Every single page refresh generates such warnings, so the log is literally inundated with them.

So, I just followed Google's trail here. There's no `/admin/config/content/layout-builder`at all, is this something that got removed in the meantime?

@djg_tram thank you for the message, this was covered in the CR for the original issue that changed this functionality https://www.drupal.org/node/3416592 →

This CR was outdated in that it was still referring to the setting that was originally developed. However, in your case, re-enabling the module will fix your issues once caches are cleared. I have now fixed this.

If you're still having issues, please open a bug report.

Thanks!

@djg_tram I actually just noticed the same error on a fresh Standard install of Drupal with Layout builder disabled. This warning is not related to this issue.

Seeing as 🐛 Reduce the number of field blocks created for entities (possibly to zero) Fixed has been closed, I'll ask here.

How are you meant to know if you can turn this module(/feature flag) off?

Is there a way to list all instances of field blocks being used where their layout builder option hasn't been enabled?

We should implement #16 in code as a status report message if the module is enabled but can safely be disabled.

I agree. I was worried about disabling the module, wondering if I would unknowingly break something.

I ended up disabling it, and then exporting config, to see if anything changed.

@solideogloria that's a great idea!

As for knowing whether you can disable it (without the great suggestion in #17) you could check if any of your view_display config that uses layout builder contains either field_block:ENTITY_TYPE_ID or extra_field_block:ENTITY_TYPE_ID blocks, where ENTITY_TYPE_ID is the machine name of an entity type that does NOT use layout builder.

If there are no field blocks in use, or only field blocks in use which have at least one bundle that uses layout builder, you can safely disable the module.

Fantastic replies.

I did consider #18, but didn't have enough information to know if this was thorough enough.

I think #19 is what I was originally asking for, so I will do #19, #18, and 🤞.

But #17 would be the ideal, for both the less technically competent, or (like me) time limited.