wp_render_duotone_support() in > 5.9 prevents duotone filters being applied when loading page content with ajax.

[slr1979]

Description

I am using a 3rd party theme which uses ajax/pjax page reloading. On upgrading from 5.8.3 to 5.9 and 5.9.1, I noticed that my images with duotone filters were no longer been applied when refreshing of content via ajax/pjax.

The wp_render_duotone_support() filter in > 5.9 does not allow any scope for use cases such as these and does not allow theme developers to control how/where the styles etc. are placed. The function assumes that a theme will being using hard pages reloads for every page. It would be great to find a solution that allowed more control over the placement of the Duotone styles etc. especially in the frontend. At this time I will be forced to use the solution below , stay on 5.8.3 or abandon the use of Duotone. Not ideal.

Step-by-step reproduction instructions

1. Reload page content/main container using pjax/ajax on 5.8.3 - Duotone filters are successfully applied as relevant styles/filters/svg are within the main container which is reloaded via ajax/pjax.
2. Reload page content/main container using pjax/ajax on > 5.9. - Duotone filters are not applied as relevant styles/filters/svg are placed in wp_footer which obviously does not get updated when reloading the main container using ajax/pjax .

Screenshots, screen recording, code snippet

So far, the only solution I have been able to find is to remove the wp_render_duotone_support() filter within my theme and replace it with a copy of the function from 5.8.3. I am unsure of the effect this may have on the block editor but it does not appear to cause any issues so far. As per other reports I am also forced to remove global styles and svg filters as they cause layout conflicts with the theme styles.

global $wp_version;
if ( version_compare( $wp_version, '5.9', '>=' ) ) {
	function remove_global_css() {
		remove_action( 'wp_enqueue_scripts', 'wp_enqueue_global_styles' );
		remove_action( 'wp_body_open', 'wp_global_styles_render_svg_filters' );
		remove_filter( 'render_block', 'wp_render_duotone_support', 10, 2 );
	}
	add_action('init', 'remove_global_css');

	function wp_render_duotone_support_58( $block_content, $block ) {
		$block_type = WP_Block_Type_Registry::get_instance()->get_registered( $block['blockName'] );

		$duotone_support = false;
		if ( $block_type && property_exists( $block_type, 'supports' ) ) {
			$duotone_support = _wp_array_get( $block_type->supports, array( 'color', '__experimentalDuotone' ), false );
		}

		$has_duotone_attribute = isset( $block['attrs']['style']['color']['duotone'] );

		if (
			! $duotone_support ||
			! $has_duotone_attribute
		) {
			return $block_content;
		}

		$duotone_colors = $block['attrs']['style']['color']['duotone'];

		$duotone_values = array(
			'r' => array(),
			'g' => array(),
			'b' => array(),
		);
		foreach ( $duotone_colors as $color_str ) {
			$color = wp_tinycolor_string_to_rgb( $color_str );

			$duotone_values['r'][] = $color['r'] / 255;
			$duotone_values['g'][] = $color['g'] / 255;
			$duotone_values['b'][] = $color['b'] / 255;
		}

		$duotone_id = 'wp-duotone-filter-' . uniqid();

		$selectors        = explode( ',', $duotone_support );
		$selectors_scoped = array_map(
			function ( $selector ) use ( $duotone_id ) {
				return '.' . $duotone_id . ' ' . trim( $selector );
			},
			$selectors
		);
		$selectors_group  = implode( ', ', $selectors_scoped );

		ob_start();

		?>

		<style>
			<?php echo $selectors_group; ?> {
				filter: url( <?php echo esc_url( '#' . $duotone_id ); ?> );
			}
		</style>

		<svg
			xmlns:xlink="http://www.w3.org/1999/xlink"
			viewBox="0 0 0 0"
			width="0"
			height="0"
			focusable="false"
			role="none"
			style="visibility: hidden; position: absolute; left: -9999px; overflow: hidden;"
		>
			<defs>
				<filter id="<?php echo esc_attr( $duotone_id ); ?>">
					<feColorMatrix
						type="matrix"
						<?php // phpcs:disable Generic.WhiteSpace.DisallowSpaceIndent ?>
						values=".299 .587 .114 0 0
								.299 .587 .114 0 0
								.299 .587 .114 0 0
								0 0 0 1 0"
						<?php // phpcs:enable Generic.WhiteSpace.DisallowSpaceIndent ?>
					/>
					<feComponentTransfer color-interpolation-filters="sRGB" >
						<feFuncR type="table" tableValues="<?php echo esc_attr( implode( ' ', $duotone_values['r'] ) ); ?>" />
						<feFuncG type="table" tableValues="<?php echo esc_attr( implode( ' ', $duotone_values['g'] ) ); ?>" />
						<feFuncB type="table" tableValues="<?php echo esc_attr( implode( ' ', $duotone_values['b'] ) ); ?>" />
					</feComponentTransfer>
				</filter>
			</defs>
		</svg>

		<?php

		$duotone = ob_get_clean();

		// Like the layout hook, this assumes the hook only applies to blocks with a single wrapper.
		$content = preg_replace(
			'/' . preg_quote( 'class="', '/' ) . '/',
			'class="' . $duotone_id . ' ',
			$block_content,
			1
		);

		return $content . $duotone;
	}
	add_filter( 'render_block', 'wp_render_duotone_support_58', 10, 2 );
}

