Replace "Expose all fields as blocks to Layout Builder" configuration with a feature flag module

This is a very good idea and the diffstat also shows how much it simplifies things compared to using custom config. I think we should go ahead here, and whether or not we use feature flags for many other things can be figured out in ✨ Add an API for feature flags Active .

We should have a follow-up to deprecate the module too.

So moving the settings to flags how would that work for configuration exports and schema validation? Would flags be exportable?

Change looks neat and can think of a few other tickets that could use this. Probably need to get in before 10.3 to avoid having to do a update hook to remove the config.

@smustgrave in this case the flag is just whether a module is enabled or not - so it's all controlled by the extension config object with no new infrastructure.

Couple of questions on the MR.

+1 for more "zero config", which indeed requires more tightly focused modules to be installed. (A very similar example is how https://www.drupal.org/project/big_pipe_sessionless → is a contrib module with zero settings that upon installation provides one very specific feature on top of core's big_pipe module. That is very similar to the structure/approach what's being proposed here.)

Seems to cause a few test failures.

Just reporting the comment I just made on the parent issue because it's equally relevant here:

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.

Fixed the legacy tags and it's back to green.

Feedback appears to be addressed.

I don't see how this can be rtbc until ✨ Add an API for feature flags Active has been agreed. I'm +1 on the approach but there are still outstanding questions on the parent issue.

I personally think we should go ahead here, and then if we add a new package, extensions page filter etc. in the other issue (or spin-offs from that issue), the module added here can be brought up to date with those when they happen.

If we don't do this before 10.3.0, we have config to deprecate/remove in updates etc. to worry about.

@catch has convinced me that doing this now and before 10.3 is in our interest due to update functions. We can update the module's package etc later.

Gave this another once-over.

I agree we'll probably need to change this once ✨ Add an API for feature flags Active is resolved, but it'll be much easier to tweak the package and maybe hook_help() etc. than it will to make this change once the existing config has made it into a tagged release - we're saving ourselves 2-3 update hooks if we do it in this order as well as introducing then removing translatable strings etc.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!

Amazing! Thanks guys

acbramley → closed merge request !7142

Automatically closed - issue fixed for 2 weeks with no activity.