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.

cPanel MultiPHP INI Editor issue

Discussion in 'EasyApache' started by Dhaupin, Aug 9, 2017.

  1. Dhaupin

    Dhaupin Active Member

    Joined:
    Jan 3, 2014
    Messages:
    41
    Likes Received:
    4
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    I am running into this everywhere. It seems like this editor ACL is a bit "static" as to what it chooses to include in user.ini, and if multiple domains hit the same root, doesnt work in a per-domain manner anyways if they are all in the same root (ie, multisite). So far its wrecked up an install/requirements on every account on our server in some way or another. Is there a way to shut off the use of user.ini without hacking around and which will persist through updates? We are using FPM if that matters.

    EDIT: it seems like it could be related to this: MultiPHP INI Editor file name .user.ini instead of php.ini

    The reason im asking is that last week all some Newrelic schemas got nuked. There is no reason newrelic stuff cant be set in user.ini, htaccess, or even at php runtime, right? Also things like max_input_nesting_level or max_file_uploads dont work anymore which is a massive issue for ecom apps that had been stable for years.
     
    #1 Dhaupin, Aug 9, 2017
    Last edited: Aug 9, 2017
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    37,064
    Likes Received:
    1,287
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello @Dhaupin,

    I've moved this post to a separate thread. Here's a link to a post with a workaround when configuring custom PHP values when PHP-FPM is enabled:

    PHP-FPM and PHP.INI

    Thank you.
     
  3. Dhaupin

    Dhaupin Active Member

    Joined:
    Jan 3, 2014
    Messages:
    41
    Likes Received:
    4
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    Ah thanks. Interesting workaround, I suppose :) In our case that would be a bunch of manual work. Not sure what we will do atm. For now, manually dumping some into user.ini, moving more directives to app runtime/config, and pre-loading modules at main php instance helps.

    I noticed a critical piece to some of this strange behavior though, as to why the some integrations got nuked (and wouldnt return): the "extension" directive (and a handful of others) only work in php.ini. So allowing users to call optional extension=something.so via their account prob wont work in user.ini. This disallows former modules that users could call for their app like extension=redis.so or newrelic.so

    In regards to the other directives that arent loading at user.ini, they seem to be kinda random. It should be everything PHP_INI_SYSTEM is not available at user level? Looking forward to v68.
     
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    37,064
    Likes Received:
    1,287
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    These are the directives that are not changeable from the user-level (unless using the suPHP handler):

    allow_url_fopen
    allow_url_include
    enable_dl
    file_uploads
    safe_mode

    Generally, we recommend using the cPanel MultiPHP INI Editor option to make PHP configuration changes to the individual account (as opposed to manually creating ini files), as this feature is designed to populate the correct entries in the required files and accounts for changes to the PHP handler.

    Thank you.
     
Loading...

Share This Page