In WordPress 5x, Image uploads frequently fail, and do so with a spurious error message

[toomanyairmiles]

I run my own dedicated server, a dual processor Xeon with 128GB of ram.

When uploading batches of images for sites I'm working on I frequently find one or two images fail with the message 'Post-processing of the image likely failed because the server is busy or does not have enough resources. Uploading a smaller image may help. Suggested maximum size is 2500 pixels.' I have numerous reports from my userbase of the same issue.

• The images that fail are far smaller than the error message suggests would cause an issue. For example my currently problematic image is 1621 x 1000 and a svelte 292kb.

• Imagick 3.3.4 is installed

• Rebooting the server does not make the issue go away.

• There is no issue with resources on the server or resources available to the wordpresses, they all have 512 MB assigned, which should be more than enough.

• Occasionally reuploading the image solves the problem, but this is rare - I've currently been stuck for an hour trying to get one single image into a slider.

• Saving the image as a different kind of JPEG i.e. baseline optimized rather than progressive sometimes seems to work (I suspect this isn't meaningful or indicative of the issue though).

The wider point is this is preposterous, I'm currently trying to upload 15 identically sized, identically produced, images and one single file keeps failing for no fathomable reason.

There is another bug report discussing the content of the message being inaccurate, which it clearly is, but as a wordpress dev/admin I'm encountering this issue multiple times a day and there does not appear to be a rational reason for its occurrence or any reasonable steps a user can take to solve it on their own.

Frankly wordpress 5x seems to dislike certain images for no reason at all.

For the avoidance of doubt this ticket is not about the language of the error message (useless and wrong as it clearly is) it's about the problem that causes it to occur.

[markparnell]

Welcome to trac, @toomanyairmiles and thanks for the report. Have you tried uploading one of the images that consistently fails to a site on another server, and/or a clean WP install with no plugins and just one of the default themes?

If you're at liberty to do so it would probably also be helpful if you were able to upload one of those images here.

The above will all make it easier to narrow down exactly where the issue lies.

[toomanyairmiles]

There appears to be another similar bug in which results in the message below. I have again been battling away with this all day, and it is specific to video/large media, in this case a 3.7Mb webm video.

'Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.'

The issue is max execution time, if I set the max-execution-time in user.ini to a lunatic number, say 100000 the issue with uploading videos goes away. Similarly, the issue with photos also goes away.

As I understand it the default for this setting in php is 30 seconds, my sites use a default of 5 seconds (which is fairly standard/reasonable).

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 5000

I host 40 odd wordpresses and this issue has been occurring with frustrating frequency since the 5x release, and I am finding it occurs on brand-new sites with default themes. It also doesn't appear related to the specific image as best I can tell - it's sporadic but regular enough to result in thrown objects!

Based on today's hacking there is something funky going on with 5x and the way it handles max-execution-time compared to older versions.

Based on stack, my own users and other forums the issue appears widespread.

Replying to markparnell:

Welcome to trac, @toomanyairmiles and thanks for the report. Have you tried uploading one of the images that consistently fails to a site on another server, and/or a clean WP install with no plugins and just one of the default themes?

If you're at liberty to do so it would probably also be helpful if you were able to upload one of those images here.

The above will all make it easier to narrow down exactly where the issue lies.

[codemilitant]

@azaozz I can say that this is not the fault of WordPress, but the fault of default server configurations. My discipline as a server DevOps focuses on Nginx, and when I ran into this problem, my KVM frontend (Nginx KVM) crashed before routing to all my upstream servers. The low default configurations in Nginx, and the default SELinux, were the problem. It's not necessary to crank up the Nginx memory limits to 10M or more, as I've seen posted elsewhere, instead, just disable the client_max_body_size, then update the client_body_buffer_size to a modern configuration for WordPress.

Server: CentOS 7
Kernel: Linux version 3.10.0-1127.8.2.el7.x86_64

Like this:

client_body_buffer_size 1m;
client_max_body_size 0;
Context: http, server, location

As noted here on nginx.org:

Default: client_body_buffer_size 8k|16k;
Default: client_max_body_size 1m;
Context: http, server, location
Setting (client_max_body) size to 0 disables checking of client request body size.

It gets the client request body from:

the maximum allowed size of the client request body, specified in the “Content-Length” request header field.

These server defaults are problematic, and will most likely fail WordPress for most default Nginx configs running this latest version of WordPress since most "Content-Length" for a large file will be considerably more than 1MB. Since images (any media) report a "Content-Length" in the header, this will easily surpass default Nginx configurations, and throw the request into the client_body_temp_path.

In my tests, it doesn't look like WordPress combines multiple image uploads into a single "Content-Length" header, but if I'm mistaken, then this should be corrected to submit each media element in it's own request to ensure "Content-Length" is not unnecessarily overloading the server by combining all media sizes into a single request header.

The second element is SELinux. While most web hosts, depending on the service selected, do not enable SELinux, in my case, I have website clients that routinely pump out over 2 million page views, so I have SELinux enabled (Enforcing) for their safety.

Unfortunately, the default configuration for SELinux does not contain any default policies within the file_contexts for Nginx caching. Whether or not fastcgi_cache, proxy_cache, etc... are enabled, the client_body_temp_path, will be used for memory overruns. By default this is stored in /var/cache/nginx. SELinux does not have a default policy for /var/cache/nginx, so this will result in:

2020/06/11 16:22:29 [crit] 17420#17420: *8041 open() "/var/cache/nginx/client_temp/0000000362" failed (13: Permission denied), client: 192.168.101.100, server: example.com, request: "POST /wp-admin/async-upload.php HTTP/2.0", host: "example.com", referrer: "​https://example.com/wp-admin/media-new.php"

Of course, this will kill the upload and throw either of:

• Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.
• Post-processing of the image failed likely because the server is busy or does not have enough resources. Uploading a smaller image may help. Suggested maximum size is 2500 pixels.

To fix the default SELinux, do the following as root:

# Configure Nginx cache for new WordPress media upload
semanage fcontext -a -t httpd_cache_t "/var/cache/nginx/client_temp(/.*)?"
restorecon -R -v /var/cache/nginx/client_temp

Since most webhosts disable SELinux for shared hosting, this is not an issue, and you shouldn't encouter many issues. However, any VPS or dedicated server could easily run into issues, and throw multiple errors.

Once the new SELinux configs are enabled, the successful response will look like:

2020/06/11 16:48:00 [warn] 17420#17420: *9283 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000485, client: 192.168.101.100, server: example.com, request: "POST /wp-admin/async-upload.php HTTP/2.0", host: "example.com", referrer: "​https://example.com/wp-admin/media-new.php"

If it's not possible to update the SELinux policy, another solution would be to direct the Nginx client_body_temp_path to a folder that already has a proper SELinux policy for processing web server requests.

Something like:

client_body_temp_path /var/www/html/yourdomain/wp-content/client_temp 1 2;
Context: http, server, location

This doesn't have to be the /var/www/ directory, but could be /home/user/public_html/wp-content/client_temp for just about any shared hosting.

Thank you for all the hard work on this new Media Library.