Fix duotone render in non-fse themes

[ajlende]

Description

Fixes #37598

It seems that the render_block filter is being called after the wp_body_open hook in non-fse themes, so this change will fall back on wp_footer if it has already been called.

We switched from wp_footer to wp_body_open in #36754 because Safari renders blocks incorrectly when the SVG filter comes after the content that it is filtering. Switching back unfortunately means that duotone rendering will be incorrect for non-fse themes when viewed from Safari.

How has this been tested?

1. Activate a non-fse theme like Blank Canvas.
2. In a post, add an image with a duotone filter.
3. Publish and view the post to see the filter applied.

Screenshots

Using the Blank Canvas theme using the one of the default duotone filters applied to the block

Before:

After:

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).
• I've updated related schemas if appropriate.

[youknowriad]

Is there a way to force a repaint in safari (since it seems that fixes the issue according to the link PR)

[ajlende]

Is there a way to force a repaint in safari (since it seems that fixes the issue according to the link PR)

It's going to get messy if we do. We'd have to do a user agent check and add a script for each duotone filter to hide and show the filtered content in Safari according to a blog post that I found.

[youknowriad]

My main concern with wp_body_open is that we're creating inconsistencies between the different ways we render server side styles. Layout block support use wp_footer right now and ideally we could share code between all these server side styles to enqueue the styles in the exact same way.

Anyway, my comments shouldn't block you here but as part of the discussion here #37495 I think ultimately enqueue this kind of styles should be consistent.

[ajlende]

@youknowriad, I gave the repaint a go in Safari. It's a little messy, and I sometimes see the images flash, but it seems to work.

ideally we could share code between all these server side styles to enqueue the styles in the exact same way.

It would be nice to have a better system for adding things like this—I keep thinking about other SVG filter opportunities because there's a lot of things that they can do, but it's kind of clunky to add them right now.

[youknowriad]

This seems like the best fix I can think of. Thanks

[noisysocks]

I can't backport this PR as it depends on #36236 which was not backported into 5.9. Ordinarily I would backport both PRs but #36236 contains quite a bit of new PHP code and we are very late into the RC period.

I've put the Backport to WP Minor Release on both PRs so that both fixes are included in 5.9.1 which should follow 5.9 very quickly.