id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	focuses	prnumber
48453	Regression: Implied contract between image sub-size filenames and their base filename now broken	ianmjones	azaozz	"Since the introduction of big image scaling and automatic rotation of images in #47873 and further refined in #48304, the base file name for an image stored in the `_wp_attached_file` postmeta value may no longer directly relate to the filenames of image sub-sizes held in the `_wp_attachment_metadata` postmeta value's `sizes` array.

This now means the local URL for a thumbnail might be:

https://example.com/wp-content/uploads/2019/10/image-150x150.jpg

But it's base URL might be any of the following:

https://example.com/wp-content/uploads/2019/10/image-scaled-2560.jpg
https://example.com/wp-content/uploads/2019/10/image-rotated.jpg
https://example.com/wp-content/uploads/2019/10/image.jpg

That `image-scaled-2560.jpg` filename is dependent on a filterable threshold, and could change depending on themes or plugins that are installed and any criteria that might apply.

Previously there was an implied contract between the filenames for elements of the `sizes` array, they were the base file name with `-WWWWxHHHH` as the suffix depending on their width (WWWW, usually 3 to 4 numerics), and height (HHHH, usually 3 to 4 numerics).

This meant when a plugin such as the many many page builders and other custom content builders added an image to their content and did not use the standard functions to do so that generate an `img` tag with `wp-image-NNN` class name that could be used to find the attachment ID, you could at least parse the URL's path element, strip off the consistently formatted size information, and then find the attachment ID via its base path/filename.

This is no longer possible as the base file name for scaled or rotated images that corresponds to the sizes is now within the `original_image` meta field within the `_wp_attachment_metadata` value.

To find the attachment ID for a local image URL you could previously do a relatively fast SQL select based on the `meta_key = '_wp_attached_file'` and `meta_value = '2019/10/image.jpg'` for the above example.

Now you're going to have to concoct some UNION on the possible alternate file names, with some fudging for alternate thresholds, or a very expensive `LIKE` select on the `meta_value` of the `_wp_attachment_metadata`, or somehow capture the relationship between the `_wp_attached_file` value and the `original_image` in custom data (custom tables no doubt) so that there's some sort of fast lookup.

Proposal:

1) Instead of suffixing the base file name for images with either `-scaled-NNNN` or `-rotated`, leave it as per the ""normal"" sanitized version, but move the original file to a suffixed name such as `image-original-version.jpg` and store that in `original_image`. For clarity, it could be something like `image-original-pre-scaling-2560.jpg` or `image-original-pre-rotation.jpg`.

or

2) Ensure that the sub-sizes are generated with a matching file name. So if the ""full"" size is now ""image-scaled-2560.jpg"", there would be ""image-scaled-2560-150x150.jpg"" and ""image-scaled-2560-300x200.jpg"" etc.

As an aside, while testing I have noticed a couple of further problems related to the renaming of the base file...

1) When a large file is edited with the standard editor, the base file and sizes now have a unified `image-scaled-2560-e123456789012` base, which is good. Except the `twentytwenty-fullscreen` size retained the original `image-1980x990.jpg` filename.

2) The change in filename during upload causes problems with the `wp_unique_filename` being handled consistently by plugins."	defect (bug)	closed	normal	5.3	Media	5.3	major	fixed	2nd-opinion has-patch dev-reviewed