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

From: 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

« previous php.doc.bugs (#15748) next »