jgidi

Registered
Aug 1, 2016
2
0
1
Michigan
cPanel Access Level
Root Administrator
Hello,

I'm testing out EasyApache 4 on a dev system and noticing an odd behavior change, relative to EA3.

On our production EA3 systems, the system-wide php.ini is in /usr/local/lib/php.ini. Site-specific php.ini files in user home directories work as expected; for example /home/testaccount/public_html/php.ini overrides the system-wide php.ini and all is well.

On my EA4 test system, the system-wide php.ini is /opt/cpanel/ea-php56/root/etc/php.ini, and again, php.ini files in user home directories work as expected.

However, if any changes are made within the MultiPHP INI editor, it triggers the creation of /opt/cpanel/ea-php56/root/etc/php.d/local.ini. At that point, php.ini files within user home directories are no longer honored; it appears that local.ini is the *only* configuration file that is used.

Is this the desired behavior? Is there any way to get site-specific php.ini files to work if local.ini exists?

Thanks for any insight.

Joe
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463
However, if any changes are made within the MultiPHP INI editor, it triggers the creation of /opt/cpanel/ea-php56/root/etc/php.d/local.ini. At that point, php.ini files within user home directories are no longer honored; it appears that local.ini is the *only* configuration file that is used.
Hello,

Currently, you must rename the php.ini file in the user's home directory to ".user.ini". Here's an example on the command line:

Code:
mv /home/$username/public_html/php.ini /home/$username/public_html/.user.ini
Thank you.
 

jgidi

Registered
Aug 1, 2016
2
0
1
Michigan
cPanel Access Level
Root Administrator
Thanks kdean and Michael, I confirmed that I was able to fix this by either renaming the php.ini to .user.ini or by setting user_ini.filename = "php.ini" in local.ini
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463
I'm happy to see the information was helpful. Thank you for updating us with the outcome.
 

Cyber911

Active Member
May 24, 2003
25
0
151
Hi Michael,

do you know if there's a Bugreport / Feature Requests where I could track if the problem about php.ini -> .user.ini gets resolved? Current MultiPHP INI Editor in cPanel (11.58.0.20) still creates php.ini files inside home directories... :)

kind regards

Sven B. 8)
 

orudge

Member
Oct 31, 2004
20
4
153
United Kingdom
I'm experiencing this same issue with EA4 on 11.58.0.20. Renaming php.ini to .user.ini is half a fix - however, according to the PHP documentation, "Only INI settings with the modes PHP_INI_PERDIR and PHP_INI_USER will be recognized in .user.ini-style INI files." So upload_max_filesize can be modified, for instance, but allow_url_fopen cannot (which in this case is the directive that my customer needs enabled).

According to phpinfo(), the local php.ini file is being picked up (via "loaded configuration file"), but I presume all the directives are being overridden by local.ini, as nothing I change seems to make any difference.

In our case, therefore, using a .user.ini (or setting "user_ini.filename = php.ini") is not a valid workaround; is it possible to get back the old behaviour whereby the local php.ini takes precedence? If this is not possible, the "allow_url_fopen" and "allow_url_include" options should be removed from the cPanel-specific MultiPHP Editor.

Thanks,

Owen
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463
Hello,

Here's a quick overview of how this works for anyone else visiting this thread. I'll use PHP 7 in this example, but the same behavior applies to any PHP version in EasyApache 4.

