Full Site Editing: Add image filters to the template content output

[Copons]

Changes proposed in this Pull Request

• Add more the_content filter functions to the template content output in order to fix how the manually resized images in the template part look on the front end.

Before	After

These are the default the_content filters that we should roughly use in FSE, and here are the prepend_attachment and wp_make_content_images_responsive functions.

Testing instructions

• Either:
  • Apply D33228-code and sandbox a WPCOM FSE site with Maywood.
  • Or just open a non-WPCOM FSE site with Maywood.
• Add an image to the header, and resize it using the resize handles (not the size selector in the sidebar).
• Preview the image: the size should be the same.
• Repeat the test on the post content, and make sure the image size is the same in both editor and front end.

Fixes #36020

[matticbot]

Test live: https://calypso.live/?branch=fix/36020-fse-resized-images

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[Copons]

@iamtakashi I've noticed that non explicitly aligned images are always centered in the front end.
Is it the intended behaviour?

[iamtakashi]

@Copons Hmm, it appears left-aligned to me. Do you have a URL where I can see what you're seeing?

[Copons]

@iamtakashi Sorry, you're right, I forgot to mention "manually resized images".

This is on a non-FSE site using Varia (but the same happens with Maywood):

[iamtakashi]

@Copons Oh.. nice catch. We need to fix this in Varia and child themes.

[gwwar]

Non-blocking, but I think we'll probably want to start tracking these as units in the isolated suite on the wpcom side. It makes it much easier to visualize the post_content transform and catch regressions.

[gwwar]

Feel free to DM if you need help with test setup.

[gwwar]

Tested this on wpcom, but I think this is about right. Some other behavior to note:

1. Header images can't be resized past their natural image dimensions
2. Also ran into the image alignment issue after resizing (centering when it shouldn't in the published view)

Maybe get a +1 for if the filters look correct

[Copons]

@gwwar

2. Also ran into the image alignment issue after resizing (centering when it shouldn't in the published view)

Yup, noted this in an earlier comment: #36026 (comment)
It appears to be a theme issue unrelated to FSE.

Maybe get a +1 for if the filters look correct

I'll wait for a +1 and meanwhile I'll investigate this:

1. Header images can't be resized past their natural image dimensions

It might be as easy as having max-width: none (instead of 100%) on .is-resized images. 🤔

EDIT: ditto for this: it's a theme thing. I'll ship this and open an issue tagging theme folks too.

[mattwiebe]

This will need changing on the WPCom side as we handle things differently there. The wp_make_content_images_responsive function is removed from the_content filter and new filters are added via WPCOM_Responsive_Images::set_filters.

Probably the easiest thing would just be something like:

if ( defined( 'IS_WPCOM') && IS_WPCOM ) {
  $instance = new WPCOM_Responsive_Images;
  $content = $instance->make_content_images_responsive( $content );
} else {
  $content = wp_make_content_images_responsive( $content );
}

I don't know for sure if that will work, but it should get us on the right track.

[Copons]

Thanks @mattwiebe, that's a very good suggestion and... there even was a todo comment a few lines above pointing to it!
I'll give it a try asap.

[Copons]

I've added @mattwiebe's suggestion in 8834b9a.

It works on my local environment and also on my sandboxed test site on WPCOM.

Trying it was as simple as just manually copying and pasting these few lines of code into:
wp-content/plugins/full-site-editing-plugin/0.7/full-site-editing/templates/class-wp-template.php
and perform the test steps provided in the PR description.

[vindl]

So far we have tried to avoid adding any Dotcom specific code in the FSE plugin. As a non-blocking suggestion: we could add a filter here and modify the content from dotcom side in our mu-plugin code.

[Copons]

Oooh, very good point!
It's an easy enough change, I'll do it right now!

[Copons]

This now requires D33228-code to work on WPCOM.

[noahtallen]

With the filter being in mu plugins, will this PR work for Atomic? (or is this just a workaround for wpcom which isn't the case in Atomic sites?)

[vindl]

With the filter being in mu plugins, will this PR work for Atomic? (or is this just a workaround for wpcom which isn't the case in Atomic sites?)

Atomic sites should behave as other self-hosted sites, I don't think they have this Dotcom specific code accessible or running (unless it's explicitly ported via wpcomsh).

[Copons]

@noahtallen what @vindl said. 🙂
I'm confused about this too, because—even if it's not the case here—what would happen on Simple->Atomic sites if the WPCOM filter was very different than the Core one?
(Rethorical question of course 😄)

Anyway, I think this doesn't depend on the WPCOM diff, and it's good to go now!
Thanks y'all for the reviews and discussion.