image_resize() treats all resized images resulting in JPEG as having the .jpg extension

[kawauso]

Steps to reproduce:

1. Upload foobar.jpg
2. Upload foobar.jpeg
3. WordPress will use foobar-200x200.jpg and such for the intermediate sizes of the second image

wp_handle_upload() uses image_resize() which attempts to convert all images except GIFs/PNGs to JPEG and hardcodes the .jpg extension. This may well affect all image types handled by GD aside from GIF/PNG when WordPress is given the correct settings to handle them.

The real issue for me is that if the resize procedure fails, it does so silently and just passes back the URL for an existing file matching the output filename.

[solarissmoke]

Related/duplicate #7491

[nacin]

Moving version to 3.0 as this would not be a regression.

[kurtpayne]

This patch using an incrementing counter to make the thumbnail filenames unique.

[leogermani]

Hi,

I have just stumbled on this problem now... really annoying

Any feedback on this patch or suggestion on how to approach this problem?

Leo

[SergeyBiryukov]

Perhaps wp_unique_filename() can be used here?

[kawauso]

Replying to SergeyBiryukov:

Perhaps wp_unique_filename() can be used here?

Just looked into that. There's a hitch in that it adds to the end of the filename, after the size prefix, so you end up with foobar-200x2002.jpg for a 200x200 resize which can be rather misleading.

[kurtpayne]

Test case: Upload "uploaded_image.jpg" and "uploaded_image.jpeg"

Default behavior results in:

wp-content/uploads/2012/02/uploaded_image-150x150.jpg
wp-content/uploads/2012/02/uploaded_image.jpeg
wp-content/uploads/2012/02/uploaded_image.jpg

The resized image names ("....-WIDTHxHEIGHT.jpg") stomp on each other.

With 16458.diff​, results are:

wp-content/uploads/2012/02/uploaded_image-150x150.jpg
wp-content/uploads/2012/02/uploaded_image.jpeg
wp-content/uploads/2012/02/uploaded_image.jpg
wp-content/uploads/2012/02/uploaded_image1-150x150.jpg

The resized image name only gets a counter inserted if the file already exists.

[SergeyBiryukov]

Having some issues with 16458.diff​ on 3.4-alpha-19998, Twenty Eleven, default media settings.

1. Uploading Untitled.jpg (1000x1000) results in 6 files:

   Untitled.jpg
   Untitled-1000x288.jpg
   Untitled-150x150.jpg
   Untitled-300x300.jpg
   Untitled1-1000x288.jpg
   Untitled1-300x300.jpg
   

Two of them are the same, so there should be only four. Apparently image_resize() can be called multiple times with the same parameters.

2. Uploading Untitled.jpeg then results in 4 files:

   Untitled.jpeg
   Untitled-1000x288.jpg
   Untitled-150x150.jpg
   Untitled-300x300.jpg
   

Three of them overwrite the intermediate sizes of the previous image. This creates orphaned DB records when either image is deleted.

Without the patch, issue 2 still happens, but issue 1 doesn't.

We can probably just preserve .jpeg extension (16458.2.diff​).

[nacin]

Fine with 16458.2.diff​. Note that if ( 'jpeg' != $ext && 'jpg' != $ext ) $ext = 'jpg'; is going to be quicker than in_array().

Unit tests would be nice.

[ryan]

Should $orig_type be used here instead of relying solely on the extension?

[ryan]

Replying to ryan:

Should $orig_type be used here instead of relying solely on the extension?

I guess not.

[ryan]

Alternative suggested by nacin

[nacin]

In [20701]:

In image_resize(), do not force the destination filename to *.jpg when we are dealing with a *.jpeg.

props SergeyBiryukov.
fixes #16458.