Upload issues with imagick and WordPress
Hi guys,
We just installed imagick on all our servers beacause WordPress displays and "error" under "Site health", that says that imagick should be installed. Many of our clients have noticted this, and thus we have installed it.
However, imagick is not working well with LiteSpeed webserver, and our customers are now getting image upload-errors like described here:
However, getting our customers to edit their fuctions.php file is not a great solution.
So my questions is, if anyone in here have found a host-side fix besides just not using imagick?
Thanks!
-
Did you also try the other 2 suggestions? 0 -
Did you also try the other 2 suggestions?
Yes - we tried using a test-user with plenty of memory and the same error happend. Upload folder also has correct permissions, as other smaller images can be uploaded without any issues.0 -
We also just discovered now that imagick is also leaving large temp files when it fails, like described here: ImageMagick creates huge temporary files " Issue #395 " ImageMagick/ImageMagick So everything now points in the direction of just disabeling imagick again. 0 -
LiteSpeed has a setting in the WebConsole to limit the amount of allocated memory PHP can consume, there's a soft and a hard memory limit defined on the web server level ( I believe the default is about 2 gigabyte ), Apache doesn't have such feature, thus it does not appear as an issue in Apache environment (unless you're short on memory). Imagick is known (sadly) for being one big memory leak, I've managed to make a 300 kilobyte PNG image consume more than 4 gigabytes consumed (and more than 10 gigabytes allocated), simply by using the Media Library in WordPress. Since LiteSpeed does protect against this, that can cause broken uploads, and thus generating huge temp files (and sometimes Imagick just crashes slightly internally without actually cleaning out the temp files, even if it's successful at the upload). My advise is to simply keep Imagick disabled and use the GD Library as the "standard", and those who needs PDF previews generated can get the module explicitly enabled, you can do this per user by using: LS_EXTAPP_ENV PHP_INI_SCAN_DIR=/opt/cpanel/ea-php73/root/etc/php.d:/home/$user/
In the Apache user includes (remember both for SSL and STD directories). Alternatively, there's a WP plugin to use the imagick binary in WordPress and not relying on the actual PHP Module - it still suffers from the leaks, despite they're less frequent. And ideally check if there's an existing case for WP to not actually list Imagick as being a strict requirement, because it's silly :)0 -
I'd like to see if our analysts can look over this further for you. Can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved. Thanks! 0 -
Hi Lucas, Thank you very much for your great reply. We have also come to the conclusion, that we need to deactivate imagick and rely on GD instead. Even though WordPress recommends the module under "site health", it simply produces way more errors/issues than it resolves, and thus is not worth the trouble - not for us as a host, not for our clients. We will keep it deactivated untill imagick gets the bug fixed. Thanks again for your time! 0
Please sign in to leave a comment.
Comments
6 comments