You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 URLsif (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
The text was updated successfully, but these errors were encountered:
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.
When using the plugin, image blocks inserted through Gutenberg do not get the
srcset
andsizes
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
andheight
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:
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 toCar-at-beach.png
while the remote site has it set to2021/10/Car-at-beach.png
The text was updated successfully, but these errors were encountered: