Bug #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: admin at inwebse 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: Bug Package: PHP options/info functions Operating System: Any PHP Version: 7.0 Block user comment: N Private report: N New Comment: Up. Any progress? Previous Comments: ------------------------------------------------------------------------ [2018-05-15 10:33:45] admin at inwebse dot com Any news? ------------------------------------------------------------------------ [2018-05-06 16:06:29] php at alternize dot com for anyone who thinks "php_admin_value[error_reporting]" should not be immutable: nobody is forced to use this. if you want to allow apps/users to change the error level, use "php_value[error_reporting]" and you're good. whoever sets "php_admin_value[error_reporting]" certainly has her/his reasons - there *are* valid reasons for doing so, some outlined in this bug's comments. ------------------------------------------------------------------------ [2018-05-06 15:45:17] spam2 at rhsoft dot net @ operator has nothing to do with a ini-value hell what is the problem simply ignore ini_set() for values or flags set with php_admin_* which should have no other runtime impact or even offer optimizations because its known not to change ------------------------------------------------------------------------ [2018-05-06 15:33:15] gpointorama at gmail dot com Instead of starting ethical discussions about how php error design works please keep in mind: 1) php has ever worked that way, no one had never had problems about it 2) between php 5 and 7 has been introduced a backward incompatible change, without documenting it 3) shops that do php hosting want to be like php itself "do the right thing" in a pragmatic way, if our clients/or use code from third parties that do messy things about error_reporting we want all will work anyway in most cases without touching their code, for example wordpress and plugins we can't afford and it's a also bad for all if who hosts had review all the code of our clients/third parties plugins etc...while switching from php 5 to 7 also keep in mind that, the already slow adoption of php 7, for hosting providers will slow more before php 7 we had the option to "php_admin_value[error_reporting] = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_WARNING & ~E_STRICT" and all was good in case of problems 4) if php want to introduce a new better way/design to handle errors a new separate mode can be added but should be optional until all php code/devs in the word will know about that 5) we are not switching to php7 because of this ------------------------------------------------------------------------ [2018-05-06 15:07:35] nikic@php.net The problem I see is that error_reporting is a somewhat more fundamental configuration option with direct language integration. If you take your premise that php_admin_value should affect the error_reporting() function one step further, you could also argue that the @ operator should become ineffective if php_admin_value[error_reporting] is used (which I think would be quite the disaster...) ------------------------------------------------------------------------ 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