|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50374 .user.ini subdirectory not working and problem with [PATH] in php.ini
Submitted: 2009-12-03 15:27 UTC Modified: 2021-02-28 04:22 UTC
Avg. Score:4.2 ± 0.8
Reproduced:11 of 11 (100.0%)
Same Version:4 (36.4%)
Same OS:3 (27.3%)
From: tom_borgo at hotmail dot com Assigned: cmb (profile)
Status: No Feedback Package: Scripting Engine problem
PHP Version: 5.3.1 OS: XP SP3
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: tom_borgo at hotmail dot com
New email:
PHP Version: OS:


 [2009-12-03 15:27 UTC] tom_borgo at hotmail dot com
WinXP SP3 Fr, Apache 2.2 (winnt), PHP 5.3.1 (but problem is in 5.3.0 too).
PHP: NTS (tested with VC6, VC9 and VC8 version from ZendServer)
Used in CGI mode

.user.ini are not parsed for script in subdirectory of the .user.ini.
Sould be as it should works like .htaccess.

Second problem, if php.ini as a [PATH=/path/] section, /path/.user.ini are no more parsed.

Reproduce code:
.user.ini is display_errors = 0 (i try with Off, "Off", "0", same)
main php.ini is display_errors = 1

/www/administrator/phpinfo.php (with <?php phpinfo();?>)

PHP Info, in /www/administrator/, gives display_errors = 1, but should be 0 as it is defined in the www/.user.ini (should be taken in the subdirectory, like .htaccess)

Second strange problem:
if in php.ini there is:

display_errors = 1

In this case a phpinfo in /www/ give display_errors = 1, even if .user.ini in /www/ is configured display_errors = 0.

Expected result:
Expected to work like .htaccess for subdirectory.
Expected to work even with a [PATH] section for the directory is defined (.user.ini should be prioritary to the [PATH] section).

Actual result:
Explained in the code section.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-12-03 15:39 UTC] tom_borgo at hotmail dot com
Just a comment about the [PATH] section
It is said in that directive in PATH section overide custom and runtime ini directives. So I think it is in fact normal that .user.ini don't change the display_errors flag.
But .user.ini are not parsed if [PATH] section are in the main php.ini for other directory

display_errors = 1

/www/.user.ini is not more taken into account !
If i remove the PATH section (i put it inthe end of my php.ini), .user.ini is taken into account.
Really strange...
 [2009-12-03 15:39 UTC]
It works only with the FastCGI SAPI, not apache. We don't support ZendServer so I won't say what should work or not with their version.

Can you try using a snapshot please (FCGI VC9)?
 [2009-12-03 15:50 UTC] tom_borgo at hotmail dot com

Yes I know it works only for CGI/FastCGI SAPI (
.user.ini works for me only for the directory where it is and without any [PATH] section in the main php.ini.

I tried with a PHP downloaded from the (5.3.1 NTS VC6 and i try with VC9 too). It is the same as the one from ZendServer (VC8).
So problem is in ZendServer,but too in the last stable binary windows compiled on the website.

Is it a configuration problem on my side or does another people got the same problems ?

I will try with the snapshot right now.
I keep you warning.
 [2009-12-03 16:10 UTC] tom_borgo at hotmail dot com
Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot.

Problem .user.ini for php script in subdirectory is always the same.
/www/phpinfo.php -> take into account the /www/.user.ini
/www/administrator/phpinfo.php -> take NOT into account the /www/.user.ini

For the [PATH] problem, i tried and problem is no more here.
So I tried again with 5.3.1, no more problem.
Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is just for ZendServer.
So we can forgot about the [PATH] problem.

But for the .user.ini, am i mistaken something ? Or is it a php problem ?

 [2009-12-11 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2010-06-10 21:15 UTC] jirka at pbox dot cz
Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010 17:13:20.
.user.ini custom setting works in the directory where the ini file is located, but 
has no effect in any of subdirectories.
 [2010-06-12 19:10 UTC]
-Status: No Feedback +Status: Assigned
 [2010-06-13 20:19 UTC] tom_borgo at hotmail dot com

Yes, the problem has not been resolved, or the documentation has not been updated to say that it is normal that it doesn't affect the subdirectory.
It is a shame because .user.ini is very important to use php directive by directory (because htaccess cannot be used in this way like PHP in apache module).

I hope problem will be taken really into consideration. And it is really easy to test it.

 [2010-06-13 20:32 UTC]
Assigned means "someone (me) will work on it", not "it is fixed" :)

