EA4 php.ini/local.ini behavior

Check the local.ini file to see if it has this line:

user_ini.filename = "php.ini"

 

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)

 

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

 

BANG! That was the solution I was looking for! Many thanks!

 

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?

 

Looking forward to this being resolved as it currently causes too many support requests.

 

Any Update ????

 

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.