Make WordPress Core

Opened 11 months ago

Last modified 9 months ago

#59017 new enhancement

Duotone not working in 6.3

Reported by: alh0319's profile alh0319 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 6.3
Component: Editor Keywords: needs-patch
Focuses: css, performance Cc:


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:

Change History (23)

#1 @poena
11 months ago

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 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?

#2 @joedolson
11 months ago

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

#3 @joedolson
11 months ago

Caused by 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.

#4 @joedolson
11 months ago

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?

#5 @ajlende
11 months ago

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

// 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');.

#6 @ajlende
11 months ago

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.

#7 @spacedmonkey
11 months ago

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

#8 @isabel_brison
11 months ago

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?

#9 @spacedmonkey
11 months ago

  • Focuses performance added

#10 @joedolson
11 months ago

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.

This ticket was mentioned in Slack in #core-upgrade-install by pbiron. View the logs.

10 months ago

#12 @spacedmonkey
10 months ago

  • Milestone changed from Awaiting Review to 6.3.2

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.

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.

10 months ago

#14 @joemcgill
10 months ago

  • Keywords needs-patch added

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.

This ticket was mentioned in Slack in #core-upgrade-install by costdev. View the logs.

10 months ago

#16 @pbiron
10 months ago

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))?

#17 @joemcgill
10 months ago

  • Component changed from Upgrade/Install to Editor

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?

#18 @isabel_brison
10 months ago

We might need to make adjustments to the compatibility layer in the plugin, e.g. here:

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

#19 @spacedmonkey
10 months ago

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

#20 @ajlende
10 months ago

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?

@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.

This ticket was mentioned in Slack in #core by joemcgill. View the logs.

9 months ago

#22 @joemcgill
9 months ago

  • Milestone changed from 6.3.2 to 6.4

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.

#23 @joemcgill
9 months ago

  • Milestone changed from 6.4 to Future Release
  • Type changed from defect (bug) to enhancement

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.

Note: See TracTickets for help on using tickets.