Btw, htscanner allows htaccess-like file for 5.x, for the record.
 [2010-06-13 20:56 UTC] tom_borgo at hotmail dot com
Thanks Pajoye for your fast answer.
I really hope you can fix it ! :)

Yes htscanner is an alternative solution, i never try it. I prefer rely on PHP itself. And htscanner is in alpha stage and last release is more one year old, i mean for system in real production it is necessary to have stable version. Htscanner seems ok for leisure purpose but I will not use it for bussiness application.
 [2011-07-08 11:21 UTC] carsten_sttgt at gmx dot de
> /www/phpinfo.php -> take into account the /www/.user.ini
> /www/administrator/phpinfo.php -> take NOT into account the /www/.user.ini

Just found out: The same problem exists in PHP 5.3.6-NTS-VC9; Apache/2.2.19 (CGI setup); Windows 7 32bit

Even I can read in the manual:
| In addition to the main php.ini file, PHP scans for INI files in each
| directory, starting with the directory of the requested PHP file, and working
| its way up to the current document root

I have a DOCUMENT_ROOT = "D:\Webserver\Apache2.2\htdocs"
And the files:
D:\Webserver\Apache2.2\htdocs\phpinfo.php (working)
D:\Webserver\Apache2.2\htdocs\test\phpinfo.php (not working)

 [2014-09-13 13:08 UTC] dummy at dumyydummy dot com
Same problem on Win7 with apache 2.4.10 X86 (the one from apache haus and the one from Apache Lounge) and php 5.6.0, php 5.5.16 or php 5.3.29 all in fcgi mode.

php configurations defined in .user.ini only apply to the folder where .user.ini is. Not subfolders.
 [2015-03-17 09:39 UTC] framelio at gmail dot com
I have the same problem here, with php 5.3.29, 5.4.38, 5.5.22 and 5.6.6 

Configuration on linux with Apache 2.4.12 and mod_proxy_fcgi and PHP-FPM configuration:

# This is to forward all PHP to php-fpm.
<FilesMatch \.php$>
 SetHandler "proxy:unix:/path/to/.socks/php-domain.sock|fcgi://domainname/"

The .user.ini directives apply only in the same folder as the php file and not in the subfolders.

Some phpinfo:

Server API: FPM/FastCGI 
_SERVER["DOCUMENT_ROOT"] is correctly set to the virtualhost DocumentRoot

I didn't have this problem when working with mod_fastcgi using FastCgiExternalServer directive.
 [2017-01-13 09:00 UTC] kawewong at gmail dot com
I have the same problem.

If I put .user.ini file into www root.
http://localhost/ -> ini_get('upload_max_filesize') result is 10M (override value)
http://localhost/test -> ini_get('upload_max_filesize') result is 10M
http://localhost/test/lv2 -> ini_get('upload_max_filesize') result is 10M
http://localhost/test/lv2/lv3 -> ini_get('upload_max_filesize') result becomes 2M which is php.ini value and this folder has no .user.ini file.
These are not in virtual directory.
 [2017-10-24 07:31 UTC]
-Status: Assigned +Status: Open -Assigned To: pajoye +Assigned To:
 [2019-12-13 19:19 UTC] noyearzero at hotmail dot com
This but just passed it's 10th anniversary!  How about we celebrate by getting it fixed?

I have the same issue on Windows 10 x64 using the Apache 2.4.41 x64 and the fcgi module.  I've tried pretty much all the php versions both Thread Safe and Not.  I've tried about every combination of everything I could possibly change.  

I'd really like to see this fixed because PHP on windows actually works pretty good now... other than this.
 [2021-02-16 13:30 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-02-16 13:30 UTC]
I cannot reproduce this with PHP-7.4 FCGI (tested with IIS and
Apache).  For me, .user.ini in subdirectories are scanned, and
PHP_INI_ALL and PHP_INI_PERDIR settings are applied.

Can anybody still reproduce with any of the actively supported PHP

[1] <>
 [2021-02-28 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 19 00:01:33 2024 UTC