Make WordPress Core

Opened 8 years ago

Closed 2 months ago

#36534 closed defect (bug) (worksforme)

Media Upload Issue Since 4.5 Upgrade

Reported by: unicornbacon's profile unicornbacon Owned by: joemcgill's profile joemcgill
Milestone: Priority: normal
Severity: critical Version:
Component: Media Keywords: needs-testing needs-patch close
Focuses: Cc:

Description

Here is my problem: Since I updated to 4.5 yesterday, I can't upload certain image files. Every time I try, I get an error stating:

Fatal error: Maximum execution time of 30 seconds exceeded in /home2/scarlett/public_html/germany/wp-includes/class-wp-image-editor-imagick.php on line 358

I finally figured out that the problem is with the photograph's dimensions. All of the photos that won't upload were rotated from landscape to portrait on import. Their dimensions are 3000x4000 rather than 4000x3000 like the photos that I can still upload. After trying to save the photos without their metadata, turning off all plugins, and various other edits and experiments, it turns out that for some reason I only get the "imagick"" error on the photos that have a dimension of 3000x4000. Changing it to 2250x3000 (or anything less than 4000 for the height) allows me to upload them. I had no problem uploading files with this designation before I updated to 4.5. Everything else about the files is identical, and the file sizes do not conform to any kind of pattern and are not particularly large or small. As test, I tried to re-upload a photo that had this exact same ratio that I had uploaded successfully yesterday, and it would not upload today. This leads me to believe that there is something going on WP's end, since nothing has changed on the server side in the last 24 hours (and sadly my auto-backup was turned off somehow so now I am stuck with this).

Attachments (3)

36534.diff (859 bytes) - added by joemcgill 8 years ago.
36534.2.diff (1.2 KB) - added by joemcgill 8 years ago.
Use FILTER_BOX during resizing
Image_that_breaks _WordPress_upload.jpg (118.8 KB) - added by lukecavanagh 7 years ago.
Test Image - 3600 × 1800 pixels

Download all attachments as: .zip

Change History (136)

#1 @adamsilverstein
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Hi @unicornbacon thanks for the bug report (and awesome handle!)

The error Maximum execution time of 30 seconds exceeded tells us that your web server has run out of time trying to process the images you are uploading. Increasing the max execution time should solve your issue.

As you may know, every time you upload an image to WordPress, the server resizes the upload into several sizes for use on the front end of the site. By default there are thumbnail (small), medium and large sizes and themes and plugins can add additional sizes.

In WordPress 4.4 and 4.5 we have been changing and improving image handling with several goals including faster/small images for faster loads/less space on small image sizes, and new large sizes to provide responsive image sizes (images that display well on hi def monitors, ie 'retina'). These additional sizes and better compression mean more work on the server side when uploading.

This is all my long way of saying image processing load has increased when uploading images in 4.5 - we are trying to do more with each image that is uploaded. The error you see you see is on a line of code calling unsharpMaskImage which sharpens up resized images. I don't think this is a core bug: your images are very large and are exceeding the capacity of WP 4.5 to handle them on your server.

#2 @smashingjay
8 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

@adamsilverstein with all due respect I believe this to be a bug. I was notified of this exact issue from a user of our hosting service. I was able to replicate the http error on the site no matter how small or large the image. At first I assumed as you did, they were trying to upload large images but then noted that the error occurred instantly (not after 30 seconds) as I tailed the error.log in another window. In my tests, everything from a 14KB postage stamp size jpg to a 1MB file causes 4.5 to throw this error instantly, not after a 30 second server timeout.

This same issue was reported in the forums: https://wordpress.org/support/topic/http-errors-on-media-uploads-after-45-update and appears to be related to calling or how Imagick is called/used since 4.5.

Environment I was testing on was PHP 5.6.20, Imagick 6.7.2-7 2015-02-27 (Module 3.4.1), WP 4.5.

#3 @adamsilverstein
8 years ago

@smashingjay thanks for re-opening and apologies for closing if the issue isn't what I described.

In the original bug report, @unicornbacon described an error message of Fatal error: Maximum execution time of 30 seconds exceeded - what error are you seeing in your log files?

I will try to replicate the issue locally by matching your stated config as best I can; did you try the fixes mentioned on the support ticket and did they resolve the issue for you?

#4 @smashingjay
8 years ago

Hi @adamsilverstein I was seeing the exact error message (the line number in the file is still within the Imagick section of the file):

[19-Apr-2016 19:18:41 UTC] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /www/wp-includes/class-wp-image-editor-imagick.php on line 338

And inside the WP media manager it shows HTTP Error "filename.jpg" where the filename is the name of the file attempted to be uploaded.

I'll confer with our hosting customer about this. I do not want to alter the functions.php file on a live site without permission. I'll ask him if the fix corrected his issue and post back.

Jay

Last edited 8 years ago by smashingjay (previous) (diff)

#5 follow-up: @unicornbacon
8 years ago

I can't even upload photos from my smartphone that are in portrait mode. I tried scaling down my cameras settings as far as they will go and I still couldn't upload things that were in portrait mode. I tried Using photo editing software to scale down my photos as far as 35% and that STILL didn't work. My files are now under 600kb in size and well below 1500x1500 in dimensions and if I am lucky they MIGHT upload 1 out of every 4, even though I can't find anything different about the files. I can't change my php.ini or htaccess files because my webhost doesn't allow those changes. Again, this was NEVER a problem before this upgrade. Not once in the 8 years I have had my website and been using Wordpress on this webhost. The only other solution is to try and manually reinstall a previous release of Wordpress, but 1. That's a pain for a non-coder like myself and 2. That will only last so long before I will be forced to upgrade and will still have broken work. This isn't just a vanity blog, I am a student doing once-in-a-lifetime field work overseas, and much of my work hinges on my ability to share my photographs with my faculty back home. If I can't do this effectively, I am screwed.

#6 in reply to: ↑ 5 ; follow-up: @smashingjay
8 years ago

@unicornbacon you may wish to try the fix here: https://wordpress.org/support/topic/http-errors-on-media-uploads-after-45-update?replies=24#post-8300481 which should be relatively easy and would also prove out the issue further, that it relates to Imagick.

#7 in reply to: ↑ 6 ; follow-up: @unicornbacon
8 years ago

Replying to smashingjay:

@unicornbacon you may wish to try the fix here: https://wordpress.org/support/topic/http-errors-on-media-uploads-after-45-update?replies=24#post-8300481 which should be relatively easy and would also prove out the issue further, that it relates to Imagick.

Oh! THANK YOU!! That worked! I added that code to the functions.php page, and so far, I have been able to upload everything that has been failing since the 4.5 update! Thank you kind stranger! You have snatched my dreams from the jaws of oblivion!

#8 @crscrk
8 years ago

Wordpress upgrade broke my http upload as well. No explanation except http error - just doesn't work. I have UpdraftPlus plugin for backup and I rolled back to previous version of Wordpress and all works as before. My files are simple jpegs and not that big. Will not upgrade Wordpress again until this is fixed! This is a bug, no question about it. Even if it weren't a bug, shouldn't trash everyone's work that was functional before!!!!

#9 @joemcgill
8 years ago

  • Owner set to joemcgill
  • Status changed from reopened to reviewing

@joemcgill
8 years ago

#10 @joemcgill
8 years ago

  • Keywords has-patch added
  • Milestone set to 4.6
  • Status changed from reviewing to accepted

