Fix duotone filters in classic themes

[ajlende]

The style engine runs before blocks get rendered in classic themes, and duotone queues up styles while blocks are rendered, so the styles never get output on the page.

I've fixed it in this patch by generating the duotone styles again in wp_footer for classic themes.

Trac ticket: https://core.trac.wordpress.org/ticket/58734

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[jeryj]

I tested this on Twenty Twenty with the reproduction steps from the trac ticket and this is working well 👍🏻

[spacedmonkey]

Suggested change

	if ( ! empty( self::$used_global_styles_presets ) ) {
	wp_add_inline_style( 'core-block-supports', self::get_global_styles_presets( self::$used_global_styles_presets ) );
	}
	if ( ! empty( self::$block_css_declarations ) ) {
	wp_add_inline_style( 'core-block-supports', wp_style_engine_get_stylesheet_from_css_rules( self::$block_css_declarations ) );
	}
	$handle = 'core-block-supports';
	wp_register_style( $handle, false );
	if ( ! empty( self::$used_global_styles_presets ) ) {
	wp_add_inline_style( $handle, self::get_global_styles_presets( self::$used_global_styles_presets ) );
	}
	if ( ! empty( self::$block_css_declarations ) ) {
	wp_add_inline_style( $handle, wp_style_engine_get_stylesheet_from_css_rules( self::$block_css_declarations ) );
	}
	wp_enqueue_style( $handle );

You can't add inline styles without registering and enqueuing style.

This fixes the issue in my testing.

[ajlende]

I thought it was being registered already in script-loader, but it only looks like that happens when wp_style_engine_get_stylesheet_from_context returns something when SCRIPT_DEBUG is false.

wordpress-develop/src/wp-includes/script-loader.php

Lines 3049 to 3068 in cdf3ac0

	$core_styles_keys = array( 'block-supports' );
	$compiled_core_stylesheet = '';
	$style_tag_id = 'core';
	// Adds comment if code is prettified to identify core styles sections in debugging.
	$should_prettify = isset( $options['prettify'] ) ? true === $options['prettify'] : defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG;
	foreach ( $core_styles_keys as $style_key ) {
	if ( $should_prettify ) {
	$compiled_core_stylesheet .= "/**\n * Core styles: $style_key\n */\n";
	}
	// Chains core store ids to signify what the styles contain.
	$style_tag_id .= '-' . $style_key;
	$compiled_core_stylesheet .= wp_style_engine_get_stylesheet_from_context( $style_key, $options );
	}
	// Combines Core styles.
	if ( ! empty( $compiled_core_stylesheet ) ) {
	wp_register_style( $style_tag_id, false );
	wp_add_inline_style( $style_tag_id, $compiled_core_stylesheet );
	wp_enqueue_style( $style_tag_id );
	}

Would it be okay to always register core-block-supports?

[spacedmonkey]

@ajlende Didn't know about that. You will need to enqueue it as well. Like this

         wp_register_style( $style_tag_id, false );
	// Combines Core styles.
	if ( ! empty( $compiled_core_stylesheet ) ) {
		wp_add_inline_style( $style_tag_id, $compiled_core_stylesheet );
	}
	wp_enqueue_style( $style_tag_id );

[ajlende]

I just registered and enqueued a new stylesheet. The 'core-block-supports' name is semi-dynamic, so we'll run into issues in the future if someone tries to add to $core_styles_keys and doesn't update duotone.

It's unfortunate that the duotone block supports styles won't be grouped with the rest of block supports, but it's probably not that big of a deal.

[spacedmonkey]

This PR doesn't fix the issue in my testing. I have added a suggested solution in the comments.

[spacedmonkey]

Works in my testing.

[tellthemachines]

Thanks, this fixes the issue for me!

Does this need to be fixed in Gutenberg too?

[ajlende]

Does this need to be fixed in Gutenberg too?

Yeah, we'll want to port this change and #4831 back into the plugin once they're merged here to keep things in sync.

[tellthemachines]

Committed in r56225 / 23a1516.

[t-hamano]

This commit doesn't seem to have been backported to Gutenberg, so I've submitted the PR below.

WordPress/gutenberg#54778