|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38714 local php.ini not recognized
Submitted: 2006-09-04 15:59 UTC Modified: 2006-09-05 14:35 UTC
From: lehmann at cnm dot de Assigned:
Status: Closed Package: *Configuration Issues
PHP Version: 5.1.6 OS: Linux 2.6.9-34.ELsmp
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: lehmann at cnm dot de
New email:
PHP Version: OS:


 [2006-09-04 15:59 UTC] lehmann at cnm dot de
We use PHP as command line version. Usually first the global php.ini (in PREFIX/lib/php) is parsed and evaluated, then PHP looks for a local php.ini in the directory of the php-file that will be executed to look for options that may override the global options.

This can be used e.g. to enable register_globals for a certain user.

In php-5.1.6 the local php.ini isn't recognized or at least the options in there aren't evaluated. This worked fine even in the command line versions of older php releases (php4 or php 5.0.x).


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-04 16:02 UTC]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

 [2006-09-04 17:00 UTC] lehmann at cnm dot de
It would be helpful to know what you are missing.

try the following steps:

Put register_globals=off in the global php.ini.
Put a local php.ini with register_globals=on into e.g. /test.
Save a script with




as /test/script.php

Run the command line version of php like /usr/local/bin/php /test/script.php.

phpinfo() will give you register_globals=off. It will also not show you any other options you have put into the local php.ini like change of extension dirs etc.
safe mode is off.
 [2006-09-04 17:53 UTC]
Works perfectly fine here.
Please run `php -i | grep "php\.ini"`.
 [2006-09-05 00:05 UTC] lehmann at cnm dot de
But it doesn't work here and other users in the mailinglist have the problem. pwd is the directory of the script.

php -i | grep php.ini
<tr><td class="e">Configuration File (php.ini) Path </td><td class="v">/usr/local/php-5.1.6/lib/php.ini </td></tr>

Global php.ini defines register_globals=off, local php.ini defines register_globals=on

php -i | grep register_globals
<tr><td class="e">register_globals</td><td class="v">Off</td><td class="v">Off</td></tr>

So the options of the local php.ini haven't become effective.

The is no ZendOptimizer, Ioncube or anything like loaded.
 [2006-09-05 08:04 UTC]
You are using CGI instead of CLI.
 [2006-09-05 10:56 UTC] lehmann at cnm dot de
I never said that I'm using CLI. I said "command line version", not "command line interface". However, while the problem may not exist in the CLI version, it exists in the CGI version. So I hope someone can fix it.
 [2006-09-05 11:01 UTC]
This is expected behaviour, CGI doesn't look for php.ini in the current directory, only CLI does that.
 [2006-09-05 11:16 UTC] lehmann at cnm dot de
Since when isn't this the expected behaviour? It worked for _all_ previous PHP releases and millions of ISPs are running PHP as CGI version behind a CGIwrapper. Customers need to be able to change options for their local scripts. And they cannot put ini_set() calls in all of their scripts and sometimes they even cannot change the scripts due to arising checksum-problems if they are using encoders/decoders like the ZendOptimizer.
Through the local php.ini someone that needs register_globals=on can set it like this, while it is off by default. Or someone might need his own libraries that he wants to include as an extension so he needs to change the extension_dir and so on. There definetely is a use for this feature so why has someone removed it? And why isn't the removal mentioned in the changelog if it has been done by intention?
 [2006-09-05 14:23 UTC] axelseaa at modevia dot com
We have had similiar issues.  We run php cgi via suexec in a shared hosting enviroment.  When we were using php 4, users could simply place a php.ini folder in the same folder as the script being ran, and php would parse that ini file and load the settings in it.

When we upgraded to php5, that functionality was no longer there and we have not found any reason why it is gone.  I believe it is related to the same issue being reported here.  If there is anythig you would like me to try to attempt to sort out this issue.
 [2006-09-05 14:35 UTC]
5.2.0 will fix this situation by reverting to pre 5.1.x behaviour, only CLI will not look up in current working directory. Other sapis such as CGI will look in the current dir when searching for php.ini.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon Aug 08 01:05:45 2022 UTC