Resolved WordPress Toolkit: Broken Website

[IgorG]

I'm not very practical on the subject but I'd like to ask you if you think it's complicated to switch from CloudLinux7.7 to CentOS7... just to understand whether to make this request to my hosting provider right now or wait for CentOS8 with an installation from scratch. Thanks.

I would wait until we finish work on CentOS8 support. After that, you will be able to migrate your Plesk.

 

[MicheleB]

The fix is planned for WPT 4.6.0 version.
And yes, CloudLinux is supported but not a priority.

... and another week has gone.
Now I know what "Critical bug" means to Plesk.

OT: I suggest you to remove CloudLinux from the "Supported Operating Systems" for Plesk, so that a new Plesk's customer immediately understands that if there's a problem with this operating system its solution will have a different priority than Ubuntu/CentOS.

 

[Baybora]

Hello,

I'm experiencing a similar issue. Two broken wordpress installations according to Wordpress Toolkit.

Both sites work fine.

CentOS 7
Plesk 18.0.24
LiteSpeed Web Server 5.4.5
PHP 5.6.40 (FastCGI Application)



I noticed these errors from Application Updates email. There has been a server migration recently.

Error details:
Failed to reset cache for the instance #114: Your PHP installation appears to be missing the MySQL extension which is required by WordPress.
The site is experiencing technical difficulties.

Regards

 

[MicheleB]

CentOS 7
Plesk 18.0.24
LiteSpeed Web Server 5.4.5
PHP 5.6.40 (FastCGI Application)

Error details:
Failed to reset cache for the instance #114: Your PHP installation appears to be missing the MySQL extension which is required by WordPress.
The site is experiencing technical difficulties.

It would seem a different problem than mine (Mod_lsapi) but I think that having you an operating system supported by Plesk (CentOS) you can get better and faster support (for me today is 21 days of waiting...).

 

[Baybora]

Actually, you might be right. I fixed the problem.

At first try, this command did not change anything:

plesk ext wp-toolkit --clear-cache -instance-id <id>

Then I changed the PHP handler, and switched back to the previous one (FastCGI). Then I changed the domain names from the WP settings, saved the options, and reverted back.

Second time I gave a try with the command, It took a few seconds to proceed and successfully cleared the cache.

No broken web sites in Wordpress Toolkit anymore.

I hope you can find a solution, too.

 

[MicheleB]

I hope you can find a solution, too.

I'm happy for you.
Unfortunately for me it's necessary to wait for WPT 4.6.0, as long as the Plesk Staff remembered to fix it after a long time... unfortunately switching from Debian to CloudLinux was not a happy choice.

 

[MicheleB]

Any news about this bug from the Plesk Team?

 

[custer]

Hi @MicheleB,


The good news is that based on our investigation you can actually fix this problem right away without having to wait for someone or something. The bad news is that this problem is caused by CageFS, not by WordPress Toolkit, so there's not much we can do at the moment.

Here's the gist of the problem: MySQL connections to the database server are established either over a socket (if localhost is used as a connection setting), or over TCP/IP (if IP address like 127.0.0.1 is used as a connection setting). Everything works fine (as usual) until CageFS starts to restrict access to the socket file's path, and connection cannot be made.


In practical terms, you have two options:

1. Put 127.0.0.1 instead of localhost in the wp-config.php file, where database server info is provided. Typically, it looks like this:

/** MySQL hostname */
define( 'DB_HOST', 'localhost:3306' );

You'll need to do this for each WordPress site, including new installations.


2. Add MySQL socket to /etc/cagefs/cagefs.mp and remount CageFS

You can find your socket in your /etc/my.cnf file, for example:

[mysqld]
bind-address = ::ffff:127.0.0.1
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

The /var/lib/mysql/mysql.sock is the socket file you're looking for. Add its directory (/var/lib/mysql) to /etc/cagefs/cagefs.mp file and remount СageFS with the following command:

cagefsctl --remount-all