After spending some time digging into this issue, I believe this very well may be related to a longstanding ImageMagick issue when multiple threads are available using OpenMP (see: https://github.com/mkoppanen/imagick#openmp). The patch in 36534.diff fixes this by forcing Imagick to use a single thread.

I will also add that the OpenMP issue has been an problem since before 4.5, but version 4.5 magnifies the problem by using extra memory during processing.

Can any of you experiencing this issue please try applying the patch and see if this resolves the issue for you?

#11 @NealGhoshal
8 years ago

  • Severity changed from normal to major

This is a problem for me on all my websites since updating to 4.5

The one thing that has worked was adding this

SetEnv MAGICK_THREAD_LIMIT 1

to the top of my htaccess file

Please Wordpress fix this properly with an update. Thanks.

#12 @joemcgill
8 years ago

  • Severity changed from major to normal

Even though limiting Imagick inside WordPress to only one thread will fix this issue for people affected by the OpenMP issue, this really is a configuration issue with the hosting provider that should be addressed. There are most likely valid setups where Imagick can be configured to use multiple threads, and it would be unfortunate to keep people from doing so.

I'm curious how many hosts are affected by this issue. If it's only a few, perhaps reaching out to have them fix ImageMagick on their end would be preferable.

In the mean time, people who are affected by this issue can add the line suggested by @NealGhoshal to their .htaccess file to achieve the same result.

SetEnv MAGICK_THREAD_LIMIT 1

#13 @smashingjay
8 years ago

@joemcgill

Considering the breadth of this issue, and the fact that (I suspect) most hosts have ImageMagick set up without disabling OpenMP, ideally, this could be detectable in some regard and use a fallback if it fails to function. Real world hosting for a majority of WP users is cheap shared cPanel/Plesk hosting, often with limited configuration or abilities to change server directives via .htaccess (never mind folks on nginx).

Last edited 8 years ago by smashingjay (previous) (diff)

This ticket was mentioned in Slack in #core by azaozz. View the logs.


8 years ago

#15 follow-up: @SergeyBiryukov
8 years ago

  • Milestone changed from 4.6 to 4.5.1

I've seen some similar topics on the forums after the 4.5 upgrade, moving for 4.5.1 consideration.

#16 @joemcgill
8 years ago

There are several reasons why larger images could cause these failures, but most likely are due to the server running out of memory during the multi-resize process (related: #22869).

The increased compression in 4.5 makes these failures somewhat more common, it would seem. 36534.diff fixes one possible reason for memory exhaustion when Imagick isn’t configured correctly, but the side effect is that people ​legitimately​ wanting to do multi-threaded image processing will no longer be able to (without some custom code).

Even if we do ship 36534.diff in a 4.5 minor release to provide some relief, we should reevaluate in 4.6 in the following ways:

  1. Improve the error message when these failures occur
  2. Find more ways to decrease memory usage during WP_Image_Editor_Imagick::multi_resize()
  3. Add better error handling when this does occur (which is unavoidable at some point) so that the whole process doesn't fail when some of the images are correctly available (which seems to happen in many cases).

#17 @smashingjay
8 years ago

In my tests I was also experiencing this with tiny images in the sub 100K size, in fact I tried with 14KB JPG and it throws an HTTP Error almost instantly not after exhausting CPU or available memory. I concede that the OpenMP being available on servers where it shouldn't be is a problem and I'd hate for folks to not be able to take legitimate advantage of multi-threading if available.

#18 in reply to: ↑ 15 @F J Kaiser
8 years ago

Replying to SergeyBiryukov:

[…] moving for 4.5.1 consideration.

Sorry, but imo this is a mustfix. WP takes a clear stance in the PHP version discussion because of hosters not upgrading. The clear consequence then is to fix this on the WP side. The amount of complaints in the w.org support forums states that this affects more than enough people.

#19 @adamsilverstein
8 years ago

@smashingjay - did the .htaccess change and/or patch fix the issue for you?

#20 @smashingjay
8 years ago

@adamsilverstein I'll have to check. My WP is on nginx server so I suspect only the patch will work. I'll come back with results soon.

This ticket was mentioned in Slack in #core by adamsilverstein. View the logs.


8 years ago

#22 @adamsilverstein
8 years ago

  • Milestone changed from 4.5.1 to 4.5.2

Unfortunately this fix isn't ready in time for 4.5.1, punting for consideration in 4.5.2.

#23 @smashingjay
8 years ago

@adamsilverstein the patch fixed it for me. My newer tests on the same environment before showed that I only got the http error and the following when using an image over 600KB:

[22-Apr-2016 01:05:35 UTC] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /wp-includes/class-wp-image-editor-imagick.php on line 358

My previous tests were erroring on any image large or small. Again the patch fixed the issue.

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


8 years ago

#25 follow-up: @aldon
8 years ago

also check the http error when uploading photos on media. some working fixes:

on functions.php on theme add this

add_filter( 'wp_image_editors', 'change_graphic_lib' );

function change_graphic_lib($array) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}


or add this line on .htaccess

SetEnv MAGICK_THREAD_LIMIT 1 

https://wordpress.org/support/topic/http-error-when-uploading-images-17?replies=18

https://wordpress.org/support/topic/http-errors-on-media-uploads-after-45-update?replies=40

Last edited 8 years ago by SergeyBiryukov (previous) (diff)

#26 @joemcgill
8 years ago

Hi @aldon,

Thanks for the feedback. The first fix you mention is actually just forcing WordPress to use GD instead of Imagick, which is a possible workaround, but doesn't fix the root issue.

The second suggestion is another way of implementing the same fix suggested in 36534.diff, which I would suggest trying first.

#27 in reply to: ↑ 25 @tmm63
8 years ago

Replying to aldon:

I added this the lines to my functions.php file and it worked. I would like to understand exactly what this is doing. :-) And a permanent fix would be desireable. Thank you @unicornbacon for reporting the issue!

also check the http error when uploading photos on media. some working fixes:

on functions.php on theme add this

add_filter( 'wp_image_editors', 'change_graphic_lib' );

function change_graphic_lib($array) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}


#28 @jiuzton
8 years ago

  • Keywords needs-patch added; has-patch removed
  • Severity changed from normal to major

I installed a fresh wordpress today, this is an issue. I tried a combination of every solution listed here (.htaccess/functions.php/.diff modification) as well as other techniques around. But I still have the issue. Mobile app won't upload either. peace.

This ticket was mentioned in Slack in #core-images by kaiser. View the logs.


8 years ago

#30 @guibernardi
8 years ago

Any news about this issue?

Yesterday I installed the WP 4.5 and I'm having trouble with this bug.
I don't want to edit the files listed on the solution listed above, so is there any comming update to fix it?

#31 @ManagerJosh
8 years ago

Out of curiosity - for those who are experiencing issues, how many of us are running PHP 7?

I was doing some debugging earlier and it *appears* that by using PHP 5.6 it resolves itself.

#32 @smashingjay
8 years ago

@ManagerJosh I seriously doubt that many are running PHP 7 unless on their local environments. Many shared/vps hosts are still <PHP 5.6—even though PHP 5.5. is EOL. I tested on PHP 5.6.20.

#33 @krhefley
8 years ago

I have tried both solutions mentioned above (editing the .htaccess file and the functions.php file) and neither solution appears to be working for me. I've tried the other requisite steps as well including different themes, deactivating all plugins and using super small photos.

For the record, I'm running php version 5.6.

Last edited 8 years ago by krhefley (previous) (diff)

#34 @jiuzton
8 years ago

Running PHP 5.6 - Fresh 4.5 Install - No plugins

.htaccess / functions.php *Does not fix the problem

#35 @rgoldoni
8 years ago

  • Resolution set to invalid
  • Status changed from accepted to closed

Really, this is a very big issue which Wordpress must solve as soon as possible.

It is not acceptable a lot of websites to be "frozen" because it is impossible to update with new images.

Is there any idea of when will be that solved?

Thanks

#36 @ocean90
8 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#37 @guibernardi
8 years ago

Well... I updated the PHP version and it works. I understand that is simple to update and solve this issue, but most of my friends just use the Wordpress for blogging or have their own business site and don't know how to update the PHP version, they don't even know what is PHP...

So I think this is a big issue and must solve as soon as possible.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-images by mike. View the logs.


8 years ago

#40 @Chaton666
8 years ago

Hi there,
same bug here.
WordPress MU 4.5.1

#41 @FrankEck
8 years ago

Hi... have had the same problem and two actions solve the problem:

1) downgrade to php 5.6 (from 7)
2) add the 3-liner to the functions.php

<?php
add_filter( 'wp_image_editors', 'change_graphic_lib' );

function change_graphic_lib($array) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}

