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
     
    #1 jgidi, Aug 1, 2016
  2. kdean

    kdean Well-Known Member

    Joined:
    Oct 19, 2012
    Messages:
    268
    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"
     
    #2 kdean, Aug 2, 2016
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    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.
     
    #3 cPanelMichael, Aug 2, 2016
  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
     
    #4 jgidi, Aug 2, 2016
  5. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    I'm happy to see the information was helpful. Thank you for updating us with the outcome.
     
    #5 cPanelMichael, Aug 2, 2016
  6. Cyber911

    Cyber911 Member

    Joined:
    May 24, 2003
    Messages:
    19
    Likes Received:
    0
    Trophy Points:
    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)
     
    #6 Cyber911, Aug 18, 2016
  7. orudge

    orudge Member

    Joined:
    Oct 31, 2004
    Messages:
    14
    Likes Received:
    2
    Trophy Points:
    153
    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
     
    #7 orudge, Aug 18, 2016
  8. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    #8 cPanelMichael, Aug 24, 2016
  9. martin MHC

    martin MHC Active Member

    Joined:
    Sep 14, 2016
    Messages:
    29
    Likes Received:
    6
    Trophy Points:
    3
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    BANG! That was the solution I was looking for! Many thanks!
     
    #9 martin MHC, Nov 3, 2016
  10. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    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.
     
    #10 cPanelMichael, Nov 3, 2016
  11. 4u123

    4u123 Well-Known Member
    PartnerNOC

    Joined:
    Jan 2, 2006
    Messages:
    784
    Likes Received:
    6
    Trophy Points:
    168
    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?
     
    #11 4u123, Nov 17, 2016
  12. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    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.
     
    #12 cPanelMichael, Nov 17, 2016
  13. DomineauX

    DomineauX Well-Known Member
    PartnerNOC

    Joined:
    Apr 12, 2003
    Messages:
    421
    Likes Received:
    6
    Trophy Points:
    168
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    Looking forward to this being resolved as it currently causes too many support requests.
     
    #13 DomineauX, Dec 16, 2016
  14. ddshadow

    ddshadow Member

    Joined:
    Nov 18, 2011
    Messages:
    11
    Likes Received:
    0
    Trophy Points:
    51
    cPanel Access Level:
    Root Administrator
    Any Update ????
     
    #14 ddshadow, Jan 2, 2017
  15. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    cPanel 62 includes some changes that improve how this feature works. Here's the pertinent section from the cPanel 62 Release Notes:

    Thank you.
     
    #15 cPanelMichael, Jan 10, 2017
  16. nickwuk

    nickwuk Member

    Joined:
    Jul 18, 2009
    Messages:
    17
    Likes Received:
    1
    Trophy Points:
    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.
     
    #16 nickwuk, Mar 2, 2017
  17. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,470
    Likes Received:
    1,216
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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


    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.
     
    #17 cPanelMichael, Mar 9, 2017
(You must log in or sign up to post here.)
Loading...
Similar Threads - local behavior
  1. bejbi

    Replace SSL Certificates that do not match local hostname

    bejbi, Jul 25, 2017 at 3:51 AM, in forum: General Discussion
    Replies:
    2
    Views:
    46
    cPanelMichael
    Jul 25, 2017 at 11:10 AM
  2. vikins

    Repair Mailbox Permissions remotedomains / localdomains issue

    vikins, Jul 17, 2017, in forum: E-mail Discussions
    Replies:
    8
    Views:
    89
    vikins
    Jul 18, 2017
  3. ascalotoru

    Valores master y local .user.ini

    ascalotoru, Jul 14, 2017, in forum: Discusión en Español
    Replies:
    4
    Views:
    81
    ascalotoru
    Jul 19, 2017
  4. jndawson

    Deleting /usr/local/apache.ea3/ after upgrade to EA4

    jndawson, Jul 3, 2017, in forum: EasyApache
    Replies:
    4
    Views:
    121
    jndawson
    Jul 5, 2017
  5. cgaybba

    Emails shows delivered to localhost

    cgaybba, Jun 9, 2017, in forum: E-mail Discussions
    Replies:
    2
    Views:
    86
    cPanelChrisI
    Jun 9, 2017

Share This Page