Does not work with wp_filter_content_tags filter.
When using the plugin, image blocks inserted through Gutenberg do not get the srcset and sizes attributes automatically populated as it does on the main site using wp_filter_content_tags.
The first reason this doesn't happen is because the image blocks do not have the width and height attributes set and thus fails the following conditional. If the width/height attributes were present, it would work.
Even without the attributes, WordPress should be able to autodetect the dimensions based on the postmeta, but fails because it's comparing the the image filename to a full remote URL and thus this conditional also fails.
A quick fix on my end was the following filter:
add_filter('wp_image_src_get_dimensions', function ($dimensions, string $image_src, array $image_meta, int $attachment_id) {
if ($dimensions !== false || empty($image_meta['sizes'])) {
return $dimensions;
}
$src_filename = wp_basename($image_src);
foreach ($image_meta['sizes'] as $image_size_data) {
// Check for AMF remote URLs
if (filter_var($image_size_data['file'], FILTER_VALIDATE_URL) === false) {
continue;
}
// Compare against the filename rather than the full URL.
$image_size_filename = wp_basename($image_size_data['file']);
if ($src_filename === $image_size_filename) {
$dimensions = [
(int) $image_size_data['width'],
(int) $image_size_data['height'],
];
break;
}
}
return $dimensions;
}, 10, 4);
I'm guessing the correct fix for this would be to set the width/height attributes on the image tag when inserted with Gutenberg. I have not looked into why this is happening.
If it matters, I noticed that postmeta of the attachment had the file property set to the filename, not the year-month relative path (in case you do not use year-month folders when testing this).
So the sub site has the file property set to Car-at-beach.png while the remote site has it set to 2021/10/Car-at-beach.png
I don't think we can change the behaviour in gutenberg easily and I imagine there's a reason it's not added there, probably for the drag to resize type behaviour.
The fix you describe above is probably the best we could do, keeping in mind the source site might have totally different image sizes registered or configured than the sub site.
Thanks for the report and for sharing a workaround.
Re. the file name I'm not sure it's a big problem given the image is from another site / source. I imagine most external providers would just be saving that value.