Doc #71340 [Com]: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code

Edit report at https://bugs.php.net/bug.php?id=71340&edit=1 ID: 71340 Comment by: gpointorama at gmail dot com 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. ---------------------- It's a bad argument to me, using this setting with admin_value IS NOT MANDATORY FOR ANYONE, so backward compatibility is always preferable in such cases, strange no one understand this way of thinking. dunno i'm strange probably! but it feels is not the php way to make this breaking changes for no good reason! 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... ---------------------- Exactly it's their code (or their third party code) and we as hosting providers need a way to make it work in some way even a bad one without having to touch all their code (or their third party code) and this method of fixing it had been working for years! it's obvious you never had to handle such problems, and it's the cause you don't know why this is useful, as you see if you are not open minded enought it's not possible to convince you about that, we have already given this answers about cases where this is useful! 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. ---------------- i only see changing not mandatory options and proclaiming it as good pratice because are special as controversial! if we have some free time we will try to escalate this issue to php core devs, for now we are forced to use a patched version of php seems, unfortunate. Previous Comments: ------------------------------------------------------------------------ [2018-06-06 14:24:11] requinix@php.net 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. ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ 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