Edit: Sorry, problem comes up with v4.5 and 4.5.1

Last edited 8 years ago by FrankEck (previous) (diff)

#42 @Chaton666
8 years ago

Hi @FrankEck !
Thanks, your second action save the problem for me.

Marie.

Edit: Nope, finally it works just for one image...

Last edited 8 years ago by Chaton666 (previous) (diff)

This ticket was mentioned in Slack in #core by ocean90. View the logs.


8 years ago

#44 @rogerstone26
8 years ago

I also had problems with image loading. I could load large files and small images (up to 1MB) but every time I tried to load an image >1MB, there was an "HTTP error" message.

Tried the suggestion set out above of setting the thread limit to 1 but it did not work (possibly I did not put the instruction in the right place).

Eventually solved, after talking to my hosting company, by adding a php5.ini file in my root directory:

memory_limit = 256M ; Maximum amount of memory a script may consume
max_execution_time = 300 ;

I am running WP 4.5.1, hosted by GoDaddy

This ticket was mentioned in Slack in #core-images by ocean90. View the logs.


8 years ago

#46 @joemcgill
8 years ago

#36764 was marked as a duplicate.

#47 follow-ups: @swissspidy
8 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

I'm a bit worried about seeing so many reports of breakage.

@ all: If you're affected by this bug, it would be great if you could test 36534.diff by applying those changes to wp-includes/class-wp-image-editor-imagick.php and write here if it works.

@joemcgill How confident would you be with shipping 36534.diff in 4.5.3 and improve things in 4.6 as you previously suggested?

#48 in reply to: ↑ 47 @mouriana
8 years ago

Replying to swissspidy:

I'm a bit worried about seeing so many reports of breakage.

@ all: If you're affected by this bug, it would be great if you could test 36534.diff by applying those changes to wp-includes/class-wp-image-editor-imagick.php and write here if it works.

@joemcgill How confident would you be with shipping 36534.diff in 4.5.3 and improve things in 4.6 as you previously suggested?

OK, so I'm pretty new to the whole WordPress thing (or any web coding at all for that matter, though I have a few years of DB and IT experience under my belt), so forgive me if I'm crazy stupid. I am using WP 4.5.2 on PHP 5.6.
Have been working on 3 separate sites (with 3 separate templates) and getting this error for a little over 24 hours now, though it is happening most consistently on the site that is using the Nisarg template. I have tried shrinking image sizes, using the browser uploader, making the media size huge under tools, editing the themes function file, adding the line to the .htaccess file, and applying the aforementioned 36534.diff patch. Nothing works. If I am trying to add to a page, I get the HTTP error. If I am simply trying to add to my library, it just stops (with MOST images, not all, but my largest image is 4.87 MB), gives me no error, but if I go to the library, the image is listed with no thumbnail. If I click 'view,' the image comes up but I get the following errors:

Warning: Illegal String Offset 'Width' In /src/Wp-Content/Themes/Nisarg/Image.Php On Line 31

Warning: Illegal String Offset 'Height' In /src/Wp-Content/Themes/Nisarg/Image.Php On Line 32

The image is likewise unusable, though I can see it.
Now, if I turn off all my plugins (I only have Jetpack, Event Calendar WD, and Akismet running) AND shrink one of these images by 50% (75% doesn't do it) and try to upload it, it actually crunches it (it doesn't normally do this), and works. However, if I do all those steps except only shrink it to 75%, it TRIES to crunch it, and I get this error:
Fatal error: Out of memory (allocated 39845888) (tried to allocate 450 bytes) in /src/wp-includes/media.php on line 2751

I am using 1and1 for my host and as far as I can tell the size is set correctly on the host end (plus this is behaving erratically from site to site, all of which are hosted on the same package). I can call them, but by now I am tired. :P

Hope that wasn't too much information; I'm new enough to this that I'm trying to be thorough.

#49 in reply to: ↑ 47 ; follow-ups: @kirasong
8 years ago

@joemcgill and I worked with a couple larger hosts that had this issue, who worked quickly to resolve it (thank you!).

For those who reported, if you could test again it'd be helpful.

If you're still having problems, please include the following information so that we can investigate further:

  • Host
  • Example image

And from phpinfo():

  • Imagick Version
  • ImageMagick Version
  • memory_limit
  • max_execution_time
  • max_input_time
  • upload_max_filesize
  • post_max_size

#50 in reply to: ↑ 49 @mouriana
8 years ago

Well then, here's what I got (no, I don't get to go home. I work FROM home. :P)
Host: 1and1.com
Example image: (the one I was trying was a little over 300k and it was much taller than wide. I don't want to upload it here, though).
memory_limit: 120M
max_execution_time:50000
max_input_time: -1
upload_max_filesize: 40M
post_max_size: 8M

I ran all kinds of code to find the Imagick/ImageMagick version, and it kept telling me it didn't know what I was talking about. :-/

At any rate, the support guy at 1and1 was not helpful, but my husband, who is a web developer and finally got home, seemed to know more about what's up, because he was giving me a hard time for trying to upload too big of files (I told you I was a n00b to this stuff!) so I'm going to try some other things.

At least this is better than cleaning the house. :P

Replying to mikeschroder:

@joemcgill and I worked with a couple larger hosts that had this issue, who worked quickly to resolve it (thank you!).

For those who reported, if you could test again it'd be helpful.

If you're still having problems, please include the following information so that we can investigate further:

  • Host
  • Example image

And from phpinfo():

  • Imagick Version
  • ImageMagick Version
  • memory_limit
  • max_execution_time
  • max_input_time
  • upload_max_filesize
  • post_max_size

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


8 years ago

This ticket was mentioned in Slack in #core by adamsilverstein. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


8 years ago

#54 in reply to: ↑ 49 ; follow-up: @anonymized_8660175
8 years ago

I have tried the patch ( 36534.diff) without luck. imagick is not installed in my server, so the problem must be related to other things. OR maybe i get the error because imagick is not installed. Is imagick required now?

I get the HTTP-error instantly when trying to upload an image. Not after or during processing but instantly.

Sometimes when I save a post after the error, the image is somehow showing up in the editor just fine. But only sometimes maybe 1 out of 3 times.

Here is my info:

PHP Version 5.3.3
memory_limit 128M
max_execution_time 60
max_input_time 60
upload_max_filesize 128M
post_max_size 8M

This ticket was mentioned in Slack in #core by adamsilverstein. View the logs.


8 years ago

#56 in reply to: ↑ 54 @kirasong
8 years ago

Replying to Martin_wol:

I have tried the patch ( 36534.diff) without luck. imagick is not installed in my server, so the problem must be related to other things. OR maybe i get the error because imagick is not installed. Is imagick required now?

If you don't have Imagick installed, then this is an unrelated issue. No, Imagick is not required by core -- it falls back to GD when it's not available.

Was this a problem with WordPress 4.4 for you as well?

I'd suggest contacting your host, or posting in the WP support forums if the problem continues (and you haven't already).

This ticket was mentioned in Slack in #core-images by mike. View the logs.


8 years ago

#58 @joemcgill
8 years ago

While doing additional profiling/research for this ticket, I'm noticing that the new compression settings introduced in 4.5 can result in an increase in total wall time while creating images, while memory used is generally the same, so we could be running into time limits that are being applied to ImageMagick on hosts (via their policy.xml settings, for example). Here's the data from an example run:

XHProf run of an image in 4.5
Total Incl. Wall Time (microsec): 2,018,447 microsecs
Total Incl. CPU (microsecs): 1,851,793 microsecs
Total Incl. MemUse (bytes): 4,452,312 bytes
Total Incl. PeakMemUse (bytes): 4,805,744 bytes

XHProf run of an image in 4.4
Total Incl. Wall Time (microsec): 1,676,827 microsecs
Total Incl. CPU (microsecs): 1,092,302 microsecs
Total Incl. MemUse (bytes): 4,449,392 bytes
Total Incl. PeakMemUse (bytes): 4,794,664 bytes

