Skip to content
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

wp_get_global_styles: return the standard format for CSS Custom Properties #4556

Closed
wants to merge 4 commits into from
Closed

wp_get_global_styles: return the standard format for CSS Custom Properties #4556

wants to merge 4 commits into from

Conversation

oandregal
Copy link
Member

@oandregal oandregal commented Jun 6, 2023

Trac ticket https://core.trac.wordpress.org/ticket/58467
Backports WordPress/gutenberg#50366 and WordPress/gutenberg#50527
Part of WordPress/gutenberg#45171

What?

This PR fixes wp_get_global_styles so that it always return the standard format for CSS Custom Properties. For a theme.json dataset with the following data:

"core/post-terms": {
    "typography": { "fontSize": "var(--wp--preset--font-size--small)" },
    "color":{ "background": "var:preset|color|secondary" }
}

the wp_get_global_styles function should return:

(
    [typography] => Array( [fontSize] => var(--wp--preset--font-size--small) )
    [color] => Array( [background] => var(--wp--preset--color--secondary) )
)

Why?

See WordPress/gutenberg#49693 The internal syntax shouldn't leak out, so consumers of this function only have to deal with the standard CSS Custom format.

How?

This PR extract the already existing logic that converts var:preset|color|secondary to var(--wp--preset--font-size--small) to a separate method, then uses the same method to sanitize the output of wp_get_global_styles to only include custom CSS variables and not internal variable syntax.

Testing Instructions

  • Use a theme that has a theme.json.
  • Paste the following under styles.blocks:
"core/post-terms": {
    "typography": { "fontSize": "var(--wp--preset--font-size--small)" },
    "color":{ "background": "var:preset|color|secondary" }
}
  • Use the wp_get_global_styles functions to retrieve those styles. For example, paste the following in functions.php of the theme:
add_action( 'init', function(){
        error_log( print_r( wp_get_global_styles( array(), array('block_name'=>'core/post-terms') ), true ) );
} );

The result will be:

(
    [typography] => Array( [fontSize] => var(--wp--preset--font-size--small) )
    [color] => Array( [background] => var:preset|color|secondary )
)

when it should have been

(
    [typography] => Array( [fontSize] => var(--wp--preset--font-size--small) )
    [color] => Array( [background] => var(--wp--preset--color--secondary) )
)

Note the color.background value. It should return the value in a valid CSS value, not the shortened internal format.

Commit message

`wp_get_global_styles`: return the standard format for CSS Custom Properties.

Props samnajian, hellofromtonya, isabel_brison.
Fixes #58467.

Copy link
Contributor

@tellthemachines tellthemachines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good and testing steps are returning the expected values. Just one (tiny, non-blocking) question below!

@@ -92,6 +92,8 @@ function wp_get_global_settings( $path = array(), $context = array() ) {
* Gets the styles resulting of merging core, theme, and user data.
*
* @since 5.9.0
* @since 6.3.0 the internal format "var:preset|color|secondary" is always resolved
* to the standard form "var(--wp--preset--font-size--small)".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this comment given there are no actual changes to this function? I'm assuming that returning the internal notation was a bug 😄 as I don't see the behaviour documented anywhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a hard one. I suppose the comment is helpful in clarifying the behavior so consumers using different versions of WordPress can prepare accordingly: they have to do the conversion themselves in versions <6.3. Unless this change is backported to any older version that is also affected 🤔

For the purposes of 6.3 beta, I'm going to merge this as it is, but we can iterate / create follow-ups after.

@oandregal
Copy link
Member Author

oandregal commented Jun 21, 2023

@oandregal oandregal closed this Jun 21, 2023
@oandregal oandregal deleted the update/transform-to-standard-form branch June 21, 2023 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

2 participants