If you use Imsanity and decide the compression doesn’t look good can you go back to the way the images looked originally? Or do you have to upload new images?
if image is uploaded following the error message, only one original image is uploaded without Imsanity resize. It doesn’t always show in the media library, and when it does, it shows a blank image, although the image is fine when you examine via sftp. Yes the way round it, is to delete from sftp and then upload manually resized image.
I’m seeing that behaviour too occasionally. It’s definitely down to the upload process exhausting memory as I always get a corresponding Apache error log like:
1215: PHP Fatal error: Out of memory (allocated 209977344) (tried to allocate 13824 bytes) in /home/sites/xxxxxxx/public_html/wp-includes/class-wp-image-editor-gd.php on line 329: /home/sites/xxxxxxx/public_html/wp-admin/async-up
I’ve contacted our host (HEART in UK) who have bumped up our php.ini files as follows:
max_input_vars = 2000; Allows more than 90 menu items
max_execution_time = 3000; Maximum execution time of each script, in seconds
max_input_time = 300; Maximum amount of time each script may spend parsing request data
memory_limit = 512M; Maximum amount of memory a script may consume
file_uploads = on; Whether to allow HTTP file uploads
upload_max_filesize = 100M; Maximum allowed size for uploaded files
post_max_size = 100M; Maximum size of POST data that PHP will accept
Which are some quite hefty settings allow for shared, but files with dimensions of ~4000 x 6000 px still get the HTTP Error. I’ve advised client to resize with Photoshop online rather than implementing something like Upload from Server where the upload bit it done via FTP
Thanks dozza, that would explain it since the sites in question are on shared hosting.
@androweb Pleasure, and it might be that Jetpack is not so much conflicting, but using too much of the available php memory?