Unix and Linux network configuration. Multiple network interfaces. Bridged NICs. High-availability network configurations.


Reviews of latest Unix and Linux software. Helpful tips for application support admins. Automating application support.


Disk partitioning, filesystems, directories, and files. Volume management, logical volumes, HA filesystems. Backups and disaster recovery.


Distributed server monitoring. Server performance and capacity planning. Monitoring applications, network status and user activity.

Commands & Shells

Cool Unix shell commands and options. Command-line tools and application. Things every Unix sysadmin needs to know.

Home » Featured, WordPress

WordPress: Post-processing of the image failed

Submitted by on November 6, 2021 – 11:59 am

This particular WordPress issue appeared with version 5.3 and is refusing to go away. However, the problem here is not with WordPress but with the Apache ModSecurity. The particular ModSecurity rule in question is 200003 that’s been giving webmasters a headache for half a decade now.

The specific WordPress error in question is:

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.

You will find this error message inside wp-includes/script-loader.php:

860:            'http_error_image'          => __( '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.' ),

Truth be told, this error has very little to do with server resources or the image size (as long as the image size is within your WordPress and PHP limits). This error is chiefly a result of sloppy coding.

Looking further for http_error_image, you will spot it in these two files:

440:                    wpQueueError( pluploadL10n.http_error_image );
449:                    wpQueueError( pluploadL10n.http_error_image );
476:                            wpQueueError( pluploadL10n.http_error_image );
509:                            wpQueueError( message || pluploadL10n.http_error_image );
518:                    wpQueueError( pluploadL10n.http_error_image );

126:                            error( pluploadL10n.http_error_image, data, file, 'no-retry' );
135:                            error( pluploadL10n.http_error_image, data, file, 'no-retry' );
479:                            return pluploadL10n.http_error_image;

The clue to the error’s cause can be found in wp-includes/js/plupload/wp-plupload.js:

* Attempt to create image sub-sizes when an image was uploaded successfully
* but the server responded with HTTP 5xx error.

 if ( ! data || ! data.responseHeaders ) {
  error( pluploadL10n.http_error_image, data, file, 'no-retry' );

So it’s a 5xx error coming from the Web server. Checking the Apache logs, you will see these errors that coincide in time with your failed file upload attempts:

[Fri Feb 26 09:25:12 2021] [error] [client] ModSecurity: Access denied with code 44 (phase 2). 
Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [file "/etc/httpd/conf.d/mod_security.conf"] 
[line "39"] [id "200003"] [msg "Multipart parser detected a possible unmatched boundary."] [hostname ""] 
[uri "/wp-admin/async-upload.php"] [unique_id "YDkEyMCoeokAAAZ@JKsAAAAj"]

Open the specified location of the mod_security.conf file (/etc/httpd/conf.d/mod_security.conf in my case) and add the SecRuleRemoveById 200003 line to the end of the </IfModule> section.

Restart Apache and you should be good to go. How bad is this for your server’s security? Probably not too bad: this particular rule is known to be buggy and its value is questionable at best.

Print Friendly, PDF & Email

Leave a Reply