Fix duotone theme cache

[ajlende]

Description

Fix #36208

Duotone filters were getting rendered via a side-effect of the global stylesheet generation. Because the stylesheets were cached, the duotone filter rendering wasn't called when the cache hit.

This adds a separate cache for the SVG filters which have to be rendered in the footer of the document, separate from the stylesheet.

How has this been tested?

1. Ensure that your environment doesn't have any of these consts set:

   gutenberg/lib/compat/wordpress-5.9/get-global-styles-and-settings.php

   Lines 79 to 85 in 3e84b56

   	$can_use_cached = (
   	( empty( $types ) ) &&
   	( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) &&
   	( ! defined( 'SCRIPT_DEBUG' ) || ! SCRIPT_DEBUG ) &&
   	( ! defined( 'REST_REQUEST' ) || ! REST_REQUEST ) &&
   	! is_admin()
   	);

2. Apply a duotone filter to a theme via the theme.json file:

{
    "styles": {
        "blocks": {
            "core/image": {
                "filter": {
                    "duotone": "var(--wp--preset--duotone--default-filter)"
                }
            }
        }
    }
}

{
    "settings":  {
        "color":  {
            "duotone":  [
                {
                    "colors": [ "#000", "#B9FB9C" ],
                    "slug": "default-filter",
                    "name": "Default filter"
                }
            ]
        }
    }
}

3. See that the duotone filters are loaded on all images and persist on subsequent reloads

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[MaggieCabrera]

Thank you for this, so quick! This seems to fix the cache issues I was seeing on Skatepark myself

[oandregal]

Hey, thanks for creating the PR. This looks a bit involved and I have my brain cycles focused on today's freeze. Would you mind if I come back to this on Monday? It's a bug that we need to fix so we have more leeway than for features.

[ajlende]

Added a few comments to help with reviewing

[ajlende]

Previously this was handled by gutenberg_render_duotone_filter_preset (above), but now has to be its own separate call.

[ajlende]

This whole function was just moved below without modification.

[ajlende]

Split this into a few functions

• gutenberg_get_duotone_filter_property for generating the filter url() property
• gutenberg_get_duotone_filter_svg for creating SVG
• gutenberg_render_duotone_filter for rendering the SVG in the appropriate place

This way the SVG can be generated and saved in get_svg_filters below which can be cached.

The old gutenberg_render_duotone_filter_preset still exists below for value_func and for backwards compatibility.

[oandregal]

Hey, I wasn't able to look at this yet for reasons. I hope to be able to look at this when the beta1 is in a better place (probably next week?).

One overall comment I'd like to share is that we need to be careful with changes to code that landed in WordPress. For example, changes to code in lib/block-supports/duotone.php that was part of WordPress 5.8 (see) needs to either stay the same (in terms of name, parameters, etc) or be deprecated (some examples in this file).

[ajlende]

Hey, I wasn't able to look at this yet for reasons.

No worries, there is a lot going on for the beta release and this is just a bug fix that can go in any time. Feel free to add me on any reviews for things, especially around the color palette work, if you need some help with reviews.

One overall comment I'd like to share is that we need to be careful with changes to code that landed in WordPress. For example, changes to code in lib/block-supports/duotone.php that was part of WordPress 5.8 (see) needs to either stay the same (in terms of name, parameters, etc) or be deprecated (some examples in this file).

Yep, all functions that existed before still exist with the same signature. I noticed a documentation problem with one of them that I fixed, and I updated some of my review comments to help point to where they all moved since it isn't obvious from the diff.

[oandregal]

Hey, I've been looking at this during the morning and I have a couple of minor details that I'll push shortly if you don't mind (where code lives and function names to make sure backporting is easy).

I need to review the duotone block supports a bit more and understand what's new in 5.9 and what existed in 5.8. My current understanding of how duotone works and how this PR changes it:

