Style engine: remove enqueue flag

[ramonjd]

What?

Follow up to #42880 (comment)

This PR:

• Removes enqueue flag in favour of context to indicate that the style engine should store CSS rules.
• Renames $store_key to $store_name for consistency
• Updates tests and README.md
• Checks for valid $store_name in WP_Style_Engine_CSS_Rules_Store

Why?

Since moving enqueuing to Gutenberg in #42880, we no longer need to tell the style engine to "enqueue" styles.

Testing Instructions

Test in both classic and block themes.

Create some content in a post with link colors and several "layout blocks", e.g., Group and Column.

Here's some test HTML:

<!-- wp:group {"style":{"color":{"background":"#ee6b6b"},"elements":{"link":{"color":{"text":"var:preset|color|vivid-cyan-blue"}}}},"layout":{"type":"flex","flexWrap":"nowrap","justifyContent":"space-between","orientation":"vertical"}} -->
<div class="wp-block-group has-background has-link-color" style="background-color:#ee6b6b"><!-- wp:paragraph {"style":{"elements":{"link":{"color":{"text":"var:preset|color|white"}}}}} -->
<p class="has-link-color"><a href="https://word">Test</a></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"style":{"elements":{"link":{"color":{"text":"#eaf1f6"}}}}} -->
<p class="has-link-color"><a href="https://word">Test</a></p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

<!-- wp:group {"style":{"color":{"background":"#c4cce6"}},"layout":{"contentSize":"342px"}} -->
<div class="wp-block-group has-background" style="background-color:#c4cce6"><!-- wp:paragraph {"style":{"elements":{"link":{"color":{"text":"var:preset|color|vivid-red"}}}}} -->
<p class="has-link-color"><a href="https://word">Test</a></p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

<!-- wp:group {"style":{"color":{"background":"#9eebbc"}},"layout":{"contentSize":"342px"}} -->
<div class="wp-block-group has-background" style="background-color:#9eebbc"><!-- wp:paragraph {"style":{"elements":{"link":{"color":{"text":"#cd31d6"}}}}} -->
<p class="has-link-color"><a href="https://word">Test</a></p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

Check that elements and layouts styles are enqueued.

Expected CSS output. For classic themes this style tag should appear at the bottom of the page. For block themes, in the head.

<style id='block-supports-styles-inline-css'>
.wp-elements-bfe89bcbd3fbf76f9bf93ac884528d9a a {color: var(--wp--preset--color--vivid-cyan-blue);}.wp-elements-85694c8ee6aa1fb95efca209b615f0b0 a {color: var(--wp--preset--color--white);}.wp-elements-6ac1c4acebd6a433ed64dc4e6b0eb185 a {color: #eaf1f6;}.wp-elements-469734e762a60395c96370480f3c9414 a {color: var(--wp--preset--color--vivid-red);}.wp-elements-9307c4f13980ac2b051b4fcf5f7b28fa a {color: #cd31d6;}.wp-block-group.wp-container-1 {flex-wrap: nowrap; align-items: flex-start;}.wp-block-post-content.wp-container-4 > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {max-width: 840px; margin-left: auto !important; margin-right: auto !important;}.wp-block-post-content.wp-container-4 > .alignwide {max-width: 1100px;}.wp-block-group.wp-container-2 > :where(:not(.alignleft):not(.alignright):not(.alignfull)),.wp-block-group.wp-container-3 > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {max-width: 342px; margin-left: auto !important; margin-right: auto !important;}.wp-block-group.wp-container-2 > .alignwide,.wp-block-group.wp-container-3 > .alignwide {max-width: 342px;}.wp-block-group.wp-container-2 .alignfull,.wp-block-group.wp-container-3 .alignfull,.wp-block-post-content.wp-container-4 .alignfull {max-width: none;}
</style>

Run the tests!

npm run test:unit:php

[andrewserong]

Thanks for the follow-up @ramonjd, the logic looks good to me here, now tying the enqueue logic to the presence of a context name 👍

✅ Elements and Layout styles are still output correctly in blocks-based themes
✅ Elements and Layout styles are still output correctly in classic themes (but output near the bottom of the page instead of in the head)
✅ With the removal of allow-listing the context, the added checks for a valid $store_name look good

Just added a couple of comments to make sure I'm understanding the intended changes correctly, but this LGTM! ✨

[andrewserong]

Just making sure I'm following along — we no longer need the block-supports check, because this function effectively doesn't do anything if it isn't calling WP_Style_Engine::parse_block_styles?

[ramonjd]

Good question! That answer is "yes, and..."

I reasoned that wp_style_engine_get_styles encounters only Gutenberg style objects, which are:

1. The value of attributes.style (block supports)
2. In the future
   i. the value of theme.json's root styles properties
   ii. the value of theme.json's styles.blocks[blockName] properties
   iii. the value of theme.json's styles.elements[elementName] properties

These object share the same basic model, although there are some variations in property names and values.

For example, global styles will eventually pass custom CSS properties such as --wp--style--block-gap or dynamic references like { "ref": "styles.color.text" }. These, I think can be dealt with internally when the time comes.

Maybe.

😇

[andrewserong]

All sounds good to me — and removing the check means it encourages us to think holistically about parse_block_styles for the global styles context in addition to the block-level, so I think this is a good direction, too 👍

[andrewserong]

Again, just confirming I'm following along: this test is no longer needed because we're no longer allow-listing the context? (We're effectively passing along the context as the store name, now, allowing any string-based value as the store name).

[ramonjd]

Exactly! Thanks for clarifying.