Provide ways to extend/customize the Global Styles sidebar

[mmtr]

What problem does this address?

Gutenberg does not provide any way to extend/customize the Global Styles sidebar for things like:

• To display extra help content - text or video. For example maybe an organization has branding guidelines about which colors (styles) are suitable and when they ought to be used.
• Getting other style variations from some source, i.e. ones that are 'generic' and not linked to a theme.
• Some kind of revision log.

Plugins developers interested in such extensions are forced to manipulate the DOM (e.g. injecting custom React components inside an element located with a CSS selector). But this is very fragile, since Gutenberg can change the DOM without further notice, breaking these extensions.

What is your proposed solution?

Add standard extension points to the Global Styles sidebar such as SlotFills, hooks, or a programmatic API, so plugin developers can customize it with a more robust mechanism.

Seems that the editor sidebar is currently extensible via SlotFills (https://github.com/WordPress/gutenberg/issues/13357), so I guess the Global Styles sidebar can follow the same approach.

[Copons]

cc @mtias

[erikyo]

Same thing here, I would like to be able to extend the global styles panel (e.g. by adding the font-family) but I have not found any way to do this.

[mtias]

There are multiple points of extensibility to consider here. New "navigator" items should probably use a registration based API, while pieces outside the navigator could use some UI slots if we make them semantic enough. cc @gziolo @oandregal

Extending individual design features seems more granular.

[oandregal]

Thanks for providing specific examples of things to be extended/customized. That helps a lot in providing feedback.

To display extra help content - text or video. For example maybe an organization has branding guidelines about which colors (styles) are suitable and when they ought to be used.

Would the existing filters help with this? They can be used to provide specific color palette per block type. There's a new one landing in 6.2 to be able to filter per block instance https://make.wordpress.org/core/2023/02/28/custom-settings-wordpress-6-2/

The case for showing some tooltips is an interesting one. I don't know that we allow that in the post editor. cc @jorgefilipecosta as he has worked quite a bit on extending UIs.

Getting other style variations from some source, i.e. ones that are 'generic' and not linked to a theme.

Can we do this with the existing filters provided by the REST API? Perhaps rest_post_dispatch? If this does not work for some reason, we could look into providing a specific filter for this.

Some kind of revision log.

There's work to add this feature. I'm not sure how active it is or whether other people could pick it up https://github.com/WordPress/gutenberg/pull/46667

---

In general, my understanding so far is that the UI reflects APIs registered elsewhere (block supports from the block API, theme.json API, etc.). The UI is still a moving target (see https://github.com/WordPress/gutenberg/pull/49014 where it's being moved to the black shell sidebar, to the left), so I don't know how stable can we make those UI slots, if any is required.

[jorgefilipecosta]

The case for showing some tooltips is an interesting one. I don't know that we allow that in the post editor. cc @jorgefilipecosta as he has worked quite a bit on extending UIs.

As far as I know we don't have any API to provide additional tooltips.

[mmtr]

Would the existing filters help with this? They can be used to provide specific color palette per block type.

They can definitely help with the specific example of ensuring that some style guidelines are respected. But the purpose of the example was to provide additional context about why some developers might want to modify the sidebar UI to inject additional content that could be helpful for users editing global styles, and that cannot be done with existing filters.

I understand though how making the UI extensible makes harder to iterate on it because it needs to maintain backwards compatibility.

[youknowriad]

Ok, since there's still uncertainties about the use cases and semantics and I think for the sake of moving forward here, we can start by adding a slot in the Gutenberg plugin, protect it using the isGutenbergPlugin check, request feedback from plugins developers. Once we reach the "core merge" window, we can make a more informed call about whether we're confident enough to include these slots on core or not.