The difference is almost entirely a result of the switch to using Imagick::resizeimage instead of Imagick::scaleimage introduced in [36891]. We're using Imagick's FILTER_TRIANGLE within the resizeImage() function, which produces the best results considering file size savings, image quality, and performance, but is still more resource intensive than if we were to use FILTER_BOX which is the default (I believe).

While WP_Image_Editor_Imagick::thumbnail_image() accepts alternate filters as a parameter, there really is no easy way for users to alter this value unless we were to add a filter before Imagick::resizeimage is called.

We may also be able to check the value of Imagick::getResourceLimit and conditionally use the FILTER_BOX filter when the available resource time is low, but I'm not sure.

#59 @Chaton666
8 years ago

Some news...
The patch 36534.diff works if the uploaded images size are less than 200 Ko.
(WP MU 4.5.2, 1&1 hosting)

#60 follow-up: @monikarao
8 years ago

Just tested the patch and I am not getting this issue its working for me.

OS: Windows 10
Browser: Chrome 50.0.2661.102 , Safari 5.1.7 , IE-11 , Firefox 46.0.1
WP 4.5.2 , 4.5.3-alpha-37528
Server Environment : VVV
Example Image: https://cdn.photographylife.com/wp-content/uploads/2014/06/Nikon-D810-Image-Sample-6.jpg

http://vangoyourself.com/wp-content/uploads/2014/04/Self-portrait-Vincent-van-Gogh-1887.jpg

Last edited 8 years ago by monikarao (previous) (diff)

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


8 years ago

#62 in reply to: ↑ 60 ; follow-up: @kirasong
8 years ago

Replying to monikarao:

Just tested the patch and I am not getting this issue its working for me.

Server Environment : VVV

Was it a problem in VVV without the patch?

#63 @joemcgill
8 years ago

  • Milestone changed from 4.5.3 to 4.6

While the current patch is working for many people, it's kind of a sledgehammer for folks who are on systems that support multi-threading and not something I would want to force on everyone at this point. Let's keep working on it but I'm going to move it out of the 4.5.3 milestone.

#64 @kirasong
8 years ago

  • Severity changed from major to normal

#65 in reply to: ↑ 62 @monikarao
8 years ago

Replying to mikeschroder:

Replying to monikarao:

Just tested the patch and I am not getting this issue its working for me.

Server Environment : VVV

Was it a problem in VVV without the patch?

No,I have applied grunt patch:36534

#66 follow-up: @Dvaer
8 years ago

Thank you everyone for working on this. I've experienced the same issue on 2 client sites now. Both running on WordPress 4.5.2 and on the same host (Site5). In our case the functions.php fix suggested by @smashingjay solved the problem in both cases.

testimage here http://s33.postimg.org/tv0ruf1lb/strawberries.jpg

http://s33.postimg.org/tv0ruf1lb/strawberries.jpg

From phpinfo():
PHP Version: 5.5.34
Imagick Version: 3.3.0RC2
ImageMagick Version: 6.7.9-10 2013-08-29 Q16
memory_limit: 128M
max_execution_time: 30
max_input_time: 60
upload_max_filesize: 128M
post_max_size: 128M

This wasn't an issue on these 2 sites before. When initially troubleshooting I turned off all plugins, which made the image uploads work again. But then re-enabling plugins one by one I couldn't isolate a single plugin as causing a conflict. It was more that after 3 or 4 plugins were active again, the issue reappeared. But it didn't seem to matter which plugins.

Other client sites on the same server with very similar setups are not having this problem. The common thing with these 2 sites was that they are both running a child theme. I'll check some of our other sites to see if that might have anything to do with it and report back here.

#67 in reply to: ↑ 66 @Dvaer
8 years ago

Checked a handful of 4.5.2 sites with very similar setups (plugins and theme-wise), but found nothing consistent. I did see that several clients have had problems, because they have some image-files without thumbnails in their media libraries. But for all of them they seem to have been intermittent problems that went away by themselves, because they all have newer images files with tumbnails also. The problem sites were a mix of ones running child-themes and just parent themes without a child-theme. One of the sites (with a child-theme active) doesn't seem to have had any problems with image uploads and on trying my test-image uploaded it fine.

Happy to do further testing or set up a test-site if that would be useful.

Replying to Dvaer:

Other client sites on the same server with very similar setups are not having this problem. The common thing with these 2 sites was that they are both running a child theme. I'll check some of our other sites to see if that might have anything to do with it and report back here.

#68 in reply to: ↑ 7 @melissasaywhat
8 years ago

This worked for me, too!

Replying to unicornbacon:

Replying to smashingjay:

@unicornbacon you may wish to try the fix here: https://wordpress.org/support/topic/http-errors-on-media-uploads-after-45-update?replies=24#post-8300481 which should be relatively easy and would also prove out the issue further, that it relates to Imagick.

Oh! THANK YOU!! That worked! I added that code to the functions.php page, and so far, I have been able to upload everything that has been failing since the 4.5 update! Thank you kind stranger! You have snatched my dreams from the jaws of oblivion!

#69 follow-ups: @pkilmartin
8 years ago

I don't think the issue is fully understood judging by the threads I've seen. This weekend, I moved two sites to different providers, and when they looked ok, went ahead an upgraded WP from 4.4.3 to 4.52, along with all plugins. Both sites had the image issue.

I tried all of the various workarounds (SetEnv MAGICK_THREAD_LIMIT 1 in .htaccess, adding the lines to functions.php in child theme, applying the fixes from the patch, verifying permissions, verified PHP settings were above the problematic ones listed) without success. There was a youtube video about changing PHP's reporting errors, which silenced the http errors but didn't fix the underlying problem. Rather than update imagick from 6.7.2-7, i elected to downgrade WP.

I put in place the pre-upgrade public_html directory (from prior to the migration) and changed db_version in wp_options from 36686 to 35700. This was effective. Hopefully all the db changes are backwards compatible (couldn't find documentation on the db changes).

Of note is that the images were always uploaded, they just showed as broken in the media library and in the posts, when tried.

Here is my info:
imagick version: ImageMagick 6.7.2-7 2016-05-09 Q16 module version is 3.4.1
PHP Version 5.6.21
memory_limit 512M
max_execution_time 60
max_input_time 60
upload_max_filesize 128M
post_max_size 128M

Last edited 8 years ago by pkilmartin (previous) (diff)

#70 @andrewreal
8 years ago

Just stepping in to report that I am also seeing the same problem on a site running 4.5.2.

I've tried all the suggested solutions including the diff patch, functions.php alterations and the .htaccess addition. Tried switching to Twenty Fifteen theme to rule out the theme but still no luck.

Hosting provider : 1and1
Theme : Enfold based child theme
PHP Version 7.0.7
memory_limit 512M
max_execution_time 360
post_max_size 64M

The file I'm using to test at the moment is 1,481KB, 4500 x 3000 pixels.

I can confirm that the file gets uploaded into the uploads folder but no size variations are produced.

Please find a fix soon as my daughter is giving me grief after I just moved her blog from Blogger to WordPress. :-)

#71 @jiuzton
8 years ago

  • Severity changed from normal to major

I have tried all the fixes listed here and nothing seems to work. Even reinstalled WordPress.
I'm also using 1and1 hosting provider. Wordpress was installed using their 1&1 App Center.
Sub-domain being used. Uploading using the wordpress app also fails most of the time.

HTTP error.
HTTP error.

#72 in reply to: ↑ 69 @melissasaywhat
8 years ago

  • Keywords needs-patch added; has-patch removed

The fixes I've tried work for a minute (maybe a day) then I started having the same issue again.

"Of note is that the images were always uploaded, they just showed as broken in the media library and in the posts, when tried." --- This is exactly what's happening to me.

I went back and checked all the code I had edited and it was still in place. I reverted it, tried each one, one by one, again and I'm back at square one.

Replying to pkilmartin:

I don't think the issue is fully understood judging by the threads I've seen. This weekend, I moved two sites to different providers, and when they looked ok, went ahead an upgraded WP from 4.4.3 to 4.52, along with all plugins. Both sites had the image issue.

