WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 2 years ago

#31296 closed defect (bug) (fixed)

Uploaded images are saved as a "resized" duplicate, if the size matches $_wp_additional_image_sizes

Reported by: wpdennis Owned by: wonderboymusic
Milestone: 4.2 Priority: normal
Severity: major Version: 4.1
Component: Media Keywords: has-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

If an image is uploaded with the exact same width and height, as via add_image_size() specified, it results in two files with same dimensions in upload dir. One being the original filename and the other is the "resized" one with a size appendix to its filename.

Prior to 4.1 there was only the image with the original filename. The behaviour with 4.1 is bad, because we have a) more images than necessary and b) WordPress uses the version with size appendix. If you're optimizing images before uploading them, the optimizations aren't used at all.

It seems like the change came in with this changeset: r30639

Corresponding ticket: #19793

Change History (7)

#1 @SergeyBiryukov
4 years ago

  • Description modified (diff)

#2 @rowd1951
4 years ago

  • Severity changed from normal to major

I have also noticed this bug, but did not have the skill that @wpdennis did to work out what the cause was!

So, after seeing wpdennis' ticket, I went into a test website and edited those lines of the media.php file in the Wordpress core to how they were in version 4.0 and, sure enough, the problem went away.

Basically, if your blog has featured images of the dimensions 600x200 pixels, for example, and you created an image called blogpostimage.jpg for your latest article which is exactly the required 600x200 pixels, before this change was introduced in v4.1 (i.e. 4.0 and previous) then when uploading blogpostimage.jpg, that file would be used as the image, wherever that size was required, and no duplicate of the same size was ever created.

Now what happens is an IDENTICAL version of blogpostimage.jpg is created called blogpostimage-600x200.jpg AS WELL as the original blogpostimage.jpg, which is bad enough because it's a redundant image taking up unnecessary space, but what makes this bug worse is that it is THIS file e.g. blogpostimage-600x200.jpg which is being used as the featured image/thumbnail, and it's not nice.

Please can this be sorted? The last thing on earth I thought I'd do is to have to edit a WP core file, it's a cardinal sin, but unless this bug is changed, I'm afraid I think I'll have to, and that's not good form -it makes me feel dirty!

The original code in the media.php file worked fine, can't it be reverted, or fixed? Also, there has been an update to 4.1 already, I only noticed this error recently after 4.1.1 or I would have flagged it up earlier.

I'd like to thank wpdennis.

#3 @wonderboymusic
4 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.2

#4 @wonderboymusic
4 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from new to closed

In 31576:

In the ->multi_resize() method of the WP_Image_Editor subclasses, when looping through potential crops, we need to make sure the crop isn't the exact same dimensions as the original image before copying it as a new crop.

This ensures that we don't save multiple copies of the same image.

Supposedly broke in [30639], but this logic was always missing. When I tested reverting [30639], there were still 2 files being created.

Fixes #31296.

#5 @rowd1951
4 years ago

Thanks Wonderboymusic - I note in your comments on the fix/patch [31576 ] after explaining the technical nature of this bug, you state that this: "Supposedly broke in 30639, but this logic was always missing..." - however I can clarify this for you:

If you had IMAGICK enabled on your server then this, indeed, was a problem that would have been experienced prior to the introduction of WP v4.1.

It only arose as a problem with GD post 4.1.

I.E. If IMAGICK wasn't enabled then you would not have experienced this duplication error with GD until version 4.1 was released, which brought in this offending change: 30639

Thanks for your help - do you know when v4.2 will be released with this repaired?

#6 @wpdennis
4 years ago

@wonderboymusic: Thanks for your patch, but I'm afraid it hasn't caught every case. I opened a new ticket as a follow-up: #32437, since the comment form told me to. :-)

This ticket was mentioned in Slack in #core-media by desrosj. View the logs.


2 years ago

Note: See TracTickets for help on using tickets.