Doc #71340 [Ana]: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code
| From: | requinix@php.net | Date: | Wed, 06 Jun 2018 14:24:14 +0000 |
| Subject: | Doc #71340 [Ana]: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-15748@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=71340&edit=1
ID: 71340
Updated by: requinix@php.net
Reported by: gpointorama at gmail dot com
Summary: php_admin_value[error_reporting] in fpm/apache conf
can be bypassed in user code
Status: Analyzed
Type: Documentation Problem
Package: PHP options/info functions
Operating System: Any
PHP Version: 7.0
Block user comment: N
Private report: N
New Comment:
I'm partially undecided but if the choice is between the old and new behavior then I'm in
favor of the new. I understand people want fix the value but I still don't understand why; have
one error_reporting value as a default and I see no reason why a user should not be able to change
it in their code. Why does it matter? It's their site, their code, their error logs...
And no, that argument does not apply to every INI setting so there's no need to go there:
error_reporting is an exception to the rule. I'd even say it's not the only one, like I
could very easily argue that include_path should get special treatment too.
I'm not one of the core devs, I just hang around the bug tracker, but to me what PHP is doing
now makes sense.
As far as this bug report is concerned, it would be NAB because the behavior is intentional, however
the docs should mention it and don't now so instead this should be repurposed into a docs bug.
Which is what nikic just did. Beyond that, changing the behavior to go back to the PHP 5 version is
clearly controversial and so should be discussed in the appropriate place: the internals list and
not here.
Previous Comments:
------------------------------------------------------------------------
[2018-06-06 13:58:15] gpointorama at gmail dot com
I can only say that is a shame that core php devs are totally unaware on how useful this feature is
in general and how is used from an hosting provider point of view.
And we are not convinced about your decision on how good breaking backward compatibility is and also
the other performance motivations behind this change.
------------------------------------------------------------------------
[2018-06-06 13:32:59] nikic@php.net
I haven't been convinced by what has been said and it seems that @requinix concurs, so I'm
switching this to a documentation issue. This backwards-incompatible change needs to be mentioned in
the PHP 7.0 upgrading guide.
------------------------------------------------------------------------
[2018-06-06 11:19:14] admin at inwebse dot com
Up. What with this problem?
------------------------------------------------------------------------
[2018-05-25 19:55:32] admin at inwebse dot com
Up. Any progress?
------------------------------------------------------------------------
[2018-05-15 10:33:45] admin at inwebse dot com
Any news?
------------------------------------------------------------------------
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=71340
--
Edit this bug report at https://bugs.php.net/bug.php?id=71340&edit=1