Make WordPress Core

Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

#48209 closed defect (bug) (worksforme)

Original file name changes on images upload and extra unregistered image sizes generated

Reported by: Iulia Cazan Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.3
Component: Media Keywords:
Focuses: Cc:
PR Number:



I installed and tested the functionality provided with version 5.3-beta2 and there is an issue with images uploads. Basically, when uploading an image, the filename that is recorded in the attachment metadata for the original file is using a suffix that indicates the original image width, and the file is created as well.

For example, I uploaded the image called image.jpeg (with 5472×3648px) and the result looks like this:
I end up with the following images in the folder:

image-1024x683.jpeg - matches the large size - OK
image-1200x800.jpeg - matches the post-thumbnail size - OK
image-150x150.jpeg - matches the thumbnail size - OK
image-1536x1024.jpeg - 1536x1536 - as far as I know, this should not be generated, there is no image size registered programmatically for this
image-1980x1320.jpeg - matches the twentytwenty-fullscreen - OK
image-2048x1365.jpeg - 2048x2048 - as far as I know, this should not be generated, there is no image size registered programmatically for this
image-2560.jpeg - this is mapped as the original file, but this should be image.jpeg
image-300x200.jpeg - matches the medium size - OK
image.jpeg - this is the original file but is mapped separately

And in the database the metadata contains these:


My original test image.jpeg has 5472×3648 and the image that is now linked as the "original" image-2560.jpeg has been scaled and is not the original image. Basically, there is no real information about the actual file that was uploaded (the width and height are not mapped in the database at all). I confirm that my tests are done on a clean WordPress instance, with no custom settings and with the Twenty Twenty theme activated.

If this is not a bug, but the intended new functionality, then this is quite a change and needs some documentation.

As far as I understand, we will end up with a lot of hidden images (that will only pile up without ever being used), since most of the functionalities related to media are handling media attributes bases on the image sizes registered programmatically and readable/known image sizes names. Also, it's going to decrease the performance on upload, since there are extra image sizes that will be generated/handled per each file.


Change History (6)

#1 @sotiris_k
2 months ago

I have reproduced this bug successfully. It does tend to happen with high resolution images.

#2 @desrosj
2 months ago

  • Keywords needs-testing 2nd-opinion added
  • Milestone changed from Awaiting Review to 5.3
  • Version set to trunk

Related #40439.

Thanks, @iulia-cazan! Welcome to Trac!

This is related to some changes coming to the image upload process in 5.3. I’m moving to the milestone for visibility, but this may be the new intended behavior.

The meta value you attached looks like the one that keeps track of all subsizes generated for an image. Can you see if there is an additional meta field that contains the original image file name?

#3 @Iulia Cazan
2 months ago

I understand.

However, @desrosj, do you have an explanation for the image sizes that are generated outside of the registered image sizes? That is a red flag for me, regardless of the intended new functionality.

#4 @desrosj
2 months ago

  • Keywords needs-testing 2nd-opinion removed
  • Milestone 5.3 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

The 2048x2048 and 1536x1536 are new sizes introduced in [46066] in an effort to enhance the way WordPress displays images on the front-end on larger, high-density devices. They make it possible to generate more suitable srcset and sizes attributes, and not use the original, often non-optimized image.

These new sizes will be generated for all newly uploaded images going forward.

I am seeing the original image in the meta data that you supplied in the original_image index, so it seems to be working as intended.

  • The original image is larger than the new big image threshold used to cap images at an upper size limit.
  • The original is scaled down to be more useful using the two new image sizes.
  • The original is preserved in the attachment's meta data.

If you wish to disable this big image threshold (or tweak it to your liking), you can use the big_image_size_threshold filter to return a new size. Returning false will disable this.

I'm goign to close this out because it appears to be working as intended. If I am misinterpreting the questions, or you have more, feel free to reopen to discuss more.

#5 @Iulia Cazan
2 months ago

OK. Thank you!

#6 @desrosj
2 months ago

Also, I forgot to add! @iulia-cazan keep an eye out on https://make.wordpress.org/core for a developer note detailing all of the changes that were made here! A few small things were being tested and maybe tweaked, so that's why it's a bit delayed being published. Please do follow up there if you have any further questions!

Note: See TracTickets for help on using tickets.