Fix/wp get global styles for custom props returns internal variable

[samnajian]

What?

This PR fixes #49693 so that wp_get_global_styles for the following in theme.json

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

returns:

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

Why?

#49693
The internal syntax shouldn't leak out.

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

Please refer to the issues for testing instructions, but please note the following:

1. Make sure the Gutenberg plugin is installed and active
2. In body of wp_get_global_styles exchange WP_Theme_JSON_Resolver with WP_Theme_JSON_Resolver_Gutenberg
3. Confirm the output of wp_get_global_styles doesn't include internal variable syntax.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @samnajian! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[oandregal]

This is a great start, thanks!

In body of wp_get_global_styles exchange WP_Theme_JSON_Resolver with WP_Theme_JSON_Resolver_Gutenberg

The only thing left would be to copy back from core the wp_get_global_styles function and declare it as gutenberg_get_global_styles function in Gutenberg. This is a bit cumbersome, but it's the method we have now to keep core<=>gutenberg in sync.

[oandregal]

I've left a few suggestions for improving sanitize_variables implementation. Other than that, this is ready. Thanks for your work here 👏

[oandregal]

This is great work, thanks for your contributions, Sam!

[github-actions]

Congratulations on your first merged pull request, @samnajian! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts:

https://profiles.wordpress.org/me/profile/edit/

And if you don't have a WordPress.org account, you can create one on this page:

https://login.wordpress.org/register

Kudos!

[hellofromtonya]

Once introduced in WP Core, this modifies the value format for the returned styles from wp_get_global_styles(). As such, it is a backwards-compatibility (BC) break for extenders expecting and using this structure.

The result could mean broken styling experiences for users.

Is this a truly a bugfix, meaning wp_get_global_styles() should always have returned the style value structure? Or is this a new improvement to avoid leaking internal structures?

cc @oandregal

[oandregal]

This is why I think it's a fine change.

Let say we had the following input:

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

Before this PR, the output of wp_get_global_styles would be:

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

After this PR, the output of wp_get_global_styles would be:

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

Before this PR, the consumers had to deal with two formats: var(--wp--preset--color--secondary) and var:preset|color|secondary, as a possible representation of the same value.

After this PR, they only have to deal with one format that's been always present: var(--wp--preset--color--secondary). I don't remember when the var:preset|color|secondary was introduced for people to use in theme.json but it was later and added as a convenience. It should have never leaked to consumers, in my view. I did some quick search but didn't find when it was, I can do some archeology if this is important.

An important note is that the format doesn't carry any meaning about where this data comes from. Any origin (default, block, theme, user) can use var:preset|color|secondary. Consumers cannot use that format as a hint of it being data from the user origin.

Does this help?

[oandregal]

Follow-up to fix PHP docblock at #50527

[oandregal]

Backport at WordPress/wordpress-develop#4556