Make WordPress Core

Opened 16 years ago

Closed 11 years ago

Last modified 11 years ago

#8754 closed defect (bug) (duplicate)

Uploading images whose dimensions are greater than the maximum size allowed fail to generate thumbnails and no error/failure message is displayed.

Reported by: drgdc's profile DRGDC Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Upload Keywords:
Focuses: Cc:


The process of uploading images that have dimensions (physical size) greater than the maximum size allowed by the global setting will fail part way through the process without an error or failure message being displayed.

Example: Uploading a JPEG image with a width of 625 pixels and height of 938 pixels. This physical size is greater than the maximum size allowed by the default WordPress configuration.

When uploading such an image using the "Add an Image" panel the the Flash uploader will stop with the upload progress bar at 100% and displaying "Crunching…". The Browser uploader will return a blank "Add an Image" panel display.

In both cases the images are uploaded to the appropriate directory on the server and appear when the post's media gallery is refreshed. Thumbnail images are not generated for these uploads. It appears the failure is before or during thumbnail generation.

Note: The maximum image dimension allowed for upload is not the same as the Administration > Setting > Media > Large Size: Max Width and Max Height settings. In my case these settings are both set at 1024 pixels (above the size of the image I am working with). It appears this control panel setting only impacts the HTML image tag attributes for posts, so as not to break the visual design with images that are wider than a layout allows.

Now you may ask what is the default maximum dimension for uploaded images. Unfortunately I cannot find my notes on where exactly the setting is in the WordPress code (it has no Web GUI access that I am aware of). I had changed this setting once to work around this problem and hoped 2.7 would have fixed the issue. It is a pain to track down as the location of this setting has changed over time as it moved to different files and functions with each new version of WordPress.

My understanding is that this maximum image dimension setting was set to prevent images over 3 megapixels from being uploaded since those are really big and readers shouldn't have to deal with such images. This is old thinking from before broadband and photo blogs took off.


I think the default limit should be raised, but that would be a feature request. This ticket is to have error messages displayed.

Change History (17)

#1 @DD32
16 years ago

  • Component changed from Administration to Upload
  • Milestone set to 2.9
  • Owner anonymous deleted

WordPress has no inbuilt limit to the resolution of the images which you can upload..

However, PHP's Image functions may fail to handle the image, esp. if the memory limit is too low for it to handle the image (WP tries to increase it to 120MB).

Theres another ticket which deals with errors during thumbnail creation not being passed through to the UI.. cant find it right now though.

Testing it, I just uploaded 2 images, 4674 x 2564 px, and 5170 x 2627, Both worked fine for me. I'd say the issue outlined in that blog post is long gone..

#2 @DD32
16 years ago

Hm.. Ok.. So i created a 120megapixel image.

indeed, It dies as you suggest, crunching just stops, thumbnails never created.

but the actual cause... is weird.. imagecreatefromstring() the PHP function gets called to load the image, But it just.. doesn't work for large files (In this case, 14MB, and 15510x8000px). While the docs say it will return false upon error, The function never returns, PHP just stops in its tracks, and nothing more gets run.. Which makes it a bit hard to catch the error condition of the thumbnails not being created..

