-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate overall Global Styles mechanics in the server #20047
Conversation
Heya @nosolosw !! Thank you for working on this 😍 I walked through the steps you outlined:
However, I wasn't able to see the Global styles stuff render. No Is there something I need to do in addition to this? Note: Testing locally on fresh Docker install and TwentyTwenty theme. Thanks! Update, I also tried running the
|
Nope, that's all you need! Just tested with a brand new site, fresh clone PR, and the steps above: it worked fine for me. If there is no As per the CLI error. It looks like you need to provide some extra info (user/pass)? If you use the env bundled with gutenberg it may be more convenient to do // Delete existing CPT, if any.
$gs_cpt_list = wp_get_recent_posts( [
'post_type' => 'wp_global_styles',
] );
foreach ( $gs_cpt_list as $gs_cpt ) {
wp_delete_post( $gs_cpt['ID'] );
}
// Insert new one with required data.
wp_insert_post( [
'ID' => 0,
'post_content' => json_encode( [
'color'=> [
'primary' => 'blue',
],
] ),
'post_type' => 'wp_global_styles',
'post_name' => 'wp-global-styles-twenty-twenty', // Note this is for TwentyTwenty!
'post_status' => 'publish',
] ); |
@nosolosw Hallooo!! Thank you for your support 🙏 I've recorded a video here walking through the instructions: https://www.loom.com/share/0635e0c69b1042129e09a12f555920e3 Hopefully this helps with some debugging? |
@nosolosw Hallo!!! Just tested this again, and it's working as expected! I have no idea why it wasn't working for me previously. Thank you so much for your efforts in helping me debug! 🤗 It was most likely my local Docker environment. My machine has been having issues lately. I left a comment for something to fix. After that, I would say this is 👍 from me! |
@ItsJonQ I don't seem to find any comment in the PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nosolosw Oops! I forgot to hit Request changes! 🙇
lib/global-styles.php
Outdated
|
||
if ( is_array( $value ) ) { | ||
$result = array_merge( | ||
$result, | ||
gutenberg_get_css_vars( $value, $new_key, false ) | ||
gutenberg_experimental_global_styles_get_css_vars( $value, $new_key . '-' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nosolosw Haii!!!
Would we be able to change this from -
to --
(double hyphen)?
@jorgefilipecosta made the suggestion of using double hyphen to better indicate depth levels from the global styles object within the flattened CSS var string.
https://github.com/WordPress/gutenberg/pull/19883/files#r373700289
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! But this was when we had different levels (globals vs blocks) so it was useful to differentiate the element part (global/block name) vs the CSS custom property name. Now that we don't have the element part (everything is prefixed by --wp-
), is the --
still useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, now we have --wp-color-primary
, would we want to have --wp--color-primary
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated at 7efa53e and 798a0d3
@jorgefilipecosta and I talked this over and I want to write down the trade-offs of the current approach so we have them documented somewhere until we find a better place.
Jorge's rationale for suggesting the double dash is this: in scoped styles (we store the CSS custom properties as block attributes) we need to deserialize the string into an object for editor things. In that case, we won't be able to distinguish between a valid CSS property name (ex: line-height
) and a name that results of flattening the object keys (background-color
from {background: { color: 'red' }}
). Let's work through an example. We've got this string we want to deserialize back into an object:
--wp-background-color: 'red';
--wp-line-height: 1.2;
How do we know which object to deserialize into without information about the object keys/CSS property names?
This is what we want:
{
background: {
color: 'red',
},
line-height: 1.2
}
A simple parser that creates one level per dash would return (which is not what we want, so we have to make the parser a bit more complex):
{
background: {
color: 'red',
},
line {
height: 1.2,
}
}
By using double dashes the deserialization parser is simpler (each object level is separated by --
):
--wp--background--color: 'red';
--wp--line-height: 1.2;
Personally, I'm not a fan of this implementation detail leaking into the API design/naming schema. However, I also think this is a fair approach to simplify the parser and get us going. The underlying assumption is that we store this information only once in the block attribute as a string, not as an object: when we cross that river, we'd have the opportunity to reevaluate this and change if necessary.
f9d90e0
to
d950b5f
Compare
This PR is ready to land, although it only works in the block-editor. We're going to integrate Global Styles in the
I'm going to work on the |
I was able to make this work for |
0933ad7
to
a218643
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 @nosolosw Awesome work!!! Thank you for creating and iterating on this! Not only that, but you've also added it to FSE "Edit Site".
Testing locally, and it's working as outlined in your instructions.
From a code perspective, the mechanics of the PHP updates make sense of me.
@jorgefilipecosta If you're around, it would be great to get your thoughts on the PHP implementation 🙏 . Thank you!! |
this gives a well-known string and avoids the need to parse the theme name for spaces, etc.
This has been probably inadvertenly added in a rebase.
a218643
to
6f1e87b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @nosolosw nice work here 👍 generally the changes seem good and I think they are going in the right direction.
function gutenberg_experimental_global_styles_get_user_cpt( $post_status_filter = array( 'publish' ), $should_create_draft = false ) { | ||
$user_cpt = array(); | ||
$post_type_filter = 'wp_global_styles'; | ||
$post_name_filter = 'wp-global-styles-' . strtolower( wp_get_theme()->get( 'TextDomain' ) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think as an id of the theme we should use get_stylesheet() and not the 'TextDomain'. I think the database setting the WordPress core stores in the database to identify the current theme is the stylesheet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The template parts use the TextDomain
for this, so I thought we may want to use the same mechanism for API consistency. I'm happy to change it to something else, but I guess it makes sense to update template parts as well?
$cpt_post_id = wp_insert_post( | ||
array( | ||
'post_content' => '{}', | ||
'post_status' => 'draft', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may have a bug, in gutenberg_experimental_global_styles_get_user we are querying published posts, but we insert a draft post. On the next execution, a published post will still not exist and we will probably create another one.
I think we may be able to create the post with the published status ( the empty object will not do anything);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note the optional parameter $should_create_draft
, which is false by default. We only insert a draft if there is no CPT during the editor call gutenberg_experimental_global_styles_get_user_cpt_id
. That's the only place we need a pre-existing CPT: the entities API only works with pre-existing objects, can't create new ones from the client-side.
|
||
/** | ||
* Adds class wp-gs to the frontend body class if the theme defines a experimental-theme.json. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we unconditionally add the wp-gs class we will break the styles of some blocks.
.wp-gs .wp-block-button__link:not(.has-background) {
background-color: var(--wp--color--primary);
}
As the class is added even if the theme does not support global styles a theme that was changing the button color using the following code will stop working:
.wp-block-button__link {
background-color: red;
}
I think the whole idea of adding wp-gs was to mark themes that support global styles if we unconditionally add the class we would be able to not add it at all as well.
I know that for now we only add if the experiment is enabled but one day we remove the experiment and in that case, we would unconditionally add the class.
I think we should add the class when the experiment is enabled and when the theme supports global styles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already do that! The class is only added when the experiment is enabled, the theme has support, and the editor is site editor (for back-end, doesn't apply to front-end).
@@ -37,7 +37,7 @@ $blocks-button__height: 56px; | |||
} | |||
|
|||
.wp-gs .wp-block-button__link:not(.has-background) { | |||
background-color: var(--wp-block-core-button--color--background, var(--wp-color--primary, $dark-gray-700)); | |||
background-color: var(--wp--color--primary); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we pass $dark-gray-700 as a fallback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that --wp--color--primary
is going to have always a value (user-defined, the theme default, or core default), so the fallback won't be necessary.
This PR seeks to consolidate the overall server-side mechanism for Global Styles. Continues work from #19883
It adds the user's Global Styles to the resolver, so it now works using core, theme, and user data. It stores the user's data using a Custom Post Type, so we can leverage existing editor mechanisms (undo/redo, draft/publish status for Global Styles, etc). This also presumes we want Global Styles to be tied to the theme so when theme changes we want to start with a new blank slate for Global Styles, which is implemented by using the theme's textdomain as part of the CPT's post name.
It exposes to the editor a couple of variables necessary for live-editing the styles: the ID of the entity that holds the user's styles + the base styles (core+theme). How this works will be demonstrated in subsequent PR. Note this is made to work only with the Beta Site Editor.
As per past conversations, it flattens the Global Styles tree stripping out the block variables. It looks like this:
which will be converted to this CSS rule (see discussion about syntax):
Note that the names and variables we expose are still in flux, so take the current ones as only valid for demo purposes.
How to test
npm install && npm run build
.experimental-theme.json
in your current theme's folder. For example,wp-content/themes/twentytwenty-blocks/experimental-theme.json
.1) Check that core's Global Styles work:
#52accc
.2) Check that theme's Global Styles override core's if present:
experimental-theme.json
file created before.hotpink
.3) Check that user's Global Styles override theme's if present:
blue
.[1] Make sure there isn't another post with the same post_name; if there is one, delete it first. Find below some ways you can add the required data for testing purposes. This is for the experimental Twenty Twenty Blocks theme, change to use your active theme's text-domain as required.
wp-cli -- you may need to provide other connection parameters depending on your setup:
PHP -- paste the following code within the
gutenberg_experimental_global_styles_enqueue_assets
when it comes to test user's Global Styles: