Editing Image Can Lead to Mixed Metadata

[rogerlos]

Summary

If an image is uploaded at a size allowing the creation of a defined image size (ie, "large", "twentyseventeen-featured-image", etc.) and the image is then edited to a size which doesn't allow that defined size to be created, the non-supported size can still be placed and will display the original image.

Steps to Reproduce

1. Upload an image which is slightly larger than a defined image size in a particular theme (for example, if using the WordPress default definition for "large" images, 1,024 pixels, upload an image 1,100 pixels wide)
2. Edit the image, and scale or crop it to be 1,000 pixels wide
3. Save edit
4. Within the post editor, "add media", select the "large" image size, and place within body of post

Expected Behavior

• Developer: The "large" image should not be able to be selected within the "Place Media" dialog
• Regular user: The "large" image placed should reflect the image edit

Result

The "large" size is selectable and the original image is placed within the page.

Other Effects

In this particular example, if the Media Library is in "grid" view, and our edited image is selected, the dialog which opens will display the incorrect original image, as the dialog preferentially uses the "large" image size.

Source of Behavior

I believe the problem stems from line 880 of https://core.trac.wordpress.org/browser/tags/4.9.5/src/wp-admin/includes/image-edit.php :

$meta['sizes'] = array_merge( $meta['sizes'], $img->multi_resize( $_sizes ) );

• $meta['sizes'] contains all of the sizes which were able to be created when the image was uploaded
• The return from $img->multi_resize() only has keys set for those sizes that can be created from the edited image
• Using array_merge keeps the original values not returned by $img->multi_resize(), despite the fact they are no longer valid for this edit

Fix

I believe the fix may be as simple as simply returning the result of $img->multi_resize() without merging it into the existing $meta['sizes'], which are mainly used in this context to create the _wp_attachment_backup_sizes array.

$meta['sizes'] = $img->multi_resize( $_sizes );

[rogerlos]

I tested the change I suggested locally and it does (seem to) fix the issue.

(I'll upload a patch if I get a chance in the next couple of days.)

[joemcgill]

Hi @rogerlos,

Thanks for the detailed report! I can confirm that I'm still able to reproduce this in WordPress 5.2-beta3. It's particularly obvious when cropping an image to a different aspect ratio. It's possible that there are people relying on this functionality to art direct different sizes. However, this would be relying on undocumented behavior, which I'm not sure we would want to support.

It might be worth looking at the history of that particular line of code to see if there are any clues as to why these arrays are being merged that isn't immediately obvious.

[antpb]

#37244 was marked as a duplicate.