Local php.ini files stopped working after upgrade

frisbees

Member
Feb 26, 2008
15
0
51
I have php.ini files in the public_html directories of some of my websites on our cPanel server. I upgraded cPanel about a week ago and ever since the php.ini variables are not being loaded. Today, I tried copying the entire php.ini file and just changing the variables I needed. This worked, but is not ideal as I have almost 90 websites and do not want to go through each one to find out which ones use a php.ini file and which ones don't.

How do I make it so I can just set specific variables in php.ini again instead of having to copy the entire php.ini file into the user's document root?

For example I have one site that uses all the defaults from the server's php.ini except they need a session.save_path to be equal to something different. In order for me to get this to work, I had to make a copy of the whole php.ini from /usr/lib/php.ini to /home/<userdir>/public_html and make changes to it. Just creating a file named php.ini and putting the line of text session.save_path=/home/<userdir>/public_html/session does not work. I'm not sure if this matters but I use suPHP.
 

sehh

Well-Known Member
Feb 11, 2006
579
6
168
Europe
Same here, it was working before with per-domain php.ini files that had just the custom settings required and after the recent STABLE upgrade these files are ignored.

Any suggestions on how to return the previous functionality?
 

asmithjr

Well-Known Member
Jun 13, 2003
516
8
168
Can I bump this? just encountered the same issue.

WHM 11.23.2 cPanel 11.23.6-C27225
REDHAT Enterprise 4 i686 on standard - WHM X v3.1.0

PHP Version 5.2.5

php.ini in local domain folder has no effect.
 

asmithjr

Well-Known Member
Jun 13, 2003
516
8
168
Can I bump this? just encountered the same issue.

WHM 11.23.2 cPanel 11.23.6-C27225
REDHAT Enterprise 4 i686 on standard - WHM X v3.1.0

PHP Version 5.2.5

php.ini in local domain folder has no effect.
 

cPanelDavidG

Technical Product Specialist
Nov 29, 2006
11,212
13
313
Houston, TX
cPanel Access Level
Root Administrator
Can I bump this? just encountered the same issue.

WHM 11.23.2 cPanel 11.23.6-C27225
REDHAT Enterprise 4 i686 on standard - WHM X v3.1.0

PHP Version 5.2.5

php.ini in local domain folder has no effect.
If this issue is urgent, please let our technical analysts take a look at your server. You can do this by submitting a support ticket.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,042
230
368
cPanel Access Level
Root Administrator
How do I make it so I can just set specific variables in php.ini again instead of having to copy the entire php.ini file into the user's document root?
As far as I know, this has never been a function of PHP.

PHP can be told to read a separate php.ini file, but it cannot be told to read a system-wide php.ini file and then overwrite those values with another custom php.ini file.

With phpsuexec (and I suppose with suPHP) you could always put a copy of the php.ini file in the current directory and PHP would read that php.ini when executing itself. But if that php.ini file just contained one or two lines of configurations, then the rest of the PHP configuration options would be set back to their default values as outline at php.net. This may or may not have been the set values in the system-wide php.ini.
 

frisbees

Member
Feb 26, 2008
15
0
51
Ok. Fine. Back to their default settings wouldn't bother me either, as my system wide is the same as PHP defaults. But it doesn't do that either. It sets absolutely everything to the same as the system wide or possibly the PHP default (can't tell as they are the same) unless I have the entire PHP.ini in the directory. And as I said before, this wasn't an issue until the last update I received from cPanel.
 

asmithjr

Well-Known Member
Jun 13, 2003
516
8
168
I put in a ticket.

yes I put a php.ini in current directory but it appears php is not reading it. No changes are made.
I also copied the server php.ini then made the change and looks like php is not readng it either.
 

frisbees

Member
Feb 26, 2008
15
0
51
That one I can understand (and only since the update as well) but the php.ini file has to be in the directory the page is in not just in the document root. Fun huh? So I have a couple of sites that now have to have 2 or 3 php.ini files in order to function properly. I need this fixed. We are a hosting provider so the clients update their own files and none of them have a clue about php.ini and every time they synchronize or update an entire directory or add a new directory I end up have to fix the problems they encounter.
 

frisbees

Member
Feb 26, 2008
15
0
51
All lines are commented out. Already found that during my google searching, but it didn't affect me as they are all commented out.
 

frisbees

Member
Feb 26, 2008
15
0
51
Thanks. That will suffice for my purposes. Still want to know what happened though. But really. Thanks a lot. I'll have to test it later.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,042
230
368
cPanel Access Level
Root Administrator
I can't speak for cPanel's edition of suPHP. I use a customized suPHP compile on all of our servers and with it, it doesn't allow customized php.ini files to be used in user's directories.

This is because we disable a lot of PHP system functions by default. I don't a hacker or other malicious user to be able to circumvent this by adding their own php.ini file into their directory to use these functions.

Instead, if one of our users needs a particular change to the php.ini on their account, I use this setup that was referenced in that post to create a custom php.ini just for that account, and one that I still control.

This allows me to enable PHP system functions for accounts that really need them, while leaving them disabled for the vast majority of accounts.

cPanel may have adopted a similar method.
 

frisbees

Member
Feb 26, 2008
15
0
51
Don't get me wrong. I love the idea. I've always hated having a php.ini in their DocumentRoot, but I wasn't sure what else to do. I'm fairly novice when it comes to linux and overbooked 150% of the time. There is lots of frustration surrounding our hosting. The goal right now, is to keep the clients happy and in my spare time I try to lock things down. Which is why I started using suPHP.
 

frisbees

Member
Feb 26, 2008
15
0
51
sparek-3,

That worked absolutely perfectly. I have created documentation for our company so that the other administrators can copy the process. Thanks a million.