Enqueue block custom CSS only when block renders on the page. #58991

tellthemachines · 2024-02-14T02:15:32Z

What?

Follow up from WordPress/wordpress-develop#5892.

Global styles per-block custom CSS should respect the wp_should_load_separate_core_block_assets flag and only be enqueued when the block renders on the page if separate assets are enabled.

Ideally this work would be done core-first, but given we're currently in Beta it will have to wait a while, so it's worth trying out here in the meantime.

Testing Instructions

Test with a block theme that adds custom CSS to a few of its blocks, such as TT4, or add custom CSS to blocks in global styles. Also add some base custom CSS (in the global styles sidebar, open the "More" dropdown to show Additional CSS if it's not visible in the UI).
In the front end, load up a page that contains blocks with custom CSS and one that doesn't. Check that custom CSS is loaded only when blocks are on the page (custom CSS styles can be found inside <style id='global-styles-inline-css'>)
Add add_filter( 'should_load_separate_core_block_assets', '__return_false', 11 ); to the theme's functions.php and check that custom CSS for all blocks always loads in the front end.

Testing Instructions for Keyboard

Screenshots or screencast

github-actions · 2024-02-14T02:17:13Z

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/class-wp-theme-json-gutenberg.php
❔ lib/global-styles-and-settings.php
❔ lib/script-loader.php

github-actions · 2024-02-14T02:35:03Z

Flaky tests detected in 7424bb0.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7954307106
📝 Reported issues:

[Flaky Test] can add submenus #50976 in /test/e2e/specs/editor/blocks/navigation-list-view.spec.js
[Flaky Test] can edit menu items #59006 in /test/e2e/specs/editor/blocks/navigation-list-view.spec.js
[Flaky Test] list view should correctly reflect navigation items' structure #58980 in /test/e2e/specs/editor/blocks/navigation-list-view.spec.js

ramonjd · 2024-02-14T03:56:52Z

This could be me, but I was just firing up this branch in the site editor and noticed that the home template is being rendered as though it were in a page template, i.e., with site title and the root container being a wp-block-post-content

In trunk:

If you can't see that then please ignore me!

github-actions · 2024-02-14T03:57:06Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: aristath <aristath@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

ramonjd · 2024-02-14T04:02:23Z

This could be me, but I was just firing up this branch in the site editor and noticed that the home template is being rendered as though it were in a page template, i.e., with site title and the root container being a wp-block-post-content

I rebased on trunk and it's stopped. Must've been me. Sorry!

ramonjd

Just did a drive by test.

This change makes sense to me, and it working pretty well.

I can confirm that custom block CSS is only loaded if that block appears on the page in the frontend.

add_filter( 'should_load_separate_core_block_assets', '__return_false', 11 ); makes it load all the time. 🌮

Not sure if it needs a rebase - I was seeing some strange behaviour in site editor, but my env probably needs nuking.

lib/global-styles-and-settings.php

oandregal

Nice, thanks!

I've tested a few scenarios (how posts with and without quote block behave in a block theme, by default and with the filter disabled) and all work as expected. I'm looking at the code in a bit.

oandregal · 2024-02-15T11:09:29Z

Is it feasible to deprecate gutenberg_enqueue_global_styles_custom_css() and absorb that logic as part of gutenberg_enqueue_global_styles()?

As a consumer, if I use gutenberg_enqueue_global_styles() I'd expect to have all the CSS that is needed – I shouldn't have to use a separate function for the styles.css property. In my opinion, styles.css is just another style property in the theme.json, the same as styles.typography.fontSize or styles.elements.button.border.radius. I don't understand why it needs have its dedicated set of public functions.

This is a bug that has been present in WordPress since the styles.css property landed in theme.json. The fix will land in 6.6, so I think we have plenty of time to make it right and aim to simplify.

tellthemachines · 2024-02-15T23:07:06Z

Is it feasible to deprecate gutenberg_enqueue_global_styles_custom_css() and absorb that logic as part of gutenberg_enqueue_global_styles()?

It should be, yeah! I'm not sure why it wasn't done that way to start with. One thing I noticed is that the customizer CSS is being enqueued as part of gutenberg_enqueue_global_styles_custom_css(), and if we were to make it part of gutenberg_enqueue_global_styles() it wouldn't make sense to do that. Again, I'm not sure why it was done that way, so will try to find out more before changing it around 😅

tellthemachines · 2024-02-19T03:04:06Z

Ok so the reason for the current system is explained in #47396: we're de-enqueuing the customizer additional CSS and adding them before global styles custom CSS so that they don't override global styles in hybrid themes.

The reason for customizer styles being attached to wp-head so late in the game is explained here: it was so that they would override any other theme styles 😅

Hybrid themes are a bit of an edge case, but in order to preserve back compat it would be good to keep the current order of customizer additional CSS followed by global styles custom CSS.

I don't think any of this is a blocker to enqueuing custom CSS as part of gutenberg_enqueue_global_styles, so I'll update this PR to do that.

tellthemachines · 2024-02-19T03:51:14Z

OK I think all feedback has been addressed now! I moved the enqueuing logic into gutenberg_enqueue_global_styles and deprecated gutenberg_enqueue_global_styles_custom_css.

The order of loaded styles should still be the same:

base global styles
block-specific global styles
customizer additional CSS
base global styles additional CSS
block-specific global styles additional CSS.

aristath

LGTM 👍

peterwilsoncc

@tellthemachines Sorry, it's easier to track commits rather than PRs so I only caught this late. Are you able to follow up?

I'm not sure how well the docs-parser copes with the comment format but better to play nice :)

peterwilsoncc · 2024-02-28T21:59:27Z

lib/class-wp-theme-json-gutenberg.php

+
+

Nit: Double line break

peterwilsoncc · 2024-02-28T23:22:44Z

lib/global-styles-and-settings.php

+
+		$stylesheet_handle = 'global-styles';
+
+		/**


This needs to be /*.

A double asterisk indicates that comments are a docblock to the various parsers for developer.wordpress.org and elsewhere.

peterwilsoncc · 2024-02-28T23:23:02Z

lib/script-loader.php

@@ -53,6 +53,35 @@ function gutenberg_enqueue_global_styles() {

 	// Add each block as an inline css.
 	gutenberg_add_global_styles_for_blocks();
+
+	/**


As above re docblock/comment.

peterwilsoncc · 2024-02-28T23:23:27Z

lib/script-loader.php

+	 * Before that, dequeue the Customizer's custom CSS
+	 * and add it before the global styles custom CSS.
+	 */
+	// Don't enqueue Customizer's custom CSS separately.


This can be move in to the existing multiline comment

peterwilsoncc · 2024-02-28T23:23:40Z

lib/script-loader.php

+	$custom_css = wp_get_custom_css();
+
+	if ( ! wp_should_load_separate_core_block_assets() ) {
+		/**


comment v docblock, as above.

oandregal · 2024-02-29T16:52:27Z

lib/script-loader.php

@@ -77,8 +107,6 @@ function gutenberg_enqueue_global_styles_custom_css() {
 		wp_add_inline_style( 'global-styles', $custom_css );
 	}
 }
-remove_action( 'wp_enqueue_scripts', 'wp_enqueue_global_styles_custom_css' );


Don't we still need to remove the wp_enqueue_global_styles_custom_css callback?

The plugin supports the latest two WordPress versions, so, assuming this is backported for 6.6, it's only when WordPress 6.7 is released that we can remove this (at that point, the plugin can assume the minimum version is 6.6, where that function is no longer relevant).

Oooh good point, it'll still be in core until 6.6 so yeah, I guess it'll need removing.

Actually checking the CSS output on the front end, I'd expect any custom CSS styles to be duplicated with this change (because wp_enqueue_global_styles_custom_css is still being enqueued in core) but they're not 🤔 I wonder why?

oandregal · 2024-02-29T16:54:46Z

lib/script-loader.php

@@ -63,6 +92,7 @@ function gutenberg_enqueue_global_styles() {
 * @since 6.2.0
 */
 function gutenberg_enqueue_global_styles_custom_css() {
+	_deprecated_function( __FUNCTION__, 'Gutenberg 17.8.0', 'gutenberg_enqueue_global_styles' );


I presume we also need to add a @deprecated 6.6 Use wp_enqueue_global_styles instead PHP doc, or something along those lines.

oandregal · 2024-02-29T17:14:33Z

lib/global-styles-and-settings.php

+ *
+ * @return string The global base custom CSS.
+ */
+function gutenberg_get_global_styles_base_custom_css() {


Can we simplify further and remove this function and gutenberg_get_global_styles_custom_css in favor of gutenberg_get_global_stylesheet? The styles.custom property is still the only one that has a dedicated function.

oandregal · 2024-02-29T17:17:30Z

lib/class-wp-theme-json-gutenberg.php

@@ -1284,21 +1284,68 @@ protected function process_blocks_custom_css( $css, $selector ) {
 	 * @return string The global styles custom CSS.
 	 */
 	public function get_custom_css() {


Same as below: can we deprecate/remove get_custom_css, get_base_custom_css, and get_block_custom_css_nodes, get_block_custom_css, in favor of the generic functions? IMO, it's too much code for a single style property that should behave like any other (and be part of the general algorithm).

That's a good point! It would be better if we didn't need as many functions, but I don't know why it was done this way in the first place. I'll look into it as a follow-up, thanks for reviewing!

Enqueue block custom CSS only when block renders on the page.

fb0d05f

tellthemachines added Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json CSS Styling Related to editor and front end styles, CSS-specific issues. labels Feb 14, 2024

tellthemachines requested review from oandregal, glendaviesnz, ajlende, ramonjd, andrewserong and t-hamano February 14, 2024 02:15

tellthemachines self-assigned this Feb 14, 2024

tellthemachines requested a review from spacedmonkey as a code owner February 14, 2024 02:15

tellthemachines added the [Type] Enhancement A suggestion for improvement. label Feb 14, 2024

tellthemachines added the Needs PHP backport Needs PHP backport to Core label Feb 14, 2024

ramonjd reviewed Feb 14, 2024

View reviewed changes

lib/global-styles-and-settings.php Outdated Show resolved Hide resolved

lib/global-styles-and-settings.php Show resolved Hide resolved

lib/global-styles-and-settings.php Outdated Show resolved Hide resolved

Fix sinces and return value

9b811b6

oandregal reviewed Feb 15, 2024

View reviewed changes

Move custom CSS enqueuing to gutenberg_enqueue_global_styles

7424bb0

tellthemachines requested review from Mamaduka and aristath February 19, 2024 06:42

aristath approved these changes Feb 19, 2024

View reviewed changes

tellthemachines merged commit 682fe72 into trunk Feb 28, 2024
59 checks passed

tellthemachines deleted the update/custom-css-enqueuing branch February 28, 2024 04:29

github-actions bot added this to the Gutenberg 17.9 milestone Feb 28, 2024

peterwilsoncc reviewed Feb 28, 2024

View reviewed changes

tellthemachines mentioned this pull request Feb 29, 2024

Format PHP inline comments correctly #59452

Merged

oandregal reviewed Feb 29, 2024

View reviewed changes

carolinan mentioned this pull request Mar 5, 2024

Allow custom CSS for theme.json elements #55614

Open

tellthemachines mentioned this pull request Apr 18, 2024

Improvements to class WP_Theme_JSON and its tests #60842

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enqueue block custom CSS only when block renders on the page. #58991

Enqueue block custom CSS only when block renders on the page. #58991

tellthemachines commented Feb 14, 2024

github-actions bot commented Feb 14, 2024

github-actions bot commented Feb 14, 2024 •

edited

ramonjd commented Feb 14, 2024

github-actions bot commented Feb 14, 2024 •

edited

ramonjd commented Feb 14, 2024

ramonjd left a comment

oandregal left a comment

oandregal commented Feb 15, 2024 •

edited

tellthemachines commented Feb 15, 2024

tellthemachines commented Feb 19, 2024

tellthemachines commented Feb 19, 2024

aristath left a comment

peterwilsoncc left a comment

peterwilsoncc Feb 28, 2024

peterwilsoncc Feb 28, 2024

peterwilsoncc Feb 28, 2024

peterwilsoncc Feb 28, 2024

peterwilsoncc Feb 28, 2024

oandregal Feb 29, 2024

tellthemachines Mar 1, 2024

tellthemachines Mar 1, 2024

oandregal Feb 29, 2024

oandregal Feb 29, 2024

oandregal Feb 29, 2024

tellthemachines Mar 1, 2024

Enqueue block custom CSS only when block renders on the page. #58991

Enqueue block custom CSS only when block renders on the page. #58991

Conversation

tellthemachines commented Feb 14, 2024

What?

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

github-actions bot commented Feb 14, 2024

github-actions bot commented Feb 14, 2024 • edited

ramonjd commented Feb 14, 2024

github-actions bot commented Feb 14, 2024 • edited

ramonjd commented Feb 14, 2024

ramonjd left a comment

Choose a reason for hiding this comment

oandregal left a comment

Choose a reason for hiding this comment

oandregal commented Feb 15, 2024 • edited

tellthemachines commented Feb 15, 2024

tellthemachines commented Feb 19, 2024

tellthemachines commented Feb 19, 2024

aristath left a comment

Choose a reason for hiding this comment

peterwilsoncc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Feb 14, 2024 •

edited

github-actions bot commented Feb 14, 2024 •

edited

oandregal commented Feb 15, 2024 •

edited