Media Upload Issue Since 4.5 Upgrade

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

Change History (133)

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.

@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.

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.

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!

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!!!!

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?

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.

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

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:

Improve the error message when these failures occur

Find more ways to decrease memory usage during WP_Image_Editor_Imagick::multi_resize()

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

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.

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.

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:

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.

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.

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...

@ 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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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:

@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.

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

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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?

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.

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.

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

@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?

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.

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.

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:

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.

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.