(Btw, I'm talking about the code inside wp_load_image() at present)

#3 @DD32
16 years ago

Ah.. Turns out i didnt increase the memory limit far enough, Once i increased it to 1GB memory limit (Instead of 512M which i had tried (And WP sets it by default to 256MB)) its managed to create thumbnails, and works completely as expected.

15 years ago

I've edited wp_load_image() located in /htdocs/wp-admin/includes/image.php to use 1024M and the thumbnail generation is still failing. The test image I am uploading is 1,047 KB and 625 x 938 pixels.

@ini_set('memory_limit', '1024M');

I am running WordPress Version 2.7 and below are my server stats:

OS  			Linux
Server 			Apache/2.2.3 (Red Hat)
PHP 			v5.1.6
MYSQL 			v5.0.45
GD 			bundled (2.0.28 compatible)
Server Hostname
Server IP:Port 		x.x.x.x:80
Server Document Root 	/vservers/xxxxxx/htdocs 
Server Admin	
Server Load 		N/A
Server Date/Time 	February 3, 2009 @ 10:47 am

Database Data Disk Usage  	2.3 MiB
Database Index Disk Usage 	301 KiB
MYSQL Maximum Packet Size 	1024 KiB
MYSQL Maximum No. Connection 	100
PHP Short Tag 			On
PHP Safe Mode 			On
PHP Magic Quotes GPC 		Off
PHP Memory Limit 		16M
PHP Max Upload Size 		2M
PHP Max Post Size 		8M
PHP Max Script Execute Time 	30s

15 years ago

Correction to the above, the test image I was using was actually bad.

I changed the memory limit to "1GB" instead of "1024M" and tried uploading a 322K JPG image with dimensions of 625x938 and the thumbnail generation fails.

I may have another problem...

15 years ago

I am providing updated information as this bug is frustrating for me. All I want is a 200x200 thumbnail automatically generated for the first image in my post (either first uploaded or set to order position 1).

Thumbnail generation is silently failing. Without errors it is next to impossible to debug. I am attaching an image that fails with the following configuration:

WordPress 2.8.3


  • OS: Linux
  • Server: Apache/2.2.3 (Red Hat)
  • Hostname:
  • IP:Port:
  • Document Root: /xxxxx/xxxxx/htdocs


  • v5.1.6
  • GD: bundled (2.0.28 compatible)
  • Magic Quotes GPC: Off
  • Memory Limit: 16.0 MiB
  • Max Upload Size: 30.0 MiB


  • v5.0.45
  • Maximum No. Connections: 100
  • Maximum Packet Size: 1,024.0 KiB
  • Data Disk Usage: 3.2 MiB
  • Index Disk Usage: 449.0 KiB

I've tried editing /wp-admin/includes/image.php:

function wp_shrink_dimensions( $width, $height, $wmax = 900, $hmax = 900 ) {

return wp_constrain_dimensions( $width, $height, $wmax, $hmax );


with the above setting the file upload progress bar hits 100% and then disappears, but the image doesn't upload.

With the following the file upload progress bar hits 100% and then disappears, the file is uploaded but no thumbnail is generated:

function wp_shrink_dimensions( $width, $height, $wmax = 200, $hmax = 200 ) {

return wp_constrain_dimensions( $width, $height, $wmax, $hmax );


15 years ago

Sorry, the file size of the image is over the limit, see

#9 @azaozz
15 years ago

  • Milestone changed from 2.9 to Future Release

WordPress tries to set the memory limit to 256MB when working with images however some hosts prohibit that. Also the image dimensions are not a direct indication of the image size. We could try to detect when that happens and show appropriate error message.

#11 @drgdc
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#12 @ocean90
13 years ago

  • Keywords needs-patch added; image photo thumbnail dimension size limit upload removed

#13 @iseulde
11 years ago

  • Keywords needs-patch removed
  • Resolution set to invalid
  • Status changed from reopened to closed

Media has been redone in 3.5.

#14 @helen
11 years ago

  • Milestone Future Release deleted
  • Resolution changed from invalid to duplicate

Marking as dupe of #23127, even though it's newer.

#15 @markoheijnen
11 years ago

Please don't close this kind of tickets because media has been redone. It's still can happen.

#16 @helen
11 years ago

You can reverse it and reopen this one and close the newer one as a dupe - doesn't bother me. I know generally speaking the oldest is supposed to stay open/be canonical. I bet there are more, too.

#17 @markoheijnen
11 years ago

It's nothing to do with the ticket in general. Closing ticket because something has changed first needs validation that it did solve the ticket. This wasn't the case for this ticket.

Note: See TracTickets for help on using tickets.