• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved WordPress Toolkit: Broken Website

MicheleB said:
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.
Click to expand...
I would wait until we finish work on CentOS8 support. After that, you will be able to migrate your Plesk.
 
IgorG said:
The fix is planned for WPT 4.6.0 version.
And yes, CloudLinux is supported but not a priority.
Click to expand...

... 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.
 
Last edited:
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)

1582810681780.png

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
 
Baybora said:
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.
Click to expand...

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...).
 
Actually, you might be right. I fixed the problem.

At first try, this command did not change anything:
Code: 
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.
 
Baybora said:
I hope you can find a solution, too.
Click to expand...

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.
 
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:

Code: 
/** 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:

Code: 
[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:

Code: 
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.
 
custer said:
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:

Code: 
/** 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:

Code: 
[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:

Code: 
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.
Click to expand...

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?
 
Last edited:
@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?
Click to expand...

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.
 
custer said:
@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.
Click to expand...

Ok, thanks.
Unfortunately I realized that there are big communication problems between you and CloudLinux support.
 
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.
 
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.
 
Last edited:
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.
 
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).
 
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?
 
pleskuser8m said:
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?
Click to expand...
Hello,
Could you please provide more information and attach PHPinfo. Thank you
 
You must log in or register to reply here.

Similar threads

Dmytro
Issue Error establishing a database connection [Cloud Linux, Alt-PHP]
Replies
17
Views
3K
Dmytro
Dmytro
E
Resolved wordpress-toolkit error during backup
Replies
1
Views
460
easyware
E
G
Resolved WP Toolkit setup new password for admin haystack (language) error
Replies
1
Views
640
gmu-jerdj
G
N
Multisite redirection issue
Replies
8
Views
959
Next level web
N
K
Issue Wordpress Toolkit: Critical error while checking for updates
Replies
1
Views
321
Martin Dias
Martin Dias
Back
Top