Edit report at https://bugs.php.net/bug.php?id=50684&edit=1
ID: 50684
Updated by: sergey@php.net
Reported by: john dot peterson10 at gmail dot com
Summary: max_file_uploads is now PHP_INI_PERDIR
-Status: Open
+Status: Closed
Type: Documentation Problem
Package: PHP options/info functions
Operating System: Windows
PHP Version: 7.3
-Assigned To:
+Assigned To: sergey
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.
Closed with https://github.com/php/doc-en/commit/8a04690ab3ca341df750d00b32f27df5debbc307
Previous Comments:
------------------------------------------------------------------------
[2021-08-24 11:00:10] cmb@php.net
This is already supposed to be resolved[1] as of PHP 5.4.0. The
docs need to be updated, though.
[1] <https://github.com/php/php-src/commit/8bc24c004605d5dcf41652033f9be25038f1156e>
------------------------------------------------------------------------
[2020-02-07 06:09:29] phpdocbot@php.net
Automatic comment on behalf of aharvey
Revision: http://git.php.net/?p=doc/en.git;a=commit;h=568d68b95ac7a99963076491f4d8f76d6c2733c0
Log: Fix bug #50684 (max_file_uploads can't be changed from .htaccess (or ini_set)) by changing
the documentation to reflect max_file_uploads being PHP_INI_SYSTEM, not PHP_INI_ALL as previously
documented.
------------------------------------------------------------------------
[2019-10-10 17:57:54] teo8976 at gmail dot com
> But you are right about .htaccess, I think. We probably should allow this
> setting to be changed there
So why the f*** was and still is this closed??
------------------------------------------------------------------------
[2012-02-17 17:49:05] rasmus@php.net
ini_set would never work because file uploads happen before the PHP script is
executed, so by the time you call ini_set() it would be too late.
But you are right about .htaccess, I think. We probably should allow this setting
to be changed there. It is always a tricky balance when it comes to security-
related settings. In some environments you want to lock down the security-related
settings in a single place and not allow individual users/apps to override these,
and in other environments you want to let users/apps have more rope.
------------------------------------------------------------------------
[2012-02-17 15:52:19] gonssal at gmail dot com
How do you close this bug without adding the posibility of changing the
parameter value through ini_set and .htaccess? This has to be the most retarded
idea a PHP dev has had since the "magic quotes" epic fiasco, breaking lots of
flawlessly and security-proof code working after a PHP version update, without
any warning (not even a Notice).
Also jani@php.net I've seen you answer in 3 different bugs in a way that makes
it seem like this won't be ever addressed. I can understand it was your
"brilliant" idea to implement this, but a bit of humility and acceptance of
errors would be really appreciated.
And sorry if someone is offended by the 'tone' of this message but when you have
to spend 3 days reviewing _ALL_ the projectes using the CMS you developed, in a
lot of different servers because, you know they'll stop working when PHP version
is updated, due to a "great idea" (not really), well your mood goes down real
quick.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=50684
--
Edit this bug report at https://bugs.php.net/bug.php?id=50684&edit=1