Important: option 2 does not seem to be as secure as option 1, but it fixes the issue for all existing and new WordPress sites.


We do not know why CageFS has restricted access to MySQL socket file, and we do not know if it's an isolated case or it's a global configuration change affecting many customers, so we're not sure what to do with this. You might ask CloudLinux guys about this change, maybe they can provide more information.


Hope this helps.

 

[MicheleB]

Hi @MicheleB,


The good news is that based on our investigation you can actually fix this problem right away without having to wait for someone or something. The bad news is that this problem is caused by CageFS, not by WordPress Toolkit, so there's not much we can do at the moment.

Here's the gist of the problem: MySQL connections to the database server are established either over a socket (if localhost is used as a connection setting), or over TCP/IP (if IP address like 127.0.0.1 is used as a connection setting). Everything works fine (as usual) until CageFS starts to restrict access to the socket file's path, and connection cannot be made.


In practical terms, you have two options:

1. Put 127.0.0.1 instead of localhost in the wp-config.php file, where database server info is provided. Typically, it looks like this:

/** MySQL hostname */
define( 'DB_HOST', 'localhost:3306' );

You'll need to do this for each WordPress site, including new installations.


2. Add MySQL socket to /etc/cagefs/cagefs.mp and remount CageFS

You can find your socket in your /etc/my.cnf file, for example:

[mysqld]
bind-address = ::ffff:127.0.0.1
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

The /var/lib/mysql/mysql.sock is the socket file you're looking for. Add its directory (/var/lib/mysql) to /etc/cagefs/cagefs.mp file and remount СageFS with the following command:

cagefsctl --remount-all

Important: option 2 does not seem to be as secure as option 1, but it fixes the issue for all existing and new WordPress sites.


We do not know why CageFS has restricted access to MySQL socket file, and we do not know if it's an isolated case or it's a global configuration change affecting many customers, so we're not sure what to do with this. You might ask CloudLinux guys about this change, maybe they can provide more information.


Hope this helps.

Thanks but...

the first option is only limited to the existing installations (with any WordPress removal procedure impossible to perform).
For the new installations I should always switch from PHP-FPM to LSPHP, which is obviously unmanageable.

the second option is that confirmed from the CloudLinux's support but obviously it requires an in-depth phase of analysis to avoid problems with other applications, so I still have to decide how to proceed.

However, CloudLinux technical support told me that the fix is planned for WPT 4.6.0 version.
Is it correct? Can you confirm that? When 4.6.0 will be available?

 

[custer]

@MicheleB

However, CloudLinux technical support told me that the fix is planned for WPT 4.6.0 version.
Is it correct? Can you confirm that? When 4.6.0 will be available?

WPT 4.6.0 will be published later today. However, it will not include the fix for this bug, because, as I've stated earlier, there's not much we can do with this right now -- the issue is with CageFS behavior, which is out of our control at the moment. We will try reaching out to the CloudLinux team to figure out together the best course of action.

 

[MicheleB]

@MicheleB
WPT 4.6.0 will be published later today. However, it will not include the fix for this bug, because, as I've stated earlier, there's not much we can do with this right now -- the issue is with CageFS behavior, which is out of our control at the moment. We will try reaching out to the CloudLinux team to figure out together the best course of action.

Ok, thanks.
Unfortunately I realized that there are big communication problems between you and CloudLinux support.

 

[dudley1379]

Ok, thanks.
Unfortunately I realized that there are big communication problems between you and CloudLinux support MyPrepaidCenter

ya thats right sir. but what can we do now.

 

[MicheleB]

ya thats right sir. but what can we do now.

The bug will be fixed with the release 5.0 of WPT:

Wordpress Toolkit does not operate properly on Cloudlinux server with alt-php

Applicable to: Plesk for Linux Symptoms Plesk installed on a server with Cloud Linux and alt-php is used in Domains > example.com > PHP settings; On attempt to install WordPress via Wo...

support.plesk.com

 

