Hany28

Registered
Aug 1, 2013
1
0
1
cPanel Access Level
Root Administrator
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
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463
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

Well-Known Member
May 2, 2014
617
97
103
cPanel Access Level
DataCenter Provider
Twitter
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:
Code:
#[~]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!
 
  • Like
Reactions: nisamudeen97

fuzzylogic

Well-Known Member
Nov 8, 2014
154
93
78
cPanel Access Level
Root Administrator
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

Well-Known Member
Dec 8, 2004
58
5
158
Edinburgh, Scotland
cPanel Access Level
Root Administrator
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

Well-Known Member
Jul 3, 2016
103
7
18
cPanel Access Level
Website Owner
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

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463
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

Registered
Feb 17, 2017
2
0
51
Burritoville
cPanel Access Level
Root Administrator
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

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463

Jimison

Registered
Feb 17, 2017
2
0
51
Burritoville
cPanel Access Level
Root Administrator
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

Well-Known Member
Jul 7, 2010
59
5
58
Cochin
cPanel Access Level
Root Administrator
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.
 
  • Like
Reactions: cPanelMichael

uk01

Well-Known Member
Dec 31, 2009
232
35
78
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

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463
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

Well-Known Member
Dec 31, 2009
232
35
78
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.
 
  • Like
Reactions: cPanelMichael