Environment info

WP 5.8.3 and WP 5.9.1, with Waveme (Flatfull)
All Browsers
Desktop with WIndows 10

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[slr1979]

Could anyone provide some feedback or other potential workarounds regarding this filter? I would appreciate it.

Placing styles in the footer may be good for FSE or standard WP themes but I can see implementations like this causing issues with ajax driven themes across the theme developer community. IMHO styles in the footer is not a normal design principle and creates headaches for theme developers who need inline styling within blocks.

[skorasaurus]

@ajlende - could you sharing the design decision for moving it to the footer if you know?

[ajlende]

SVGs are not valid children of the <head> (MDN), so they have to appear somewhere in the <body>.

In 5.8.3, where it seemed to be working for you, they were included directly after the block, but this was causing issues with CSS selectors in themes. #30500, #32083

Later a bug in Safari was found with rendering in the footer, so it was moved to wp_body_open instead because that was the only place that it would render correctly. #36754

Safari

Firefox/Chrome/Edge

Then there was a bug with classic themes that didn't support wp_body_open and we wanted to keep the other generated styles (like the layout support used in the columns/group/etc. blocks) consistent, so it was moved back to wp_footer along with a repaint hack for Safari to fix the incorrect colors. #37954

So, @slr1979, I can't test Waveme because it isn't open source, but if the issue is with styles in the footer, do you also have issues with blocks that use layout support? (buttons, columns, comments-pagination, group, navigation, post-content, post-template, query, query-pagination, or social-links blocks)

[slr1979]

@ajlende Many thanks for the thorough explanation. It is very helpful. I am fairly new to Gutenberg and the block editor so please bear with me.

I do appear to have issues with at least button blocks too after checking today so that is not good. eg. center-aligned buttons end up aligned left after pjax refresh etc. The theme developer does use theme supports. I believe this means that core/global styles etc are loaded by default? At the moment the only way I can resolve this is to apply a css class of aligncenter to the button block itself which allows the global style to apply. Is there something I can do to solve this without having to resort to manually adding classes to the block?

// Add support for Block Styles.
add_theme_support( 'wp-block-styles' );

// Add support for full and wide align images.
add_theme_support( 'align-wide' );

// Add support for editor styles.
add_theme_support( 'editor-styles' );

// Add support for responsive embedded content.
add_theme_support( 'responsive-embeds' );

