Just a comment about the [PATH] section
It is said in http://php.net/ini.sections 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

Ex:
[PATH=/www2/]
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...

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)?

To:  pajoye@php.net

Yes I know it works only for CGI/FastCGI SAPI (http://php.net/manual/en/configuration.file.per-user.php).
.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 php.net (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 php.net 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.
Thanks.
Thomas.

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 ?

Thanks.
Thomas.

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".

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.

Hello,

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.

Thanks.
Thomas.

Assigned means "someone (me) will work on it", not "it is fixed" :)

Btw, htscanner allows htaccess-like file for 5.x, for the record.

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.

> /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\.user.ini
D:\Webserver\Apache2.2\htdocs\phpinfo.php (working)
D:\Webserver\Apache2.2\htdocs\test\phpinfo.php (not working)

Regards,
Carsten

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.

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/"
</FilesMatch>

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.

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.

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.

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
versions[1]?

[1] <https://www.php.net/supported-versions.php>

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.