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

Gallery: register styles with style engine #43070

Merged
merged 5 commits into from
Oct 27, 2022

Conversation

ramonjd
Copy link
Member

@ramonjd ramonjd commented Aug 9, 2022

Depends on:

What?

Update gallery to use style engine enqueuing, and also WP_HTML_Tag_Processor to add the unique class.

Why?

  • To batch styles in one style tag.
  • Also, gutenberg_enqueue_block_support_styles() will soon be deprecated.

Testing Instructions

Since https://core.trac.wordpress.org/ticket/56353 WordPress supports CSS custom vars. It will be shipped with 6.1.

For sites running < 6.1 Gutenberg allows specific CSS properties only. See: #43071

  1. Create a new gallery, add your favourite holiday pics.
  2. Apply a block gap value to your gallery and publish!
  3. Check that your gallery appears as you'd expect it to on the frontend, and that it has the following styles (with your block gap value):
<style id='block-supports-inline-css'>
/* ...some styles */
.wp-block-gallery.wp-block-gallery-1 {
	--wp--style--unstable-gallery-gap: 107px;
	gap: 107px;
}
/* ...some styles */
</style>

Test in classic and block themes.

Screen Shot 2022-08-09 at 10 09 43 am

@ramonjd ramonjd added [Status] In Progress Tracking issues with work in progress [Block] Gallery Affects the Gallery Block - used to display groups of images [Package] Style Engine /packages/style-engine labels Aug 9, 2022
@ramonjd ramonjd self-assigned this Aug 9, 2022
@ramonjd ramonjd added the [Status] Blocked Used to indicate that a current effort isn't able to move forward label Aug 9, 2022
),
);

gutenberg_style_engine_get_stylesheet_from_css_rules(
Copy link
Member Author

@ramonjd ramonjd Aug 11, 2022

Choose a reason for hiding this comment

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

I think we might have to come up with a way to ensure these styles are printed after the layout styles:

See:

cc @glendaviesnz

Copy link
Contributor

@andrewserong andrewserong Oct 14, 2022

Choose a reason for hiding this comment

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

Following the testing in #41423, it looks like the fallback styling rules aren't being output on a classic theme for me (TwentyTwentyOne), so if I add the following to my theme's css, it doesn't affect the gallery gap:

html {
	--wp--style--gallery-gap-default: 37px;
}

From a bit of introspection, it appears that the fallback rules in $fallback_gap are being stripped in WP 6.0, as it's a pretty complex value, and the gutenberg_safecss_filter_attr_allow_css_6_1 function here hasn't been updated to reflect the final version in 6.1 on these lines: https://github.com/WordPress/wordpress-develop/blob/2b4d385298504d412e9f0dea2e7019d53463c705/src/wp-includes/kses.php#L2508-L2512

If I copy over that preg_replace line to the Gutenberg function, it appears that the style output works correctly, so we might need to land another backport of a backport before we can go with this PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll put up a PR to backport that line.

@ramonjd ramonjd force-pushed the update/gallery-register-styles-with-style-engine branch from 1fafece to 6ae3ebe Compare September 27, 2022 04:26
@ramonjd ramonjd marked this pull request as ready for review September 27, 2022 05:39
@ramonjd
Copy link
Member Author

ramonjd commented Sep 27, 2022

Interesting...

Seeing duplicate comments in the block supports inline CSS

<style id='core-block-supports-inline-css'>
/**
 * Core styles: block-supports
 */

/**
 * Core styles: block-supports
 */

Might mean that the hook callback is running twice

👀

@ramonjd ramonjd force-pushed the update/gallery-register-styles-with-style-engine branch 2 times, most recently from 4beea4f to 4a47f9e Compare October 14, 2022 02:29
Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

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

Thanks for keeping this one current @ramonjd! It's mostly working, but I ran into an issue with fallback gap on classic themes. I think it's uncovered a missing backport of allowed css functions in Gutenberg, but I've left a comment where we'll likely need to follow-up there.

* @param string $style String containing the CSS styles to be added.
* @param int $priority To set the priority for the add_action.
*/
function gutenberg_enqueue_block_support_styles( $style, $priority = 10 ) {
_deprecated_function( __FUNCTION__, '6.1' );
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we remove this deprecation notice since it didn't make it into 6.1, and instead add it back in once we're ready to start adding in 6.2 versions of these functions?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh yeah 🤦 This PR is old.

Will do, thank you!

Copy link
Member Author

Choose a reason for hiding this comment

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

Looks like there's a wordpress-6.2/script-loader.php file now. I could move it there and keep the notice, and bump it to 6.2

),
);

