MySQL extension missing

[Hany28]

Hi,

Suddenly I got this message after cpanel update:-

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

I rebuild Apache and php and I'm sure mysql is exist but not sure why sites have this issue!!


Regards


Hany

 

[grindlay]

I have the same issue, but only on one site. I uploaded a phpinfo() file and it seems to confirm that it's missing, but just for that site. Investigations continue..

 

[cPanelMichael]

Hello,

Could you verify if you are using EasyApache 4? If so, note that custom "suPHP_ConfigPath" values in the .htaccess file within an account's document root will prevent the reading of .ini files within /opt/cpanel/ea-php$version/root/etc/php.d/. Thus, the modules enabled in those .ini files are not loaded. Internal case EA-4772 aims to address this issue by disabling the "suPHP_ConfigPath" values in the .htaccess files during the migration to EasyApache 4. The workaround to this issue if you have already migrated to EasyApache 4 is to manually remove the "suPHP_ConfigPath" value in the .htaccess file of the affected account.

Thank you.

 

[JacobPerkins]

Hi,

Yep, the thing with suPHP_ConfigPath is that it now prevents reading php.d from loading. This allows your users to 100% customize their PHP operating environment and configuration, but it also means that no extra modules are loaded from the global / system PHP. Thus, they need a 100% *full* INI to properly operate. This means they need to load mysqlnd.so or PDO directly in their INI files.

Another work around to keep them using their local php.ini is to back it up, and give them an EA4 INI:

#[~]cat /opt/cpanel/ea-php70/root/etc/php.ini /opt/cpanel/ea-php70/root/etc/php.d/*.ini > /home/user/public_html/ini

This will give them a 100% working copy of the global configuration, and they can configure it appropriately through either the UIs inside cPanel or manually via ftp/ssh.

As Michael stated, we're going to add something to the migration script to comment out suPHP_ConfigPath so sites load, and we'll alert the administrator of the users / document roots they need to fix. We'll also be adding some UI elements in the MultiPHP INI Editor to assist in getting users a 100% clone of the system configuration so they can start in a great place.

I hope this helps!

 

[fuzzylogic]

I can add some detail that may help some people with this problem.
I have this problem on all my WordPress sites.
I am using EasyApache 4, SuPHP and the WordPress Plugin WordFence's Firewall option.
WordFence writes a suPHP_ConfigPath to .htaccess when the firewall is enabled.
Unfortunately without mysql connection the WordPress backend cannot be accessed to disable the firewall.
If the suPHP_ConfigPath is commented out in the .htaccess file the server returns 500 error for all pages.
If the # Wordfence WAF block is deleted from the .htaccess then normal server function is restored.
WordFence firewall should then be disabled from within the WordPress backend.

I will post this issue to the makers of WordFence once I complete fixing all my sites.

 

[grindlay]

Thanks for all the replies. Makes sense as I thought I'd removed all my suPHP_config directives but clearly not.
Also, didn't realise that Wordfence could re-instate them - I use Wordfence on a lot of WP sites.

 

[NOC_Serverpoint]

Hello,

Can you please confirm whether the issue is resolved?

The default PHP settings are not read to the website's wp settings and that's the root cause of the issue. Was the issue resolved by disabling the suPHP settings for the account?

 

[cPanelMichael]

The default PHP settings are not read to the website's wp settings and that's the root cause of the issue. Was the issue resolved by disabling the suPHP settings for the account?

Yes, multiple reports of this issue were addressed by the workaround referenced in this thread.

Thank you.

 

[Jimison]

I don't think this has been address by the Wordfence developer, I saw somewhere else, someone else had this issue as of yesterday. My question (which admittedly is a Wordfence question, and probably a bit noobish, but this thread is a highly appropriate place for it) does "WordFence firewall should then be disabled from within the WordPress backend." mean that if you have enabled any part of the Wordfence firewall, or the extended firewall, that makes you download an .htaccess backup first cause this issue? And are you saying just disabling the firewall, but still leaving plugin installed, before you run EA upgrade allow things to go through no problem?

If that is the case, then how about after the EA4 upgrade is completed, everything works all good with WF disabled, what happens when it is re-enabled? Would appreciate learning from others experience, rather than the hard way

 

[cPanelMichael]

Hello @Jimison,

What version of WordFence are you using? It's supposed to be addressed as of WordFence version 6.1.9 per this thread:

Topic: Your PHP installation appears to be missing the MySQL extension which is require « WordPress.org Forums

The developer of this application accepts support requests at:

View: Plugin Support « WordPress.org Forums

Thank you.

 

[Jimison]

I guess that is addressed, but it looks like it requires some manual intervention. I have latest version, that thread says you need to disable and renable the extended protection in order to get rid of the offending code. Haven't verified this myself yet. I will report back to further verify the solution

 

[nisamudeen97]

Hi,

This thread has helped me to resolve the case. We have recently moved from easyapache 3 to easypache4 and custom suphp rules in php.ini which was there while easyapache3 was being used found causing the error for us. Once the suphp custom ini rule is disabled in .htaccess disabled it worked good.

 

[uk01]

Hi we just had this issue, the migration script modification discussed in 2016 earlier in this thread was not implemented it does not alert you to this suPHP_ConfigPath issue, I had to spend 2 hours until I found this thread and removed it from one users htaccess.
The question now is, are that users php.ini settings not loaded? There are plugins in wordpress which required modules to be activated via php.ini such as extension=imagick.so

 

[cPanelMichael]

The question now is, are that users php.ini settings not loaded? There are plugins in wordpress which required modules to be activated via php.ini such as extension=imagick.so

Hello,

This thread provides some information about how php.ini files are managed in newer versions of cPanel:

Custom php.ini question

Thank you.

 

[uk01]

thanks, I discovered in the end that cpanel now writes .user.ini and php.ini the same and they work without suPHP_ConfigPath in htaccess.