I ran into this after installing Imagify and running up to my monthly limit… upped my limit and it ‘fixed’ this error.
So here’s how I fixed it for me… I looked at the apache 2 logs and saw this:
[Wed Nov 25 00:19:13.470404 2020] [ssl:error] [pid 24259] [client 192.88.135.12:27703] AH02018: request body exceeds maximum size (131072) for SSL buffer, referer: https://www.website.com/wp-admin/upload.php
[Wed Nov 25 00:19:13.470454 2020] [ssl:error] [pid 24259] [client 192.88.135.12:27703] AH02257: could not buffer message body to allow SSL renegotiation to proceed, referer: https://www.website.com/wp-admin/upload.php
So all I did to fix it was put a .htaccess file in the /wp-admin/ folder and only put in one line
SSLRenegBufferSize 10486000
And that fixed it for me.
-
This reply was modified 4 years, 5 months ago by
agcowboy.
Increasing php max_execution_time worked for me.
had the same error … but was on nginx instead of apache
had ” client intended to send too large body” in the nginx error logs.
increasing the client body size in the nginx.conf fixed it for me
client_max_body_size 32M;
https://www.cyberciti.biz/faq/fix-client-intended-to-send-too-large-body-xyz-bytes-in-nginx/
This problem can also appear if you are adding media to a new page or post and haven’t saved it as a draft yet (or recently). Save the draft and then try to upload the media again and attach it to the page or post.
Easiest of all the solutions to try first.
Contacted my host server support and they fixed it.
All they’ve done:
1. Went to php extensions
2. Turned off imagisk add-on
WP_Image_Editor_GD was conflicting with the add-on.
I just wanted to confirm that I had the same problem, and that the solution was to remove the ‘ character from the filename.
As stated before, the error is likely not a processing error on the side of WP. Check for Apache/Nginx error log. In my case, despite the php.ini allowing the specified upload size, my nginx.conf was missing ‘client_max_body_size 32M;’
I faced this issue for some days, In the 99% of cases it is not a library problem or a WordPress fault, but it’s that your hosting is throttling the CPU time and load.
For example, if Plesk is your Hosting admin panel, you can verify this in “Domain and Web sites” -> “Resource usage” and you can see the number of times the process failed because of too much CPU time or laod used.
Some providers set very lowCPU usage limits to push you to upgrade to a more expensive plan.
To verify I just put WordPress in a VPS using same settings and all is working fine, without adding any row to functions.php or disabling Imagick etc…
-
This reply was modified 4 years, 3 months ago by
cpolisini.
What is the difference between these two lines
add_filter( 'wp_image_editors', function() { return array( 'WP_Image_Editor_GD' ); } );
function use_gd_editor($array) {return array( 'WP_Image_Editor_GD', );} add_filter( 'wp_image_editors', 'use_gd_editor' )
I did notice in the thread that some use ‘ while others use the other bracket.
ps… I’ve tried practically everything here and none have resolved the issue.
The two lines are equivalent, the first does in one statement what the second does in two.
If you tried all, it is very likely that you are using a shared host and you provider is throttling the operations of your WordPress app.
-
This reply was modified 4 years, 3 months ago by
cpolisini.
@cpolisini , I manage the Azure Web app. I currently have 1 live site with a projected 170-300 sites.
When I upload an image, the servers spike for minutes and bogs the site down to a crawl. I get hundreds of http 5xx errors a day.
My fault but, this all started when that one site wanted to go live so I updated -everything- in mid Dec. WordPress version, PHP, HTTP2, plugins.
The install was fresh from Sept.
@rokoko00 This solved the issue partialy since my .gif images don’t create any error but they are now static. What a paine.