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: php at alternize 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 amazed that the "new" behavior would be considered the desired one, as that makes absolutely no sense. there is *no other way* to enforce a consistent error logging when this backwards incompatible bug is kept. on the other way, nobody *was forced to use* "php_admin_value[error_reporting]": if you did not want an immutable error_reporting, use "php_value[error_reporting]" in your fpm config or "error_reporting" in php.ini or use the error_reporting function. "php_admin_value[error_reporting]" wasn't a default setting either, and those that used it, knew why and what it would mean. this takes away a really useful feature from those that had their reasons to use it, without any gain to the php code in general. there has been no reason shown in this bug reports comment what the php world has gained by introducing the backward breaking change. Previous Comments: ------------------------------------------------------------------------ [2018-06-06 15:00:26] admin at inwebse dot com I have a lot of websites and i maintain them. And i want to have centralized point where i can see problems from all of my sites. I want to run journalctl --follow --unit=php-fpm.service for tracking errors for all of my sites. Not going to every site for modifying error_reporting or error_log (syslog) or something else. Maybe this is not a best solution for developers, who wants to have a full control, but a best solution for hostings / sysops / etc. But now we are dropped from a boat. That's very sad... ------------------------------------------------------------------------ [2018-06-06 14:55:38] gpointorama at gmail dot com If we want to talk about a clean and elegant way to fix this mess with error handling in php then i can propose an error_reporting(E_ALL){... php code here ...} block to make clear and obvious the scope of the error_reporting settings....but that's another matter... ------------------------------------------------------------------------ [2018-06-06 14:53:10] gpointorama at gmail dot com 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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