I tried all of the various workarounds (SetEnv MAGICK_THREAD_LIMIT 1 in .htaccess, adding the lines to functions.php in child theme, applying the fixes from the patch, verifying permissions, verified PHP settings were above the problematic ones listed) without success. There was a youtube video about changing PHP's reporting errors, which silenced the http errors but didn't fix the underlying problem. Rather than update imagick from 6.7.2-7, i elected to downgrade WP.

I put in place the pre-upgrade public_html directory (from prior to the migration) and changed db_version in wp_options from 36686 to 35700. This was effective. Hopefully all the db changes are backwards compatible (couldn't find documentation on the db changes).

Of note is that the images were always uploaded, they just showed as broken in the media library and in the posts, when tried.

Here is my info:
imagick version: ImageMagick 6.7.2-7 2016-05-09 Q16 module version is 3.4.1
PHP Version 5.6.21
memory_limit 512M
max_execution_time 60
max_input_time 60
upload_max_filesize 128M
post_max_size 128M

@joemcgill
8 years ago

Use FILTER_BOX during resizing

#73 follow-up: @joemcgill
8 years ago

Thanks everyone for the new reports. If you're still experiencing this issue, would you mind testing out the changes from 36534.2.diff to see if this patch has any affect? I believe that some of the changes to the resizing process that were introduced in 4.5 could be hitting Imagick's internal time limits.

#74 @joemcgill
8 years ago

I've also added some extra debugging information to the Debug Media plugin that will give us more information about Imagick's resource limits. If those who are having issues could install the plugin and share the information gathered by the plugin about your environment, that would be helpful as well.

#75 @jiuzton
8 years ago

Thanks for the Debug plugin. It seems like I don't even have ImageMagick.
I did 1and1's Install ImageMagick via SSH: http://help.1and1.com/hosting-c37630/webspace-and-access-c85098/ssh-c37775/install-imagemagick-via-ssh-a649013.html
But nothing, (php -m) on SSH does not show it and to install it I need root access.
1and1 support did not understand the situation and after looking around seems that they won't even install third party extension. I guess it's time to shop for hosting provider

#76 @andrewreal
8 years ago

The debug plugin appears to also show that ImageMagick is not installed or not working so I've raised a ticket with my host 1and1 and await their response. It seems strange that small images are being uploaded and are being resized though so I don't think this issue is fully resolved.

Media Debugging Info

Active Editor WP_Image_Editor_GD
Imagick Module Number Imagick not available
ImageMagick Version Imagick not available
GD Version bundled (2.1.0 compatible)
Memory Limit 256M
Max Execution Time 360
Max Input Time -1
Upload Max Filesize 64M
Post Max Size 64M

#77 @mboynes
8 years ago

Jumping in to report that I believe I'm also experiencing this issue on Pantheon. Since 4.5, I can no longer upload images larger than 3601x3601. I installed the debug media plugin, and here's what it reports:

Media Debugging Info

Active Editor	WP_Image_Editor_Imagick
Imagick Module Number	1672
ImageMagick Version	ImageMagick 6.8.8-10 Q16 x86_64 2015-03-10 http://www.imagemagick.org
GD Version	bundled (2.1.0 compatible)
Memory Limit	256M
Max Execution Time	120
Max Input Time	900
Upload Max Filesize	100M
Post Max Size	100M

Imagick Resource Limits
Imagick area limit	59 GB
Imagick disk limit	-1
Imagick file limit	768
Imagick map limit	59 GB
Imagick memory limit	29 GB
Imagick thread limit	Not Available

@joemcgill, I tried changing FILTER_TRIANGLE to FILTER_BOX and that didn't resolve the issue. if you'd like, I can set you up with a vanilla WP install on Pantheon so you can more easily debug the issue. Ping me in slack (@mboynes) if that would be helpful.

Side note: 36534.2.diff misses an instance:

$filter = defined( 'Imagick::FILTER_BOX' ) ? Imagick::FILTER_TRIANGLE : false;

should be

$filter = defined( 'Imagick::FILTER_BOX' ) ? Imagick::FILTER_BOX : false;
Last edited 8 years ago by mboynes (previous) (diff)

#78 @Dvaer
8 years ago

Reporting back on another site with this issue. All images smaller than 200KB.

From Debug Log

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /wp-includes/class-wp-image-editor-imagick.php on line 350

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /wp-includes/class-wp-image-editor-imagick.php on line 358

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /wp-includes/class-wp-image-editor-imagick.php on line 338

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /wp-includes/class-wp-image-editor.php on line 425

Not working: https://core.trac.wordpress.org/ticket/36534#comment:73

Working: https://core.trac.wordpress.org/ticket/36534#comment:6

From Debug Media plugin

Media Debugging Info
Active Editor 	WP_Image_Editor_Imagick
Imagick Module Number 	1657
ImageMagick Version 	ImageMagick 6.7.9-10 2013-08-29 Q16 http://www.imagemagick.org
GD Version 	bundled (2.1.0 compatible)
Memory Limit 	256M
Max Execution Time 	30
Max Input Time 	60
Upload Max Filesize 	128M
Post Max Size 	128M
Imagick Resource Limits
Imagick area limit 	126 GB
Imagick disk limit 	-1
Imagick file limit 	12288
Imagick map limit 	126 GB
Imagick memory limit 	63 GB
Imagick thread limit 	32

#79 @mukundi
8 years ago

I also have the same problem after upgrade to 4.5
SetEnv MAGICK_THREAD_LIMIT 1 is not working even for 100kB images

Last edited 8 years ago by mukundi (previous) (diff)

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


8 years ago

#81 @ocean90
8 years ago

  • Milestone changed from 4.6 to Future Release

Based on the latest chat and the lack of a patch I'm going to punt this from the 4.6 milestone.

#82 @ocean90
8 years ago

#37154 was marked as a duplicate.

#83 in reply to: ↑ 73 @jayztw
8 years ago

Replying to joemcgill:

Thanks everyone for the new reports. If you're still experiencing this issue, would you mind testing out the changes from 36534.2.diff to see if this patch has any affect? I believe that some of the changes to the resizing process that were introduced in 4.5 could be hitting Imagick's internal time limits.

Thanks your help ,after patch to single thread or FILTER_BOX are not working,
both GD and imagick Editor get http error ,GD editor get less error,hope this issue will be solved soon.

I am running WP 4.5.3, hosted by Dreamhost.

here is my debug info:

Active Editor WP_Image_Editor_Imagick
Imagick Module Number 1641
ImageMagick Version ImageMagick 6.6.9-7 2014-03-06 Q16 http://www.imagemagick.org
GD Version bundled (2.1.0 compatible)
Memory Limit 256M
Max Execution Time 1000
Max Input Time 500
Upload Max Filesize 64M
Post Max Size 2000M

Imagick Resource Limits

Imagick area limit 8 GB
Imagick disk limit -1
Imagick file limit 768
Imagick map limit 63 GB
Imagick memory limit 31 GB
Imagick thread limit Not Available

Last edited 8 years ago by jayztw (previous) (diff)

#84 @markhowellsmead
8 years ago

Replying to @jayztw :

I had been experiencing HTTP 503 errors using the uploader, although the DB entry was correctly created and the file was correctly uploaded. Using the diff patch certainly stops the error from occurring, but the thumbnails aren't generated. Neither when uploading nor when using the Regenerate Thumbnails plugin, which has always worked in the past. WP 4.6 in PHP 7 on Linux.

Last edited 8 years ago by markhowellsmead (previous) (diff)

#85 follow-up: @nomadcoder
8 years ago

Make sure that you aren't experiencing any errors with your other plugins or theme when experiencing http upload errors. Any output, error reporting or echoing, will break ajax processing and will interfere with uploads causing an error. There are a few ways to track down the culprit. The easy way: Try turning off debug or outputting it to debug.log. You could try disabling other plugins to determine the issue. Try switching themes to determine that it's not an issue with the theme. I think that it could also be a database issue, so backing up your database (very important) and running a repair on it might help. In short , it is possible that ajax is receiving data that it can't process because of the warning messages that are interfering with your uploads and possibly thumbnail generation.

#86 in reply to: ↑ 85 @markhowellsmead
8 years ago

Replying to nomadcoder:

The server always throws a 503 error when I upload, but doesn't write anything to the PHP error log or to the regular raw server statistics. Identical code in an identical local installation works fine. After implementing the patch, there are no errors at all. But no thumbnails generated either.

Last edited 8 years ago by markhowellsmead (previous) (diff)

#87 follow-up: @nomadcoder
8 years ago

Ah, I believe that I misread your comment as to the actual error number you were getting. I think that error 503 might be a server error, possibly security. Someone else who knows more can correct me.

#88 in reply to: ↑ 87 ; follow-up: @markhowellsmead
8 years ago

Replying to nomadcoder:

503 is Service Unavailable, which seems to get thrown for an unknown reason. It's certainly not a timeout, which is 500 and which would occur after 240 seconds on my server. I'm assuming that changing to FILTER_BOX is more efficient, which helps the upload. I'll have to go back to basics and deactivate everything else in the installation to see whether it's a plugin of theme function interfering.

#89 in reply to: ↑ 88 @joemcgill
8 years ago

Replying to markhowellsmead:

Replying to nomadcoder:

503 is Service Unavailable, which seems to get thrown for an unknown reason. It's certainly not a timeout, which is 500 and which would occur after 240 seconds on my server. I'm assuming that changing to FILTER_BOX is more efficient, which helps the upload. I'll have to go back to basics and deactivate everything else in the installation to see whether it's a plugin of theme function interfering.

FWIW, I've seen 503 errors occur because of misconfigurations with ImageMagick, but it's hard to tell exactly what is happening without checking your server logs to see what error is being reported.

#90 @joemcgill
8 years ago

#37853 was marked as a duplicate.

This ticket was mentioned in Slack in #core-images by mike. View the logs.


8 years ago

#92 follow-up: @aldon
8 years ago

i add the fix code on fuctions.php, and now image uploaded but doesn’t create thumbs (wordpress 4.6.1)

any help?

This ticket was mentioned in Slack in #core by joemcgill. View the logs.


8 years ago

#94 follow-up: @mhowellsmead
8 years ago

Found it! After deactivating all of the plugins and reverting to the default Theme, the problem still occurred. Further tests indicated that the JPGs we were working with had been saved in (an invalid) four-colour CMYK format. Although ImageMagick can convert invalid images in this format, the server appears to have a problem with them.

#95 @megabulk2
8 years ago

Affecting me on WestHost, WP version 4.6.1.
The two fixes to limit the ImageMagick threads (via .htaccess https://core.trac.wordpress.org/ticket/36534#comment:11 or patching class-wp-image-editor-imagick.php https://core.trac.wordpress.org/ticket/36534#comment:10) didn't work, but adding the code to functions.php to switch the image engine to gd did the trick https://core.trac.wordpress.org/ticket/36534#comment:25

And I filed a ticket with them and asked them to look into their configuration of OpenMP. I hope they deal with it.

#96 in reply to: ↑ 92 ; follow-up: @isakengstrom
7 years ago

I've got the exact same problem. Any fix for that?

Replying to aldon:

i add the fix code on fuctions.php, and now image uploaded but doesn’t create thumbs (wordpress 4.6.1)

any help?

#97 in reply to: ↑ 96 ; follow-up: @markhowellsmead
7 years ago

Replying to isakengstrom:

I've got the exact same problem. Any fix for that?

Have you made sure that the images are in RGB format?

#98 in reply to: ↑ 97 ; follow-up: @isakengstrom
7 years ago

Replying to markhowellsmead:

Replying to isakengstrom:

I've got the exact same problem. Any fix for that?

Have you made sure that the images are in RGB format?

Some are, some not. But the problem occurs regardless if it's in RGB or CMYK.

Here's a picture of the site I'm working on (it's in swedish):
https://www.dropbox.com/s/xsducxrosckh8jh/thumbnails.png?dl=0
The two post on top and the one down to the left I've added before I added the fix to functions.php and the one on the bottom right after I added it.

#99 in reply to: ↑ 98 ; follow-up: @markhowellsmead
7 years ago

I've got the exact same problem. Any fix for that?

Which error are you getting? The timeout (Maximum execution time of 30 seconds exceeded) or the “HTTP Error” message?

#100 in reply to: ↑ 99 ; follow-up: @isakengstrom
7 years ago

Replying to markhowellsmead:

I've got the exact same problem. Any fix for that?

Which error are you getting? The timeout (Maximum execution time of 30 seconds exceeded) or the “HTTP Error” message?

The HTTP error.
I've now identified that it is a problem with the thumbnail generation. When I change the image engine to GD I can upload images (no HTTP error) but WP doesn't generate any thumbnails. If i switch back to ImageMagick I can regenerate the thumbnails and then they're all showing properly, but if I use ImageMagick I can't uploading images without getting the HTTP error. So I have to switch between the two image engines to get it right...

My WP-installation is 4.6.1 and I use the theme "Newspaper" by Tagdiv. The server runs PHP 5.6.12.

#101 in reply to: ↑ 100 @markhowellsmead
7 years ago

Replying to isakengstrom:

I've now identified that it is a problem with the thumbnail generation. When I change the image engine to GD I can upload images (no HTTP error) but WP doesn't generate any thumbnails. If i switch back to ImageMagick I can regenerate the thumbnails and then they're all showing properly, but if I use ImageMagick I can't uploading images without getting the HTTP error. So I have to switch between the two image engines to get it right...

This sounds like *exactly* the same problem I was experiencing. In my case, I got around the problem completely by using ImageMagick and ensuring that all images were in RGB format. If you're getting the same issue but with RGB images, then I guess the problem is deeper than the circumstances I could reproduce.

#102 @cezariuszmarek
7 years ago

In my case the problem is not related to the RGB format of images, because it occurs randomly on some images. Uploading the same image once or twice again finally succeeds, but the failed images leave trash in the database. See #37853 for details.

#103 @vonnieB
7 years ago

My client was on WP v.4.6.1 when I discovered the image upload issue. I only just came onto the project so I cannot verify when the issue began as they hadn't used the image upload for a long time before that but it was likely a v4.5.x.

I was getting the generic HTTP error on upload of even the smallest of files (sub-100k) and the successful uploading of any images at all was inconsistent and very unreliable. The only way I was able to resolve the issue was to default to the GD library. Now it works as normal.

PHP Version 5.4.45
Host: Site5

Last edited 7 years ago by vonnieB (previous) (diff)

#104 @asirota
7 years ago

  • Severity changed from major to normal

Lots of threads with this problem being reported all over the net. It's pretty clear to me that the various configuration issues that "fix" the issue really are just band aids to an underlying problem with some of the image management innovation in v4.5. Some people are helped with .htaccess changes with the SetEnv variable or changing some timing parameters to allow a process to complete. For many those changes don't work and only switching to GD works which means a totally different code path is followed. This means that the underlying problem still exists on many configuration but the GD change is a total workaround with probably less features/support in the future. Even the PHP version update sometimes helps which probably is a different starting point configuration "fixing" the problem, but again that's not always the case.

Here's the configuration we were able to simulate with sample images:

https://wordpress.org/support/topic/media-upload-not-working-http-error/page/2/#post-8435954

There are other examples of solutions without proper debug features.

I'll upload the debug media details and post. I'd really like to see this fixed with maybe setting some parameters/changes that provide a more reliable method than switching to GD as the "worst case" scenario.

#105 @asirota
7 years ago

To fix my problem I added the functions.php patch published by @mikeschroder on github. I tried various fixes described above and only switching to GD fixed it. I removed the thread limit for imagick from .htaccess and left the PHP parameters as below.

The setup is on "Managed WordPress" at GoDaddy... The media sample I was having HTTP errors reported is 3600px across but only 2MB in size.

Here's a smaller version that is 1800px across (and smaller as a result) that had no problem WITHOUT any reconfiguration at all.

I am happy to work with a developer to troubleshoot this issue as we have lots of WordPress sites we can spin up to experiment with configuration examples.

From Debug plugin
PHP
5.4.45

MySQL
5.6.32

Memory Usage
101,921,160 bytes

Media Debugging Info

Active Editor	WP_Image_Editor_GD
Imagick Module Number	1620
ImageMagick Version	ImageMagick 6.5.4-7 2014-02-10 Q16 OpenMP http://www.imagemagick.org
GD Version	bundled (2.1.0 compatible)
Ghostscript Version	8.70
Memory Limit	2048M
Max Execution Time	1600
Max Input Time	160
Upload Max Filesize	256M
Post Max Size	120M

#106 in reply to: ↑ 69 @asirota
7 years ago

Replying to pkilmartin:

I put in place the pre-upgrade public_html directory (from prior to the migration) and changed db_version in wp_options from 36686 to 35700. This was effective. Hopefully all the db changes are backwards compatible (couldn't find documentation on the db changes).

Of note is that the images were always uploaded, they just showed as broken in the media library and in the posts, when tried.

That's what I was seeing as well, in terms of thumbnails breaking. As per a previous profiling post by @joemcgill it looks like the changes in 4.5 require more horsepower and time to process and depending on the input and configuration they break in certain situations. Seems like we'd need to setup some conditions to check what the resources are available in the current configuration and fail back to GD although setting these parameters is probably not easily determined or accurate. Tough problem!

Maybe catching the HTTP error and reprocessing with GD would be an alternative?

#107 in reply to: ↑ 94 @asirota
7 years ago

Replying to mhowellsmead:

Further tests indicated that the JPGs we were working with had been saved in (an invalid) four-colour CMYK format. Although ImageMagick can convert invalid images in this format, the server appears to have a problem with them.

How to do you check to see if the images we have problems with are in the 4 colour CMYK format? What do you use to inspect the image for this?

#108 @asirota
7 years ago

I wonder if the code from this Stackoverflow post (esp the imagemagick and GD versions to spot RGB vs CMYK) can be used to diagnose the image being uploaded and take appropriate measures depending on what we find to be the limits on Image Magick's processing capabilities. I know we're sort of down a rat hole here, but this problem really irks me for some reason :)

One thing that I have seen is very wide images cause processing to fail, although I have seen other issues so there may be multiple root causes here.

#109 follow-up: @cezariuszmarek
7 years ago

I think this issue should be split into two separate cases:

  1. Related to a wrong image format (CMYK), when the image is never correctly uploaded (some cases of too big images could match this category as well)
  2. Related to random errors, which cannot be reliably reproduced, related probably to server and PHP configuration, timeouts and other errors, leaving garbage in the database.

And it should be clearly stated that switching to GD is not a fix, it's just an ugly workaround with some other consequences (like quality).

#110 in reply to: ↑ 109 @nomadcoder
7 years ago

Replying to cezariuszmarek:

I am very certain that these are two different issues, but have dealt with both of them on almost every single site that I've worked on. I have found that saving the image in a different format enabled me to deal with issue 1. Issue #2 is always caused by something different - in most cases, some plugin or another that is throwing an error that messes with ajax. It seems like ajax issues could be resolved by isolating functionality. I know that might be a big deal to refactor, but that's my take.

#111 @nhangen
7 years ago

Experienced this issue on 4.7 w/ PHP 5.5.38. All files were under 1MB.

Both patches worked, but required max_execution_time to be increased to 45s

max post set to 32M
max filesize set to 16M

On a MediaTemple DV

#112 @asirota
7 years ago

I've setup a totally bare WP 4.7 core server, using 2017 theme. My sample image file still breaks the upload with an HTTP error. I have chatted with others online who have seen this problem with images wider than 3500px across (regardless of physical file size).

Disabled all plugins that come on core, only debug media/debug bar plugins enabled to generate the output below. I set max_execution_time in .user.ini to see if a longer time would help, but it did not even at 360. I've experimented with imagemagick environment variables like MAGICK_THREAD_LIMIT and MAGICK_TIME_LIMIT without any success yet


Managed WordPress at GoDaddy

PHP
5.6.27

MySQL
5.6.32

Memory Usage
5,620,464 bytes

Media Debugging Info

Active Editor	WP_Image_Editor_Imagick
Imagick Module Number	1620
ImageMagick Version	ImageMagick 6.5.4-7 2014-02-10 Q16 OpenMP http://www.imagemagick.org
GD Version	bundled (2.1.0 compatible)
Ghostscript Version	8.70
Memory Limit	256M
Max Execution Time	360
Max Input Time	60
Upload Max Filesize	256M
Post Max Size	65M

Imagick Resource Limits
Imagick area limit	251 GB
Imagick disk limit	-1
Imagick file limit	24575
Imagick map limit	503 GB
Imagick memory limit	189 GB
Imagick thread limit	Not Available

#113 @lukecavanagh
7 years ago

@asirota

Just uploaded the image optimized version of that image to a GD WP managed site and the image uploaded fine.

File name: Image_that_breaks_WordPress_upload.jpg
File type: JPG
File size: 119 KB
Dimensions: 3600 × 1800

@lukecavanagh
7 years ago

Test Image - 3600 × 1800 pixels

#114 @asirota
7 years ago

@lukecavanagh -- are you using Image Magick or GD as your graphics editor? If you can install the Debug/Media plugins and provide your output that would be great! Any changes to .htaccess/wp-config.php parameters would be welcome as well.

BTW, I am assuming your upload didn't HTTP error and the thumbnail shows up ok in the media library?

Last edited 7 years ago by asirota (previous) (diff)

#115 @lukecavanagh
7 years ago

@asirota

Sure let me get that info.

No HTTP error and the thumbnail was created correctly in the media library.

#116 follow-up: @lukecavanagh
7 years ago

@asirota

Here is that info.

Active Editor	WP_Thumb_Image_Editor_Imagick
Imagick Module Number	1620
ImageMagick Version	ImageMagick 6.5.4-7 2014-02-10 Q16 OpenMP http://www.imagemagick.org
GD Version	bundled (2.1.0 compatible)
Ghostscript Version	8.70
Memory Limit	256M
Max Execution Time	30
Max Input Time	60
Upload Max Filesize	64M
Post Max Size	65M

#117 in reply to: ↑ 116 @asirota
7 years ago

Thanks @lukecavanagh !

Are you on WP 4.5+ on this server? Please provide the WP version and php version. Should be at the top of the debug output.

Also the ImageMagick Resource limits from the debug media plugin... called Imagick Resource Limits

Also I noted something interesting in your output. Your image editor is called:
WP_Thumb_Image_Editor_Imagick

Mine is called...

WP_Image_Editor_Imagick

Why the difference??? Do you have anything in functions.php or a plugin that would switch out the Active Image editor?

Replying to lukecavanagh:

@asirota

Here is that info.

Active Editor	WP_Thumb_Image_Editor_Imagick
Imagick Module Number	1620
ImageMagick Version	ImageMagick 6.5.4-7 2014-02-10 Q16 OpenMP http://www.imagemagick.org
GD Version	bundled (2.1.0 compatible)
Ghostscript Version	8.70
Memory Limit	256M
Max Execution Time	30
Max Input Time	60
Upload Max Filesize	64M
Post Max Size	65M
Last edited 7 years ago by asirota (previous) (diff)

#118 @lukecavanagh
7 years ago

@asirota

No not running WP 4.5 on that site, it is running WP 4.7.

#119 @asirota
7 years ago

Surely this experience is far from an ideal WordPress experience .

http://blog.khojdo.com/http-error-while-image-upload-in-wordpress-version-4-7-2-step-by-step-tutorial-solved/

We need to solve this. Anyone want to help?

#120 follow-up: @RudiAhlers
7 years ago

  • Severity changed from normal to critical
  • Version 4.5 deleted

Can someone please tell me what the status is on this problem?

As a shared hosting company, we can't go an fix client's Wordpress installations the whole time due to a bug in Wordpress.

One client said it's easier to use Joomla! than to try and fix this issue the whole time.

What worked for us?
the .htaccess method

I can confirm, I used the patch (https://core.trac.wordpress.org/attachment/ticket/36534/36534.2.diff) to one website's Wordpress files, but it made no difference.

Server specs right now:

php -v

PHP 5.6.25 (cli) (built: Sep 1 2016 23:25:06)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

with XCache v3.2.0, Copyright (c) 2005-2014, by mOo
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.1.1, Copyright (c) 2002-2016, by ionCube Ltd.
with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo
with Suhosin v0.9.38, Copyright (c) 2007-2015, by SektionEins GmbH

convert --version

Version: ImageMagick 6.7.2-7 2016-06-17 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

root@neptune:[~]$ php -i | grep memory_limit
memory_limit => 250M => 250M

Tested on Wordpress 4.7.2

#121 @Christoph Nahr
7 years ago

I've been having the same problem, with a twist. My cheap shared host doesn't even offer Imagick so I'm using the standard PHP GD library to resize images. Yet some images caused the same problem of stalling after upload, unable to generate the requisite smaller sizes. I cannot change any PHP performance settings (because of cheap shared host) but I did find a sort of solution.

  1. First step: iPhone and Sony NEX-7 photos upload fine, some larger Sony A7R photos don't. Upgraded PHP from 5.6 to 7.1, and A7R photos now upload fine as well.
  1. Second step: Certain (not all!) even larger Sony A7R II photos repeatedly fail to upload, even when reducing Lightroom export quality to achieve an image size of 5 MB or so. Perhaps total image size in pixels, combined with certain image contents, is a narrow failure condition?

So I told Lightroom to reduce the dimensions of A7R II photos (7952 x 5304) to A7R size (7360 x 4909). This visually imperceptible downscaling allowed all my problem pictures to upload just fine, even if the JPEG size exceeds 10 MB.

edit: In a second batch of A7R II photos, this resizing now caused different uploads to fail. Very slightly changing the size again, to 7346 x 4900 pixels, allowed all uploads to succeed.

Reducing image size has been recommended previously but I wanted to point out that you may not need to downscale images to an unusable low resolution. Just getting slightly below some weird PHP image library threshold may solve your problem, with no visible degradation.

Last edited 7 years ago by Christoph Nahr (previous) (diff)

#122 follow-up: @Dvaer
7 years ago

Some more information. I'm seeing this problem on one of my hosts (Site5). They fixed it for me by adding the below configuration values in .user.ini file:

max_execution_time = 7200
upload_max_filesize = 1024M
post_max_size = 100M
max_input_time = 500
memory_limit = 512M
max_input_vars = 5000

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


7 years ago

#124 @Johnobo
7 years ago

As in the original Ticket mentioned: the problem seems to be related rather to resolution and not file size. I did a check with 2 Images (9:16 & 16:9) saved them in different qualities and different resolutions:

Image 01 ( 9:16, Portrait ) : 
Smartphone Pic | Quality 100 | 2336x4160 | 2.3MB => FAILED
PS_SavedForWeb | Quality 100 | 2336x4160 | 3.3MB => FAILED
PS_SavedForWeb | Quality  20 | 2336x4160 | 244KB => FAILED
PS_SavedForWeb | Quality 100 | 1900x0959 | 959KB => WORKS
PS_SavedAsJPEG | Quality 100 | 1900x1900 | 1.8MB => WORKS

Image 02 ( 16:9, Landscape ) : 
Smartphone Pic | Quality 100 | 4160x2336 | 2.8MB => FAILED
PS_SavedForWeb | Quality 100 | 4160x2336 | 4.2MB => FAILED
PS_SavedForWeb | Quality  20 | 4160x2336 | 463KB => FAILED
PS_SavedForWeb | Quality 100 | 1900x1067 | 1.3MB => WORKS
PS_SavedAsJPEG | Quality 100 | 1900x1900 | 1.8MB => WORKS

* "PS_*" = Photoshop

All Images failed with HTTPError before 120second Execution Time Limit.

max_input_time      = 60
max_execution_time  = 120
upload_max_filesize = 10M
post_max_size       = 16M
memory_limit        = 128M

I didn't changed any fcigd settings.

Last edited 7 years ago by Johnobo (previous) (diff)

#125 in reply to: ↑ 122 @pkilmartin
7 years ago

I originally reported my issues in #69.

As I needed to migrate those sites to new hosting this year, I played with the old instances to see if I could get this to work.

ImageMagick version is 6.7.2-7

I upgraded straight to 4.7.5, then disabled all plugins, and used several test images, and then the test image from #113.

No luck, at least not consistently.

I used your reported settings below, but in php.ini, not in .user.ini

No Luck.

Lastly, Added SetEnv MAGICK_THREAD_LIMIT 1 , which had not worked a year ago, and was successful.

Replying to Dvaer:

Some more information. I'm seeing this problem on one of my hosts (Site5). They fixed it for me by adding the below configuration values in .user.ini file:

max_execution_time = 7200
upload_max_filesize = 1024M
post_max_size = 100M
max_input_time = 500
memory_limit = 512M
max_input_vars = 5000

#126 in reply to: ↑ 120 @kirasong
7 years ago

Replying to RudiAhlers:

Can someone please tell me what the status is on this problem?

As a shared hosting company, we can't go an fix client's Wordpress installations the whole time due to a bug in Wordpress.

One client said it's easier to use Joomla! than to try and fix this issue the whole time.

What worked for us?
the .htaccess method

I missed this ticket update initially, so updating a bit late.

If you're a shared hosting company, and the .htaccess method fixed it, this means that your Imagick/Imagemagick either has a bug in terms of the versions used/compiled for the platform, or it isn't configured correctly.

The OpenMP/threading issue is not a WordPress bug, so I'd suggest fixing it globally so that your WordPress customers don't have this problem anymore.

One of the simplest solutions would be to use the same configuration that fixed it in the .htaccess rule for the one customer on the rest of the platform. I'd also suggest having your SysEng team take a look at Imagick and Imagemagick on your platform to make sure it's compiled with equal versions, and configured appropriately for your systems.

#127 in reply to: ↑ 47 @nhangen
6 years ago

Replying to swissspidy:

I'm a bit worried about seeing so many reports of breakage.

@ all: If you're affected by this bug, it would be great if you could test 36534.diff by applying those changes to wp-includes/class-wp-image-editor-imagick.php and write here if it works.

@joemcgill How confident would you be with shipping 36534.diff in 4.5.3 and improve things in 4.6 as you previously suggested?

This worked for me. Is there any way to filter this so the fix can persist throughout updates?

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


5 years ago

#129 @mrdanack
5 years ago

Hello. I'm the maintainer of Imagick. I got pointed to this bug by: https://bugs.php.net/bug.php?id=77683

Setting the parameter via env setings is inherently unsafe in all multi-threaded environments.

It should be possible to set this via code instead by doing:

Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1);

Obviously that would need to be wrapped with the appropriate check to see if the extension exists, and if the function exists. Or possibly calling Imagick::setResourceLimit(6, 1); in case the version of Imagick doesn't have that resource set.

For the record - OpenMP is meant to be used for CLI programs only. As far as I'm aware it's not designed at all to be running inside another multi-threaded environment like Apache.

#130 @mrdanack
5 years ago

For everyone thinking that images over a certain size fail, you should probably check the other resource limits through http://php.net/manual/en/imagick.getresourcelimit.php

#131 @joedolson
5 months ago

  • Keywords close added

Given the lack of activity on this in the last five years, I suspect that the underlying cause was outside of WordPress and is largely fixed upstream. Recommending for close. If somebody more familiar with the upstream hosting issues (@mikeschroder, perhaps) wants to confirm, I'd appreciate it.

#132 @kirasong
5 months ago

Hi @joedolson !

I agree. I think most of the issues listed are a variety of hosting configuration issues.

There have been improvements both in upstream libraries, and on the WordPress side as well -- like adding retries for resizes -- since this ticket was created, which likely have helped, too.

Because it's such a mix of issues, I think it's probably best to close this ticket, and open new ones for any new or more specific issues.

#133 @joedolson
2 months ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

Given the above comments, closing this issue. It seems like it's largely resolved, but the causes are so complex that any future similar issues should be treated as new issues.

Note: See TracTickets for help on using tickets.