Alike the button blocks, the issue with duotone is only happening because the svg styles/filters have been moved into the footer outside the pjax containers.

With 5.8.3, the styles/filters for Duotone were loaded just after the image. This was great as pjax is updating one or several central containers within the body so every time a page is loaded with pjax, the new duotone inline css is within that container.

With < 5.9, as the svg styles/filter are rendered into the footer. As pjax/ajax page refeshing only updates specific containers within the body, styles that are outside these containers,( that would normally be rendered on a hard refresh ) are not rendered when refreshing a pjax container. I am sure you are well aware of this.

My issue is that the current implementation of the Duotone filters does not really accommodate ajax driven content in general. Normal layout blocks are handled fine with global styles in the head but elements that generate new styles from page to page (like Duotone images) can only be rendered if a page is loaded 'in full' NOT when only parts of the page are updated.

Obviously, this may appear to be an edge case but from my point of view, it would be amazing and maybe even essential to have a filter or solution that took this usage into account. It is still common for people to create single page applications that often require some inline styling for elements that update via pjax/ajax.

Do you think there will be a way to remedy this or should I stick to my fix from 5.8.3?

Your help is very much appreciated.

[ajlende]

I do not appear to have any issue with blocks that use layout support but this is probably because the theme developer uses theme supports. I believe this means that core/global styles etc are loaded into the head by default?

The add_theme_support calls just add static styles, not the dynamic ones in question. But it looks like I was mistaken about layout. I missed this change #38750 that moved the dynamic layout styles into the head.

Obviously, this may appear to be an edge case but from my point of view, it would be amazing and maybe even essential to have a filter or solution that took this usage into account.

Not an edge case at all! Duotone and other styles like it should work in all of the contexts that themes typically render it in.

Do you think there will be a way to remedy this or should I stick to my fix from 5.8.3?

@andrewserong is working on a styles engine (#38167) to unify how styling is done. This seems to me like something that could be resolved along with those efforts. The styles engine should consider SVGs that need to be rendered in the body along with the CSS that can be rendered wherever.

[slr1979]

@ajlende. Please re-read my previous comment as I edited it just minutes before your reply! I am having issues with some of my layout and blocks after all. It appears that some of the styling that was applied before I updated to 5.9.1 is in the individual blocks as classes. If I remove those 'hard-coded' classes and use the dynamic layout styles etc, it all goes horribly wrong.

Do you anticipate these modifications taking long ? I am due to go into production in the next week or so. I can get around it in my Gutenberg pages by using my 5.8.3 based filter (from my first comment) and putting classes into each block but it would be great to be able to use the editor in the way it was meant to be used and get proper ajax compatibility so to speak.

It is great to know I am not imaging these issues or jumping the gun thinking it should work as I hope! Do get back to me with any further thoughts.

[slr1979]

@ajlende and yes, social icons have gone wrong too.

[ajlende]

Do you anticipate these modifications taking long?

Yes, probably, since this is affecting a number of areas in a rather fundamental way. It's good that you've found a workaround, but it's unfortunate that you may need to use it for a while until this is resolved.

Social icons have gone wrong too.

It seems like it may be related to #35376 as well. Do the social icons look like this?

[slr1979]

@ajlende Pretty much...

Can get them to stick with this in child stylesheet

.wp-block-social-links{
	display: flex;
       gap: 0.5em;
       flex-wrap: nowrap;
      align-items: center;
}

.wp-block-social-links.alignright{
	float:right !important;
}

Obviously, again not ideal for quick page edits or design changes but would rather have 5.9.1 with up-to-date security fixes and a slightly dodgy Gutenberg. I know you guys are trying really hard to cover an awful lot of bases but in some respects, it almost feels that it would be best for WP to backport to the version of Gutenberg pre 5.9! I'm sure it will come good in the end though but at the moment it feels slightly frustrating. It was all going so well on my dev until 5.9 ;-)