WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 18 months ago

Last modified 18 months ago

#18799 closed defect (bug) (fixed)

Image editor crops specific image widths

Reported by: squirreling Owned by:
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.2.1
Component: Media Keywords:
Focuses: Cc:

Description

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

Attachments (11)

img400x380.jpg (23.3 KB) - added by squirreling 3 years ago.
test image that fails with width of 400px
screenshot.png (149.3 KB) - added by squirreling 3 years ago.
screenshot of image editor not displaying entire image
img399x380.jpg (23.8 KB) - added by squirreling 3 years ago.
width of 399px is ok
img401x380.jpg (22.9 KB) - added by squirreling 3 years ago.
width of 401px is ok
screenshot_ok.png (151.8 KB) - added by squirreling 3 years ago.
screenshot of image editor correctly working
18799.diff (900 bytes) - added by solarissmoke 3 years ago.
Check original image first before attempting to find a smaller one
img400x600.jpg (46.3 KB) - added by squirreling 3 years ago.
bug also occurs for heights greater than 400px
img400x800.jpg (44.9 KB) - added by squirreling 3 years ago.
another fail case
img400x799.jpg (44.8 KB) - added by squirreling 3 years ago.
another fail case for good measure (bug not limited to even heights)
img380x400.jpg (38.8 KB) - added by squirreling 3 years ago.
no bug for 400px height
img600x400.jpg (37.9 KB) - added by squirreling 3 years ago.
no bug for 400px height (600px width)

Download all attachments as: .zip

Change History (21)

squirreling3 years ago

test image that fails with width of 400px

squirreling3 years ago

screenshot of image editor not displaying entire image

squirreling3 years ago

width of 399px is ok

squirreling3 years ago

width of 401px is ok

squirreling3 years ago

screenshot of image editor correctly working

comment:1 solarissmoke3 years ago

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.

solarissmoke3 years ago

Check original image first before attempting to find a smaller one

comment:2 solarissmoke3 years ago

  • Keywords has-patch needs-testing added

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.

comment:3 squirreling3 years ago

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.

squirreling3 years ago

bug also occurs for heights greater than 400px

squirreling3 years ago

another fail case

squirreling3 years ago

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

comment:4 squirreling3 years ago

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

squirreling3 years ago

no bug for 400px height

squirreling3 years ago

no bug for 400px height (600px width)

comment:6 nothin720 months ago

  • Cc nothin7 added

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 );

comment:7 nacin20 months ago

  • Milestone changed from Awaiting Review to 3.5

comment:8 bpetty18 months ago

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.

comment:9 bpetty18 months ago

  • Keywords has-patch needs-testing removed
  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:10 bpetty18 months ago

  • Cc bpetty added
Note: See TracTickets for help on using tickets.