Allow to identify styles that are added to the editor settings #1326
Conversation
oandregal
changed the title
|
Pushed a change to make this general and use a |
| $editor_settings['styles'][] = array( | ||
| 'css' => $theme_json->get_stylesheet( 'css_variables' ), | ||
| '__experimentalNoWrapper' => true, | ||
| '__unstableType' => 'globalStyles', |
There was a problem hiding this comment.
"Global styles" has several origins it could be core, theme, and user. Do you think it would make sense/would be useful to also have origin indicators for global styles? It would be complex given how our theme.json merge works.
There was a problem hiding this comment.
I considered it, but the concept of "origin" doesn't match well this use case: globalStyles is the result of merging three different sources of data.
| 'baseURL' => get_theme_file_uri( $style ), | ||
| 'css' => file_get_contents( $file ), | ||
| 'baseURL' => get_theme_file_uri( $style ), | ||
| '__unstableType' => 'theme', |
There was a problem hiding this comment.
Previously when working on presets we used the concept of origins to differentiate presets coming from core vs theme vs user. Styles are all the same type/structure they just have different sources/origins do you think it would make sense to name the property __unstableOrigin.
There was a problem hiding this comment.
See comment above #1326 (comment) I'd rather keep this as type.
|
Committed |
Part of https://core.trac.wordpress.org/ticket/53175
Global settings are filterable by hooking into the
block_editor_settingsfilter. Global styles in the front end are filterable as well by getting theglobal-stylesstyle handle (see). However, there's no mechanism to filter the global styles that come with the editor.This PR allows third-party to identify the styles that are going to be sent to the editor, so they can filter them.
In looking at making it general, this has been added to all the styles we add to the settings.
How to test
theme.jsonsupport.theme.jsonin the top-level folder of the theme and paste the following contents{"version": 1}.--wp--preset--color.wp-edit-post-js-afterscript and within a<style>tag in the body of the document, just before theeditor-styles-wrappernode.Now, install and activate the Gutenberg plugin from the plugin repository and do the same. What happens is that there will be three occurrences, the
wp-edit-post-js-afterembedded script and two identical<style>tags. With this PR there's only one<style>tag added.Changes introduced
It adds a
__unstableTypekey to the styles we add to the editor settings, so they can be inspected by others. In Gutenberg, we'll take advantage of that (as in WordPress/gutenberg#32377) to remove the global styles that come with WordPress core.Alternatives I've considered
I haven't seen many options to do something like this. A similar approach could be to add some sort of metadata in the first lines of the stylesheet instead. While feasible it seems more error-prone than this.