Duotone not working in 6.3

[alh0319]

When the WordPress Accessibility Day website updated to 6.3 today the duotone filters we have set on images stopped working. Rolling core back to 6.2.2 solves this problem.

#58994 references changes to duotone in 6.3, however, bugs still exist.

Here's an example page on a site running 6.3 where duotone is no longer working: ​https://2023.wpaccessibility.day/about/organizers/.

[poena]

Hi Amber!

Can you add some more information?
How does the custom theme register the duotone? Does the theme use theme.json?
(I tried looking at ​https://github.com/wpaccessibility/wpaccessibilityday but that seems to be the wrong place)

Is there any change when all plugins are deactivated?

In what way is it broken? I mean, I can see that they are not applied on the front of the example site, but is the option available in the editor?
If so, are the colors working in the editor?

[joedolson]

They're declared via theme.json. I think this is caused by the loading optimizations; we weren't assigning the duotone patterns through the editor, but creating a pattern using nth selectors in a grid that was produced by a shortcode. Now that the duotone code is only loaded if used, it's not available for use outside of editor generated content.

You can look at the repo at ​https://github.com/wpa11yday/wpaccessibilityday

[joedolson]

Caused by https://core.trac.wordpress.org/changeset/56226. I'm not sure, strictly speaking, that this is a core bug, but it is a major change in behavior for anybody making use of duotone filters not directly through the editor.

[joedolson]

What's lacking here, I think, is any way to get output the duotone filters outside of block usage. I don't see an obvious filter where I could override this. @spacedmonkey is there any way to override the the duotone lazy loading to force the filters to render?

[ajlende]

A workaround for now that will likely work is re-adding the old hooks.

<?php
// Render all duotone SVG filters.
add_action( 'wp_body_open', 'wp_global_styles_render_svg_filters' );
add_action( 'in_admin_header', 'wp_global_styles_render_svg_filters' );

It'll render all of the SVG filters that can be accessed in CSS with filter: url('#wp-duotone-id');.

[ajlende]

I wonder if instead of a filter it would make sense to add a property that forces rendering to the duotone filters in theme.json or an array of filters to render or something.

[spacedmonkey]

I think this is related to #58555. Can @onemaggie or @isabel_brison provide context.

[isabel_brison]

Won't there be a performance impact to just re-adding those filters? Could we perhaps make them render optionally with a theme support or something?

[joedolson]

Personally, I'd be happy with a filter that allowed me to render duotone filters using standard WP conditionals, e.g. is_page(), is_singular(), etc., so that I could continue to use them without needing blocks. @aljende's suggestion would work for me, with some conditionals added. I like not having them rendered automatically at all times - that performance benefit is well worth keeping - but after numerous releases having them always available, this is probably not the only use case that broke.

[spacedmonkey]

I recommend that we undeprecate functions like wp_get_global_styles_svg_filters and wp_global_styles_render_svg_filters. Then we put out a dev note explain the changes to Duotone. Anyone that is using duotone is a uncommon way, will have to update their codebase to use wp_global_styles_render_svg_filters if needed.

[joemcgill]

I think we definitely want to avoid globally adding the wp_global_styles_render_svg_filters, but some way for developers to opt in would be great. For a fix to go into a minor, we'll need someone to implement an approach that fixes the issue without reintroducing the performance regression they were removed to fix.

[pbiron]

This ticket came up in the Upgrade/Install component meeting today. Shouldn't the component for this ticket be Editor (unless of course, the direction of the fix is to do something in the upgrader to clear the transient(s))?

[joemcgill]

Good catch, @pbiron. I've changed the component. @isabel_brison I'm not clear on if we need to create a related issue in the Gutenberg repo for this or not, could you advise?

[isabel_brison]

We might need to make adjustments to the compatibility layer in the plugin, e.g. here: ​https://github.com/WordPress/gutenberg/blob/trunk/lib/compat/wordpress-6.3/script-loader.php#L13

I guess we can create a Gutenberg ticket once we have a better idea of how to fix this.

[spacedmonkey]

@isabel_brison Are you going to make a ticket on gutenberg for this?

[ajlende]

I guess we can create a Gutenberg ticket once we have a better idea of how to fix this.

Are you going to make a ticket on gutenberg for this?

​https://github.com/WordPress/gutenberg/issues/53662

@isabel_brison @spacedmonkey I opened this one a while ago and forgot to share it here. The focus at the time I made it was around adding an option, but we can use the same issue for updating hooks if that's what we end up doing instead.

[joemcgill]

Noting the lack of movement here or in the Gutenberg ticket, I'm moving this to the 6.4 milestone, but it seems like it's at risk of not making that release either without action soon.

[joemcgill]

I was rereading the ​related Gutenberg ticket that @ajlende posted and noticed that this is being considered an enhancement, since supporting the Duotone filters outside of block markup was intentionally removed.

Accordingly, I'm updating the type of this ticket and moving to a Future Release, where it can be added to another milestone once this is addressed in the Gutenberg repo.