Add extensibility hooks to global styles infrastructure

[oandregal]

Related #27506

As the different pieces of "Global Styles" land into WordPress core, we need the ability to extend a few things:

• The ability to modify the schema: add/remove style properties & block supports, settings, and, generally, new versions of the schema. See how PROPERTIES_METADATA and SCHEMA are used in WP_Theme_JSON. Related Handle an evolving theme.json shape (consider add versioning). #27230

• The ability to config things differently: allow third-parties to enable/disable settings, new values for styles, etc. For this one, is it enough with what we have (block_editor_settings filter)? or would it be benefitial to hook into WP_Theme_JSON->get_settings, WP_Theme_JSON->get_stylesheet, WP_Theme_JSON->get_raw_data to modify the tree before those methods do their thing?

• The ability to hook into how trees are merged. See WP_Theme_JSON::merge

[oandregal]

cc @aristath you had a PR for this that I'm failing to find. Would you like to share the use cases you wanted to address?

[aristath]

The PR I had was in #25499 but I closed it 'cause I'll have to do it again taking into account all recent structural changes.
The concept is that plugins will at some point (soon) need to extend and modify the theme.json props, as well as the generated styles.
Since I made that PR I have changed the way I see some things... which is partly why I closed that one. I'll be submitting a new PR (hopefully later today) with a new suggestion for filters related to this.

Examples for plugins that will need to use these filters:

• A plugin that hooks in a palettes API (there are a few AI-based APIs out there) and allows users to change their palettes
• A plugin that allows users to use preset typography-scales for headers
• Lots and lots more...

In order for plugins to be able to properly modify the "presets" for theme-styles, they'll need to be able to hook there, modify the JSON and inject their own css-vars in the final CSS.

[oandregal]

No rush to make a PR, we may need more changes. I just want to have a place to create clarity about the use cases we need to support.

For example, the two things you mentioned seem to me that are related to the UI, is that correct? It so, I don't think we can't do anything here, this is only for the infrastructure pieces we plan to land in #27506 UI-hooks can be discussed separately, as we'd have to iterate on the UI first #27473

[oandregal]

In a conversation with @jorgefilipecosta he mentioned an idea that I wanted to document: what if instead of introducing multiple hooks for different steps of the lifecycle we allow to have a single hook to replace the whole implementation entirely? He mentioned we do this for core blocks (see).

From the Gutenberg plugin perspective, it sounds like it could be more useful in this initial stage. I don't think it'd be that useful for themes/plugins that want to extend how this works but I'm also unsure what are the use cases for these that can't be done with the current settings filter.

[oandregal]

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

For WordPress 5.8 we haven't introduced specific filters for global styles but instead, we rely on the existing WordPress mechanisms.

[mrwweb]

we rely on the existing WordPress mechanisms.

@nosolosw Can you explain what the "existing infrastructure" is how and how it will enable plugins to modify global styles which is the purpose of this ticket? A quick look through the two links didn't provide any obvious answers for me on that need.

[oandregal]

@mrwweb there are a few things:

• Front end styles can be filtered by tapping into the wp_styles mechanism, see example in Gutenberg.
• To the editor we pass two things that can be filtered via hooking into the block editor filters in place:
  • Global settings: stored in the __experimentalFeatures key and this is how Gutenberg does it.
  • Some styles: stored in the styles key and global styles have an extra key __unstableType that is equal to globalStyles. See how Gutenberg does it.

As you can notice, these aren't "global styles" specific hooks but we rely on the existing mechanisms of WordPress and the block editor. As things mature, we should consider specific ones.

I closed this issue because it no longer served the original purpose, which was to figure out what we needed for the first iteration. I presume we've have to create a next iteration for the "global styles" focus at #20331 or an entirely new issue, including API stabilization and polishing.

[fabiankaegy]

@oandregal Readying through all this I can see how extenders can hook into the global styles system to add custom logic to allow new properties and generate the styles output. However, the piece that is missing from what I can tell is the ability to render custom controls in the global styles interface so that these settings can be configured.

Is there something I'm missing or is that the state of things? :)

I opened #47990 to flag this but want to make sure I'm not missing anything.