• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Forwarded to devs Wordpress Toolkit incompatible with CLoudlinux CageFS

Daniel Richards

New Pleskian
TITLE:
Wordpress Toolkit incompatible with CLoudlinux CageFS
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Cloudlinux 7.4 & 7.5, Plesk Onyx 17.5 & Plesk Onyx 17.8 PHP 7.0, PHP 7.1, PHP 7.2
PROBLEM DESCRIPTION:
When using Cloudlinux alt-php LSAPI the Wordpress Toolkit stops working. The wordpress installations of domains using alt-php become detached from the wordpress toolkit.

I have reported it to Cloudlinux, they're reply is below - they believe it to be a design issue of the plesk wordpress toolkit causing these problems.


Here's the workaround suggested by cloudlinux until this is fixed:

Code:
find /opt/alt/php72/etc/php.d.all -name '*.ini' -group linksafe -exec cat {} \; >> /opt/alt/php72/link/conf/default.ini

I also need to copy

Code:
mysqli.default_socket = /var/lib/mysql/mysql.sock
into the addition configuration directive section of the PHP Settings for each domain.
To fix the issue with wp-tookit plugin I compared PHP 7.2 extensions for native and alt versions and enabled all missing extensions for alt version via LVE Manager interface. That didn't help because Plesk is running plugin outside of CageFS and therefore alt-php does not load selected extensions. To enable extensions to work outside of CageFS I did the following:
find /opt/alt/php72/etc/php.d.all -name '*.ini' -group linksafe -exec cat {} \; >> /opt/alt/php72/link/conf/default.ini
Now /opt/alt/php72/link/conf/default.ini contains all required extensions and wp-toolkit works fine.

So, the issue was not related to mod_lsapi, it was related to missing extensions when alt-php was running outside of CageFS. This looks like a design issue of wp-toolkit because:
1. Why does Plesk try to run its plugin (wp-toolkit) using PHP version chosen for the website instead of using native PHP version?
2. Why does Plesk try to run it outside of CageFS?
It is better to address these questions to Plesk support
STEPS TO REPRODUCE:
Change PHP from FastCGI by Apache or PHP-FPM to Alt-PHP LSAPI (part of CLoudlinux OS) on a domain

open Wordpress Toolkit for that domain nd click refresh. Plesk Onyx 17.5 then reports a 'Syntax Error' 17.8 reports no error, but in both cases the wordpress installations on that domain become detached, and wordpress toolkit cannot manage wordpress​
ACTUAL RESULT:
Plesk Onyx 17.5 reports a 'Syntax Error' 17.8 reports no error, but in both cases the wordpress installations on that domain become detached, and wordpress toolkit cannot manage wordpress​
EXPECTED RESULT:
The wordpress installation should be able to be managed propertly by wordpress toolkit​
ANY ADDITIONAL INFORMATION:
temporary workaround details included above.
It would be really helpful if the Plesk Team could confirm that this workaround is safe
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
Last edited:
Thank you for detailed feedback. We are working on investigation of this issue. I hope to return to you shortly with a more complex responce
 
Unfortunately I don't have an update regarding your issue yet. I hope to get back to you on Monday with update
 
Why would you use alt-php instead of the native PHP-FPM? It's much faster. We use CloudLinux too but opted not to use alt-php. Just wondering, web host to web host. :)

Good luck on your bugfix.
 
Hi @Laurence@ sorry I forgot to reply. This bug remains unresolved.
We like alt-php mostly for the convenience that is brought by using PHP selector

We started testing mod_lsapi (and alt-php) and the claims they make around performance, reliability, and ease of configuration vs that for PHP-FPM.
First we started without our own performance testing, which was inconclusive, then we progressed to testing mod_lsapi on a few live domains.

Here we noticed an increase in reliability - we've been having a few random PHP-FPM problems (may be related to a PHP bug reported by plesk to PHP here PHP :: Bug #77114 :: php-fpm master segfaults in fpm_event_epoll_wait/fpm_event_fire), mod_lsapi did not trigger these problems. However we quickly noticed this problem with wordpress toolkit.
We also noticed that in real world useage mod_lsapi resulted in a slightly higher performance, and slight reduction on server demand - but this improvement is likely not noticeable for our end-user.

Overall, we are pleased with the potential of mod_lsapi, this bug with wordpress toolkit is our current only barrier to wider rollout.

I hope this is helpful
 
We are also experiencing an issue that this fix by Cloudlinux fixed. It arose on a Wordpress update to 5.2. After update to 5.2, Wordpress toolkit has given a few different errors. The first one is this:
Error: An error has occurred when decoding JSON: Illegal Token
Second Error:
Error: Your server is running PHP version 5.4.16 but WordPress 5.2.1 requires at least 5.6.20


The previous settings for PHP and Cloudlinux were, "LSPHP by Vendor OS"

Implemented the fix above and changed PHP handler to, "LSPHP7.2 alt-php"

Worked. I would also like some confirmation that the fix above is safe, if so I can consider adding it more broadly.

Anyone have any thoughts or additional information?


Sincerely,

Jared

[email protected]
 
Back
Top