gutenberg_style_engine_get_stylesheet_from_css_rules(
Copy link
Contributor

@andrewserong andrewserong Oct 14, 2022

Choose a reason for hiding this comment

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

Following the testing in #41423, it looks like the fallback styling rules aren't being output on a classic theme for me (TwentyTwentyOne), so if I add the following to my theme's css, it doesn't affect the gallery gap:

html {
	--wp--style--gallery-gap-default: 37px;
}

From a bit of introspection, it appears that the fallback rules in $fallback_gap are being stripped in WP 6.0, as it's a pretty complex value, and the gutenberg_safecss_filter_attr_allow_css_6_1 function here hasn't been updated to reflect the final version in 6.1 on these lines: https://github.com/WordPress/wordpress-develop/blob/2b4d385298504d412e9f0dea2e7019d53463c705/src/wp-includes/kses.php#L2508-L2512

If I copy over that preg_replace line to the Gutenberg function, it appears that the style output works correctly, so we might need to land another backport of a backport before we can go with this PR?

@ramonjd
Copy link
Member Author

ramonjd commented Oct 14, 2022

If I copy over that preg_replace line to the Gutenberg function, it appears that the style output works correctly, so we might need to land another backport of a backport before we can go with this PR?

Great sleuthing, thanks @andrewserong

I'll do the backport in another PR since it's bit separate and come back and test the scenario.

I appreciate the test! 🙇

@andrewserong
Copy link
Contributor

I'll do the backport in another PR since it's bit separate and come back and test the scenario.

Oh, thanks! I've opened up a backport PR already in #44962 — I mightn't get a chance to test it properly today (I just copy + pasted and hoped for the best for the moment), so might leave it until next week to try to get it merged, if it isn't too urgent

@ramonjd
Copy link
Member Author

ramonjd commented Oct 14, 2022

Oh, thanks! I've opened up a backport PR already in #44962 — I mightn't get a chance to test it properly today (I just copy + pasted and hoped for the best for the moment), so might leave it until next week to try to get it merged, if it isn't too urgent

Merged!

Thanks a lot for the quick PR

@ramonjd ramonjd force-pushed the update/gallery-register-styles-with-style-engine branch from f5e9f2a to 84d1e7b Compare October 25, 2022 21:04
@glendaviesnz
Copy link
Contributor

I think we might have to come up with a way to ensure these styles are printed after the layout styles

The styles seemed to work ok for me on Classic themes. I think #41015 removed the need to worry about the priority.

This tested pretty well for me. The only thing I noticed is that setting the gap via either the deprecated --gallery-block--gutter-size or --wp--style--gallery-gap-default in a classic theme applied the gap in the frontend but not in the editor, but it does that for me on trunk as well, so don't think it is related to this PR. Do you also see this on trunk?

@ramonjd
Copy link
Member Author

ramonjd commented Oct 26, 2022

The only thing I noticed is that setting the gap via either the deprecated --gallery-block--gutter-size or --wp--style--gallery-gap-default in a classic theme applied the gap in the frontend but not in the editor, but it does that for me on trunk as well, so don't think it is related to this PR. Do you also see this on trunk?

Thanks for testing @glendaviesnz

I activated 2021 theme, then added the following to ./style.css

:root {
--wp--style--gallery-gap-default: 22px;
--gallery-block--gutter-size:11px;
}

This indeed worked for the frontend, but not the editor.

Screen Shot 2022-10-27 at 9 18 04 am

I had to add the CSS to ./assets/css/style-editor.css to get it to work everywhere:

Screen Shot 2022-10-27 at 9 18 57 am

Is that expected. Which classic theme did you test with?

@glendaviesnz
Copy link
Contributor

glendaviesnz commented Oct 26, 2022

This indeed worked for the frontend, but not the editor.

I had to add the CSS to ./assets/css/style-editor.css to get it to work everywhere
Is that expected. Which classic theme did you test with?

Given that the likes of TwentyTwentyOne have lots of CSS vars in ./assets/css/style-editor.css I am picking we can assume it is normal to have to do that to get any extra vars to work in the editor, so let's leave it as that for now.

Copy link
Contributor

@glendaviesnz glendaviesnz left a comment

Choose a reason for hiding this comment

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

This tested well for me with block-based and classic themes.

@ramonjd ramonjd merged commit b54b0eb into trunk Oct 27, 2022
@ramonjd ramonjd deleted the update/gallery-register-styles-with-style-engine branch October 27, 2022 00:37
@github-actions github-actions bot added this to the Gutenberg 14.5 milestone Oct 27, 2022
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label Jan 11, 2023
@Mamaduka
Copy link
Member

Mamaduka commented Feb 6, 2023

@ramonjd, is there a separate core ticket for deprecating wp_enqueue_block_support_styles?

@andrewserong
Copy link
Contributor

@Mamaduka, I don't think there is a separate core ticket as far as I'm aware. @ramonjd isn't around at the moment, but I can open a trac ticket, I think I've got enough context to describe the intention here.

@andrewserong
Copy link
Contributor

@Mamaduka @glendaviesnz I've opened up a trac ticket to flag the deprecation of the function: https://core.trac.wordpress.org/ticket/57647

The short version is: as of 6.2 all usage of wp_enqueue_block_support_styles will have been replaced with calls to the style engine, where styles are grouped together and output in a single style tag. Prior to using the style engine, the calls to wp_enqueue_block_support_styles resulted in excess style tags being output to the site frontend, along with redundant CSS rules.

As far as I can tell, we can't deprecate the function until after the JS packages update has happened, as that change will include the switch in the gallery block's index.php file reflected in this PR. That appears to be the last usage of wp_enqueue_block_support_styles, so once this change is backported, we should then be right to add in the _deprecated_function() call to deprecate the function. I'll open up a wordpress-develop PR so that the deprecation is ready for review once the JS packages are updated.

@andrewserong
Copy link
Contributor

Update: I've opened up a PR to deprecate wp_enqueue_block_support_styles over in WordPress/wordpress-develop#4015 — I believe that one should only land after the JS packages update, if I'm following correctly 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Gallery Affects the Gallery Block - used to display groups of images [Package] Style Engine /packages/style-engine [Status] Blocked Used to indicate that a current effort isn't able to move forward
Projects
Status: 🏆 Done
Development

Successfully merging this pull request may close these issues.

5 participants