1. By default, no local.ini exists within the /opt/cpanel/ea-php70/root/etc/php.d/ directory.
2. I browse to "WHM Home » Software » MultiPHP INI Editor » Basic Mode ", choose ea-php70, and make a change to a PHP directive (let's say enabling allow_url_fopen).
3. Once I save the changes, /opt/cpanel/ea-php70/root/etc/php.d/local.ini is created and includes this change:

Code:
# grep allow_url_fopen /opt/cpanel/ea-php70/root/etc/php.d/local.ini
allow_url_fopen = On
4. Assuming suPHP is configured as the PHP handler for PHP 7, and no local php.ini files exist under the account, allow_url_fopen correctly shows "On" in a PHPINFO file under a test account.

5. I then create a copy of /opt/cpanel/ea-php70/root/etc/php.ini with allow_url_fopen set to "Off" to /home/$user/public_html/php.ini.

6. When refreshing the PHPINFO page for the account, allow_url_fopen is still set to "On", despite the local php.ini file's setting.

This is by design. If I want this option "Off", I must add the following line to the account's .htaccess file:

Code:
suPHP_ConfigPath /home/$user/public_html/php.ini
Once I do this, the option then reflects the value defined in the account's php.ini file. Here's the link to the document that explains how this works:

The cPanel PHPRC PHP Patch for EasyApache 4 - EasyApache 4 - cPanel Documentation

Thank you.
 

4u123

Well-Known Member
PartnerNOC
Jan 2, 2006
939
22
168
Hello,


This is by design. If I want this option "Off", I must add the following line to the account's .htaccess file:

Code:
suPHP_ConfigPath /home/$user/public_html/php.ini
Once I do this, the option then reflects the value defined in the account's php.ini file. Here's the link to the document that explains how this works:

The cPanel PHPRC PHP Patch for EasyApache 4 - EasyApache 4 - cPanel Documentation

Thank you.
Why would you create a tool for the end user to create and manage their own custom php.ini files - yet specifically set it not to work? It makes no sense. I must have missed something? Does it only work under DSO?

If I understand correctly, our customers cannot make use of the custom php.ini option in cpanel under suphp - unless we manually add a directive to their .htaccess file each time they create a new php.ini? Did I get that wrong?

I don't understand why you would go to the trouble of developing a cpanel php.ini editor at all, if it simply doesn't work?

With alt-php under CageFS, using the PHP selector, the end user is able to change their php.ini settings. We've switched to EA4 and cpanels multi PHP as a "native alternative" to the CL offering - but I now find it doesn't work as it should.

If you give the client the option to automatically create and to manage their own php.ini files, you should at least go the whole way and actually implement those changes.

With EA4, this option in cpanel is enabled by default. So you've given our customers a tool they can't use. If you're not going to finish the job and make it work correctly, why is this enabled at all?

Can you please explain, under what circumstances does this tool actually work without any further manual intervention?
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463
Hello @4u123,

Thank you for the feedback! There's actually a case open (EA-5554) to ensure that changes made via "cPanel >> MultiPHP INI Editor" work across all PHP handlers and PHP versions, and accounts for instances where the PHP handler or PHP version assigned to the account changes. I'll update this thread with more information on this case as it becomes available.

Thank you.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463
Any Update ????
cPanel 62 includes some changes that improve how this feature works. Here's the pertinent section from the cPanel 62 Release Notes:

MultiPHP Manager
We updated the MultiPHP Manager interface (Home >> Software >> MultiPHP Manager) to include a number of improvements. This includes the following improvements:
  • The interface now also displays what version of PHP a virtual host inherits, rather than just the word inherit.
  • When you change a virtual hosts' PHP version, the user interface notifies you of any other virtual hosts that may inherit these changes.
  • We updated the PHP-FPM checks to queue the necessary missing packages when you click the Install button. This allows you to more easily install these packages.
cPanel's MultiPHP INI Editor
When you save changes in cPanel's MultiPHP INI Editor interface (Home >> Software >> MultiPHP INI Editor), the changes save to both the php.ini and user.ini files.
Thank you.
 

nickwuk

Active Member
Jul 18, 2009
27
2
53
Using WHM 62 and still confused! Part of the confusion seems to be caused by the INI Editor creating a public_html/php.ini even though local.ini has the setting user_ini.filename = ".user.ini", in which case public_html/php.ini seems to be superfluous under default settings.

How does /opt/cpanel/ea-php56/root/etc/php.d/local.ini relate to /opt/cpanel/ea-php56/root/etc/php.ini ?

EA3 with SuPhp was far simpler to understand where several settings in a custom public_html/php.ini could over-ride a single server-wide php.ini.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,228
463
Hello,

The MultiPHP INI Editor will save changes to multiple configuration files to account for potential changes to the PHP handler. The purpose of this is to ensure that custom changes made via the editor are preserved when the PHP version or handler changes.

Essentially, you should not have to make any manual changes to the PHP configuration files when using "cPanel >> MultiPHP INI Editor". Note that cPanel 64 includes additional improvements to account for .htaccess files and the DSO handler:

64 Release Notes - Version 64 Documentation - cPanel Documentation

How does /opt/cpanel/ea-php56/root/etc/php.d/local.ini relate to /opt/cpanel/ea-php56/root/etc/php.ini ?
https://10.18.3.58:2087/cpsess8208155209/scripts/command?PFILE=main
The "/opt/cpanel/ea-php56/root/etc/php.ini" file stores the default values, whereas the "/opt/cpanel/ea-php56/root/etc/php.d/local.ini" includes the custom values configured from "WHM Home » Software » MultiPHP INI Editor".

Thank you.