Image editor crops specific image widths

[squirreling]

Images with width of exactly 400px are not fully displayed in the image editor. Only part of the image gets displayed, as if the image is being cropped.

Steps to reproduce:

1. Log in to wp-admin
2. Go to "Media" tab and click "Add new"
3. Upload image with width of 400px
4. Click "edit"
5. Click "edit image" button to open the image editor

The full image should be displayed in the editor window, but the image appears cropped so that the top and the bottom edges are not viewable.

Wordpress 3.2.1/ PHP 5.2.17 / twentyeleven theme / no plugins enabled

​http://wordpress.stackexchange.com/questions/11651/why-cant-i-edit-certain-images-from-the-wordpress-media-library/29666#29666

This may be the same issue as bug #17162

[squirreling]

test image that fails with width of 400px

[squirreling]

screenshot of image editor not displaying entire image

[squirreling]

width of 399px is ok

[squirreling]

width of 401px is ok

[squirreling]

screenshot of image editor correctly working

[solarissmoke]

The problem is in image_get_intermediate_size(), this line in particular:

if ( ( $data['width'] == $size[0] && $data['height'] <= $size[1] ) || ( $data['height'] == $size[1] && $data['width'] <= $size[0] ) ) {

The original image (400x380) has an automatically generated post-thumbnail that has dimensions 400x288, and that is what is delivered to the image editor instead of the full image. This happens because the image editor specifically uses 400x400 as the maximum dimensions for the image to edit. Hence if you supply an image with either 400px width or height you have this problem.

The same thing is happening in #17162 with header images - closing it as a duplicate as the explanation here is easier to understand.

[solarissmoke]

Check original image first before attempting to find a smaller one

[solarissmoke]

I reckon the problem is that image_get_intermediate_size() doesn't check the original image before checking for other auto-generated sizes. This means that whenever the width/height of the original image exactly equals the width/height supplied to the function, you risk getting something other than the original itself. See patch​.

[squirreling]

It's worth mentioning that this bug also appears if the height is greater than 400px. Attached another test image which is 400 x 600 px.

[squirreling]

bug also occurs for heights greater than 400px

[squirreling]

another fail case

[squirreling]

another fail case for good measure (bug not limited to even heights)

[squirreling]

Also, this bug does not occur when the height is 400px; there are only problems when the width is 400px.

[squirreling]

no bug for 400px height

[squirreling]

no bug for 400px height (600px width)

[SergeyBiryukov]

Related: #17626

[nothin7]

This issue also occurs if functions.php contains the following:

add_image_size( 'any_name', any_number, 400, true );

In other words, it occurs if your theme adds an image size with a height of 400 pixels and hard crop mode enabled. But the following are okay:

add_image_size( 'any_name', any_number, 400 );

add_image_size( 'any_name', 400, any_number_except_400, true );

[bpetty]

FWIW, I tested a whole bunch of the fail case images attached here with and without this line in Twenty Twelve functions.php:

add_image_size( 'any_name', 550, 400, true );

In all cases, it didn't crop any of them on any side at all. It also didn't scale down anything smaller than or exactly equal to 400x400px. In all cases, aspect ratio was respected for images bigger than 400px in either direction (which were all scaled for the image editor).

Not that I suspected this was the cause, but just covering bases, I also tested with both WP_Image_Editor implementations (GD and IM), and still couldn't reproduce.

[bpetty]

I was able to reproduce this bug in 3.4, and I have confirmed that r22094 (#6821) fixed this, and not just because this was the introduction of using IM by default since I can switch back to GD, and this is still fixed there too.