The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

EA4 php.ini/local.ini behavior

Discussion in 'EasyApache' started by jgidi, Aug 1, 2016.

Tags:
  1. jgidi

    jgidi Registered

    Joined:
    Aug 1, 2016
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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
     
  2. kdean

    kdean Well-Known Member

    Joined:
    Oct 19, 2012
    Messages:
    262
    Likes Received:
    12
    Trophy Points:
    18
    Location:
    Orlando, FL
    cPanel Access Level:
    Root Administrator
    Check the local.ini file to see if it has this line:

    user_ini.filename = "php.ini"
     
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,762
    Likes Received:
    662
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    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.
     
  4. jgidi

    jgidi Registered

    Joined:
    Aug 1, 2016
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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
     
  5. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,762
    Likes Received:
    662
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
  6. Cyber911

    Cyber911 Member

    Joined:
    May 24, 2003
    Messages:
    19
    Likes Received:
    0
    Trophy Points:
    1
    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)
     
  7. orudge

    orudge Member

    Joined:
    Oct 31, 2004
    Messages:
    14
    Likes Received:
    2
    Trophy Points:
    3
    Location:
    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
     
  8. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,762
    Likes Received:
    662
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
  9. martin MHC

    martin MHC Member

    Joined:
    Sep 14, 2016
    Messages:
    15
    Likes Received:
    5
    Trophy Points:
    3
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    BANG! That was the solution I was looking for! Many thanks!
     
  10. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,762
    Likes Received:
    662
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    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.
     
  11. 4u123

    4u123 Well-Known Member
    PartnerNOC

    Joined:
    Jan 2, 2006
    Messages:
    765
    Likes Received:
    1
    Trophy Points:
    18
    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?
     
  12. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,762
    Likes Received:
    662
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    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.
     
Loading...

Share This Page