1. The block styles defined in theme.json that use the filters: .wp-block-image{ filter: var(--wp--preset--duotone--<slug>)}. Uses the value directly from theme.json. Work as before.

2. The CSS Custom properties to be used in theme.json: --wp--preset--duotone--<slug>: url(#wp-duotone-<slug>). Uses gutenberg_render_duotone_filter_preset. Work as before.

3. The SVGs that use the ID. <svg id="wp-duotone-<slug>" />:

   • Before: side-effect of calling gutenberg_render_duotone_filter_preset => hooked the SVG generation to wp_body_open (right after body tag is opened).
   • After: hooks the SVG generation to either admin_footer or wp_footer filters (right before the body tag is closed), that uses a new public function gutenberg_get_global_styles_svg_filters to render them.

Is this correct? If so, I've got a couple of questions:

• Can we remove the code that render the SVGs using the wp_body_open filter if we're using now admin_footer or wp_footer filters instead?
• I have a vague memory that there were some issues depending on where we rendered the SVGs. Is before the closing body a good place? Does it work for all browsers?

[oandregal]

@ajlende got to test this a bit and this is what I ran into. Env: WordPress 5.8, so I could test this PR.

I've used the TwentyTwentyTwo theme and put this bit under styles.blocks:

			"core/image": {
				"filter": {
					"duotone": "var(--wp--preset--duotone--foreground-and-background)"
				}
			}

It worked for the front & post editor (reloading the page still showed me the images and they used that filter). The images in the site editor didn't get the filter, though.

Then I've tried with a duotone coming from core:

			"core/image": {
				"filter": {
					"duotone": "var(--wp--preset--duotone--blue-red)"
				}
			}

and I ran into the same issue as in trunk (the image disappears) in the frontend & post editor. The site editor images loaded but had no filters applied.

[oandregal]

@ajlende I've pushed 81ae91e that fixes the issue with default presets, so the only thing missing would be to make sure that this works in the site editor as well?

[oandregal]

I've tested on trunk and the filters are not loaded for images in the site editor either. This can be looked independently from this PR.

[oandregal]

Can we remove the code that render the SVGs using the wp_body_open filter if we're using now admin_footer or wp_footer filters instead?

Removed at 2109308 We still need to use gutenberg_render_duotone_filter to render the custom filters the user may create by itself and attach to an image.

[oandregal]

I've tested this in the following scenarios:

• custom filter added by the user
• default filter used by the theme through theme.json
• theme filter used by the theme through theme.json

And it works well in the post and frontend. There's some issue in the site editor but it exists in trunk already, so can be looked up separately.

I've pushed some code changes here, so I'll let @ajlende merge this one when he feels is right, in case some of what I've done has caused havoc somewhere.

[ajlende]

I've tested on trunk and the filters are not loaded for images in the site editor either. This can be looked independently from this PR.

Yeah, this was a know issue I'm taking another look at now. #35331

[ajlende]

We discussed these a bit on Slack, but I'll summarize here for future reference.

Can we remove the code that render the SVGs using the wp_body_open filter if we're using now admin_footer or wp_footer filters instead?

One of the places we render duotone filters is for the user-defined custom per-block filters and the other is for the filters defined in theme.json. If we can somehow register the custom filters into some global store and access them from wp_get_global_styles_svg_filters then we can use the singular footer render. But that seems like it would be a bit complicated, so we'll leave that improvement for another day.

[ajlende]

I have a vague memory that there were some issues depending on where we rendered the SVGs. Is before the closing body a good place? Does it work for all browsers?

Rendering in wp_body_open was a fix for Safari incorrectly rendering filters that appeared in the DOM after the content that they were applied to. Safari won't render filters at all if they're placed in the head of the document, so wp_body_open is what I landed on.

I updated the footer rendering to be in wp_body_open and updated the inline documentation for why that was chosen to make it a little more clear.

[scruffian]

Thanks for merging this!

[Mamaduka]

Cherry-picked for 5.9.1.