[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:  5.3
Component:  Media                    |     Version:  trunk
 Severity:  major                    |  Resolution:
 Keywords:  needs-patch 2nd-opinion  |     Focuses:
-------------------------------------+---------------------

Comment (by ianmjones):

 Replying to [comment:1 azaozz]:
 > Been wondering if there should be a better
 `image_url_to_attachment_id()` function in core to help with these cases.

 That would be awesome! 👍

 > At first look at the proposed solutions thinking that moving/renaming of
 the originally uploaded file is the better one.

 That's my instinct too.

 I expect end users would be less surprised by the filename they see
 everywhere being the sanitized version of what they uploaded, just as it
 is in WP5.2.

 We also see a lot of feedback in our support related to the importance of
 image file names being as uploaded, people get a bit twitchy if their
 carefully crafted SEO friendly file names get changed. So tacking on
 `-scaled-2560` or `-rotated` might be unwelcome.

 Seeing as the `original_image` isn't expected to be used much, if at all,
 then I don't see much downside to that file being renamed rather than the
 base file used across WP.

 If you know the attachment ID you can therefore easily get the
 `_wp_attachment_metadata` and check whether there is an `original_image`
 to optionally process.

 And because `_wp_attached_file` has the relative path to `uploads` that
 gives the location of the plain file names in `sizes` and
 `original_image`, it's easy to locate them with `dirname`.

 > The argument against was that renaming the original image may introduce
 another (very small) possibility of errors while post-processing images,
 while saving another image is proven to work properly at that time.

 I guess this is the only real concern with renaming the original rather
 than full/scaled image.

 > Also thinking that appending only `-original` or perhaps `-wp-original`
 to the file name should be sufficient. There are cases where it can reach
 length limits.

 This concern with file name length possibly hitting a limit raises another
 good reason for renaming the original and not the scaled image.

 If a large `image.jpg` is uploaded with the current RC2 method, and that
 image is not only renamed for uniqueness but then edited, we could have
 something like the following...

 `full`: `image-1-scaled-2560-e1572283267932.jpg`
 `large`: `image-1-scaled-2560-e1572283267932-1024x768.jpg`
 `original_image`: `image-1.jpg`

 For that `large` version, we're looking at an extra 38 characters at
 least.

 However, if instead the original gets renamed we have...

 `full`: `image-1-e1572283267932.jpg`
 `large`: `image-1-e1572283267932-1024x768.jpg`
 `original_image`: `image-1-wp-original.jpg`

 That means `large` is 12 characters less in length, and `original_image`
 has still gained far less characters than `large` gained for the edit and
 size suffixes and so must be within bounds.

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