How to filter block_editor_settings & global styles settings

[oandregal]

In the server, there's a filter named block_editor_settings that is used to allow 3rd parties to hook into the settings passed to the post editor. It's not clear yet if the other editors should use this as well (site editor, widgets editor, etc) ― edit: some clarity about this at WordPress/wordpress-develop#1118

What's the issue

When landing the theme.json support in core, we're going to change the settings format passed down to the editor: some things will be removed because they're substituted by new fine-grained settings provided by theme.json.

For example, if a theme opts-in into the editor-color-palette, that becomes the colors setting in the editor at the moment. However, this is absorbed by theme.json in which themes can create different color palettes by block ― hence the colors settings are no longer passed down to the editor.

Right now, we do:

1. In edit-form-blocks.php, we take the theme supports and then run the block_editor_settings filter for 3rd parties to hook into.
2. In global-styles.php (which hooks into the filter), we take the filtered theme supports and migrate them to the new format. We also unset the old ones.

The issue with this is that we don't allow 3rd parties to filter the theme.json settings #27504 A second issue is that if we want to change the settings format we're breaking backward-compatibility with 3rd party plugins.

[oandregal]

In a conversation with @youknowriad one option we discussed was to do:

1. In edit-form-blocks.php, we still take the old theme supports and apply the block_editor_settings filter.
2. Plugins hook into the filter.
3. In edit-form-blocks.php, after running the filter, we migrate the old theme supports to the new format.
4. Apply a new filter if we want 3rd parties to be able to hook into the new format as well.

For themes without theme.json support, we'll still pass the settings to the editor in the new format. We'll just use the old theme_supports to prepare them.

[youknowriad]

Apply a new filter if we want 3rd parties to be able to hook into the new format as well.

I believe the proposal I lean towards is the following:

• Introduce a $context argument to the filter allowing us to know which editor is running the filter. The context can have the following values: post-editor, site-editor, navigation-editor, widget-editor.

Also, take this context argument as an opportunity to solve the issue above by doing this in edit-form-blocks.php:

In edit-form-block

1. run the block_editor_settings with the context pre-theme-json (this ensure backward compatibility since the current plugin authors assume there's no context)
2. Compute theme-json config and property based on the result of that filter and append the theme.json config to the settings array.
3. run the block_editor_settings with the context post-editor (this would allow authors that want to extend any setting including the theme-json one to do so).

[oandregal]

I was thinking of the changes coming at #29891 Also that we now store the theme.json settings under the settings.__experimentalSettings key.

What if we stored this differently in core/block-editor to remain back-compatible?

• the top-level settings in theme.json become top-level keys under settings => no change to the existing settings, but we add new ones at the top-level.
• the block-level settings in theme.json are stored under the settings.__experimentalSettings key (or a different name) => no change to the existing settings, but we add new ones for blocks.

This would make it so that we only add changes, so it's back-compatible. Porting to WordPress core means that the global styles code that wrangles the settings is ported to edit-form-blocks.php before we run the block_editor_settings filter and doesn't need any other hook.

[youknowriad]

We still need to run the hook after we add those new settings for folks that want to alter these new settings. The proposed changes make sense though but let's keep it for later (to be able to keep the __experimental aspect until the last moment :)

[gziolo]

In edit-form-block

1. run the block_editor_settings with the context pre-theme-json (this ensure backward compatibility since the current plugin authors assume there's no context)
2. Compute theme-json config and property based on the result of that filter and append the theme.json config to the settings array.
3. run the block_editor_settings with the context post-editor (this would allow authors that want to extend any setting including the theme-json one to do so).

I was thinking about that when exploring WordPress/wordpress-develop#1118. It looks like the simplest way to keep the backward compatibility is to introduce another hook that is context-aware like:
block_editor_settings_{$context}

Similar to this https://developer.wordpress.org/reference/hooks/render_block_this-name/.

So the plan you outlined makes sense 👍🏻

[oandregal]

According to the latest work, it looks like the next steps for this are:

1. Make sure Editor: Abstract block editor configuration wordpress-develop#1118 and Block Editor: Standardize loading default block editor settings #30245 land.
2. Use the top-level settings of theme.json to set the current block editor settings (do not unset them). The settings per block are still stored within __experimentalFeatures.
3. Port the gutenberg_experimental_global_styles_settings to get_default_block_editor_settings (both plugin and core), so all editors use them.

By doing the above, we are changing how the current global settings work: from being the last to being the first. I now think this is how it should work: that the theme configures the settings via add_theme_support or theme.json shouldn't make any difference to filterability by 3rd parties (at the moment, theme.json settings override any plugin settings by being last). This was necessary only because we moved settings to a different place ― if we don't, we don't need to. It also makes "global settings" filterable in the same lifecycle of any editor.

How does this sound?

[gziolo]

How does this sound?

I think we are aligned, let's make it happen 👍🏻

[oandregal]

Going to close this one as per WordPress/wordpress-develop#1262