[wp-trac] [WordPress Trac] #48453: Regression: Implied contract between image sub-size filenames and their base filename now broken

[WordPress Trac]

#48453: Regression: Implied contract between image sub-size filenames and their
base filename now broken
--------------------------+-----------------------------
 Reporter:  ianmjones     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Media         |    Version:  trunk
 Severity:  major         |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48453>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform