WP fails to recognize and use Imagick PHP 8 module on OpenLiteSpeed / Litespeed Web Server

[luboslives]

Hi, I've made a ticket with the LiteSpeed people but they insist that their version of PHP (LSPHP) is a like-for-like copy of the PHP binaries, only hosted in their own repos. So it seems this error may be on the WordPress side.

I'll first refer you to this support thread to show I'm not the only one with this problem: ​https://wordpress.org/support/topic/imagick-module-recognized-but-not-used/

In short, WordPress does not recognize the Imagick module in LSPHP 8, so it will not use it and defaults to WP_Image_Editor_GD as its image editor. It has no problems detecting and using it in an Apache environment where I used PHP 8 from the CentOS repos. It also has no problem using the LSPHP 7.4 version either.

Here's a breakdown of the results:

Apache 2.4.37 with PHP 8.0.14
Custom Image Processing with WP_Image_Editor_Imagick = Success
ImageMagick version number = 1692
ImageMagick version string = ImageMagick 6.9.12-34 Q16 x86_64 2021-12-22
Imagick version = 3.7.0

OpenLiteSpeed 1.7.14 with LSPHP 7.4.26
Custom Image Processing with WP_Image_Editor_Imagick = Success
ImageMagick version number = 1690
ImageMagick version string = ImageMagick 6.9.10-86 Q16 x86_64 2020-01-13
Imagick version = 3.4.4

OpenLiteSpeed 1.7.14 with LSPHP 8.0.12
Custom Image Processing with WP_Image_Editor_Imagick = Error (see notes*)
ImageMagick version number = 1690
ImageMagick version string = ImageMagick 6.9.10-86 Q16 x86_64 2020-01-13
Imagick version = @PACKAGE_VERSION@

*Notes: Active editor is listed as WP_Image_Editor_GD. WordPress fails to recognize and use the Imagick extension. Custom image processing fails as it tries to run Imagick methods through the GD class.

All environments are running on Rocky Linux release 8.5.

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the report.

Replying to luboslives:

OpenLiteSpeed 1.7.14 with LSPHP 8.0.12
Custom Image Processing with WP_Image_Editor_Imagick = Error (see notes*)
ImageMagick version number = 1690
ImageMagick version string = ImageMagick 6.9.10-86 Q16 x86_64 2020-01-13
Imagick version = @PACKAGE_VERSION@

The @PACKAGE_VERSION@ string is likely the culprit here. WordPress currently supports Imagick 2.2.0 or higher, see [22904] / #22308. If the version is reported as @PACKAGE_VERSION@ instead of the correct number, that does not pass the version_compare() check in WP_Image_Editor_Imagick::test()​.

[luboslives]

Replying to SergeyBiryukov:

The @PACKAGE_VERSION@ string is likely the culprit here. WordPress currently supports Imagick 2.2.0 or higher, see [22904] / #22308. If the version is reported as @PACKAGE_VERSION@ instead of the correct number, that does not pass the version_compare() check in WP_Image_Editor_Imagick::test()​.

Thanks Sergey, I've been reading through imagick github issues and it seems that having an unsigned package version is not an uncommon bug.

Maybe I will take this back to LiteSpeed support to see if they can ship an updated version in their repos, because it looks like there's a chain of compatibility that has to be maintained between the version of PHP, the module version (hopefully signed correctly), and the ImageMagick binaries themselves.

On first glance it looks like anything over PHP 8.X requires imagick module >= 3.5, which itself may require ImageMagick >= 7.X ...or it may not, according to more changelogs I'm reading.

[ddegner]

Thanks for looking @SergeyBiryukov. The string issue might be part of the problem, but this bug still existed back when the "Site Health" info showed the correct string and I posted it here:
​https://wordpress.org/support/topic/imagick-module-recognized-but-not-used/

This bug still exists for me even after updating wordpress, litespeed, and php. So I'll share my info here in the hopes that it helps track down the bug.

Wordpress 5.9

Active editor WP_Image_Editor_GD
ImageMagick version number 1690
ImageMagick version string ImageMagick 6.9.10-23 Q16 x86_64 20190101 ​https://imagemagick.org
Imagick version @PACKAGE_VERSION@

Server architecture Linux 5.4.0-96-generic x86_64
Web server LiteSpeed
PHP version 8.0.14 (Supports 64bit values)
PHP SAPI litespeed

[luboslives]

Replying to ddegner:

I have an open ticket with LiteSpeed support where I've detailed what I dug up. They have their LSPHP guy looking into it but said it could take a while.

According to your old report and my dnf uninstall, their version of the imagick module is 3.4.4, but only module 3.5+ supports PHP 8. They'll need to update it in their repo and make sure it's signed with the version number.

In the meantime, what I've done, and what you can do is install PHP from the remi repository (if you're on a RHEL/CentOS distribution). You'll need to specify the modules you need as well as the -php-litespeed module.

If you haven't installed remi repo:

dnf install http://rpms.remirepo.net/enterprise/remi-release-8.rpm

Edit /etc/yum.repos.d/remi.repo and set enabled=1 so you don't have to specify dnf --enablerepo=remi every time you want to update the installation.

Here's everything I install for a WordPress site:

dnf install php80 php80-php-bcmath php80-php-common php80-php-gd php80-php-gmp php80-php-imap php80-php-intl php80-php-litespeed php80-php-mbstring php80-php-mysqlnd php80-php-pdo php80-php-pecl-imagick-im6 php80-php-process php80-php-soap php80-php-sodium php80-php-xml php80-php-pecl-zip

Note that remi has different versions of the imagick module available, for the version of Image Magick you have installed on your system. Since the CentOS repos don't have v7 yet, I used php80-php-pecl-imagick-im6 here.

Next, all you need to do is change your external app in your server config. Edit lsphp80, and the only thing you need change is the Command field to /usr/bin/lsphp80. Restart the server and your Site Health report should come out clean with the latest version of the module.

I'll post here if I hear anything from LiteSpeed support.

[luboslives]

I should add, if you're not going through the command line but instead using a panel like cPanel to manage your web server, support suggested to install the latest versions of PHP and the modules through the panel and to use those instead of the ones in their repo.

[ddegner]

Thanks for all that info. It's comforting to know that someone else has a similar problem and has found a solution. Unfortunately none of your solutions seem to be working with me.

I'm running Ubuntu, and just using the command line. I have php8.1 installed but haven't figured out how to make cyberpanel give me 8.1 as an option. I'll do more searching and hope it eventually resolves itself.

[luboslives]

Replying to ddegner:

I have php8.1 installed but haven't figured out how to make cyberpanel give me 8.1 as an option. I'll do more searching and hope it eventually resolves itself.

Just a heads up, it seems WordPress and most plugins aren't quite ready for 8.1 yet. I gave it a shot with a debugging plugin installed and I get dozens of warnings on each page load, mostly about deprecated calls. Maybe stick to 8.0 for now.

[SergeyBiryukov]

Replying to luboslives:

Just a heads up, it seems WordPress and most plugins aren't quite ready for 8.1 yet.

Right, WordPress core is not fully compatible with PHP 8.1 yet. See ​WordPress 5.9 and PHP 8.0-8.1 for more details.

The progress is being tracked in #54730 and other, more specific tickets with the php81 keyword.