[MicheleB]

I don't know how many people use mod_Isapi on their server with Plesk (I suppose few) but as said from Plesk Team (Yulia Plokhotnikova) in one reply of above article, we have to except a long time before this "critical" bug is fixed, only with the mayor release 5.0 and with almost three/four minor release before (4.7/4.8/4.9).
The good news is that CloudLinux Team has already found and reported the bug to the Plesk Team (a bug in WordPress Toolkit) but I don't understand because we have to wait so long.

 

[MMagnani]

I don't know if this information is helpful, but one of our instances had the same problem.

# plesk ext wp-toolkit --clear-cache -instance-id 67 [2020-04-29 11:01:35.523] ERR [extension/wp-toolkit] An error has occurred when decoding JSON by Zend_Json: Decoding failed: Syntax error [2020-04-29 11:01:35.534] ERR [extension/wp-toolkit] Failed to reset cache for the instance #67, reason: An error has occurred when decoding JSON: Decoding failed: Syntax error Failed to reset cache for the instance #67: An error has occurred when decoding JSON: Decoding failed: Syntax error exit status 3

When Indeed Coming Soon plugin is disabled, we get expected results:

# plesk ext wp-toolkit --clear-cache -instance-id 67 The cache of the selected WordPress installations was cleared.

Additionally, wp-toolkit can NOT disable the plugin.

Ubuntu 18.04.4 LTS‬,
Plesk Onyx Version 17.8.11 Update #85,
WordPress Toolkit Version 4.7.1-3439.
PHP version does not change results.

 

[MicheleB]

Is there any chance of seeing this critical bug fixed before of the major release 5?
Now we're only to the 4.7 so I think that the 5 version will not arrive before the end of the year and I need to restore urgently mod_Isapi on my CloudLinux server (also for the WebP support that is not available in the Plesk PHP packages).
The instructions to fix the bug are already sent you from the CloudLinux Team on 22 March.

 

[MicheleB]

I noticed that the reference to the WPT 5 version has disappeared (Wordpress Toolkit does not operate properly on Cloudlinux server with alt-php)... someone from Plesk Team could tell me when this damn problem will be definitely solved?

 

[MicheleB]

Using the Plesk's workaround the issue is fixed (I added "pdo_mysql.so" because WordPress requires it and it's disabled like the other two):
extension=json.so
extension=mysqli.so
extension=pdo_mysql.so

Very important, is necessary to disable them on the "PHP selector" for each hosting to avoid PHP errors as "Module 'mysqli' already loaded at Unknown#0".

Anyway, I hope that in the future Cloudlinux will be more integrated with Plesk because these workarounds don't convince me too much, especially when we will have to update the PHP handler, Plesk and CL(8).

 

[pleskuser8m]

I am installed Plesk on a clean install of CloudLinux Server, not Minimal package and use the LVE Manager Wizard to config & setup PHP, MySQL Governor, CageFS, mod_lsapi PRO to make these packages installed properly. I was trying to manualy install these packages but i got many miss-configurations, its all working fine now except this issues. The last build of my server, json extension showing up in Plesk PHP Settings, but mysqli and pdo_mysql still unavailable. In /opt/alt/phpXX/usr/lib64/php/modules/ mysqli.so and pdo_mysql.so are just two symlinks, is this cause the problem?

 

[SKristich]

I am installed Plesk on a clean install of CloudLinux Server, not Minimal package and use the LVE Manager Wizard to config & setup PHP, MySQL Governor, CageFS, mod_lsapi PRO to make these packages installed properly. I was trying to manualy install these packages but i got many miss-configurations, its all working fine now except this issues. The last build of my server, json extension showing up in Plesk PHP Settings, but mysqli and pdo_mysql still unavailable. In /opt/alt/phpXX/usr/lib64/php/modules/ mysqli.so and pdo_mysql.so are just two symlinks, is this cause the problem?

Hello,
Could you please provide more information and attach PHPinfo. Thank you