# Make error_reporting=E_ALL the default - Thread: https://externals.io/message/106810 - Original archive: https://news-web.php.net/php.internals/106810 - Started by Nikita Popov on 2019-08-30T09:32:39+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #106810 — Nikita Popov — 2019-08-30T09:32:39+00:00 URL: https://externals.io/message/106810#106810 Hi internals, Relating to the recent discussions on undefined variables & co. One thing that is particularly annoying about the undefined variable case is that our default error_reporting level (without a php.ini) does not include E_NOTICE. Thankfully distros do tend to have more reasonable defaults, but if you spend as much time with custom PHP builds as I do, not seeing *anything* for undefined variables is a pretty big annoyance. Does anyone see an issue with making error_reporting=E_ALL the default in PHP 8? It can of course still be manually downgraded via php.ini and php.ini-production will retain the existing recommendation that excludes E_DEPRECATED/E_STRICT. PR: https://github.com/php/php-src/pull/4659 Regards, Nikita --- ## #106811 — Zeev Suraski — 2019-08-30T09:37:50+00:00 URL: https://externals.io/message/106810#106811 · In reply to: #106810 > > > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include E_NOTICE. > > Thankfully distros do tend to have more reasonable defaults, but if you > spend as much time with custom PHP builds as I do, not seeing *anything* > for undefined variables is a pretty big annoyance. > > Does anyone see an issue with making error_reporting=E_ALL the default in > PHP 8? It can of course still be manually downgraded via php.ini and > php.ini-production will retain the existing recommendation that excludes > E_DEPRECATED/E_STRICT. > > PR: https://github.com/php/php-src/pull/4659 +1 Zeev --- ## #106812 — Zeev Suraski — 2019-08-30T09:45:44+00:00 URL: https://externals.io/message/106810#106812 · In reply to: #106810 > > > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include E_NOTICE. > > Thankfully distros do tend to have more reasonable defaults, but if you > spend as much time with custom PHP builds as I do, not seeing *anything* > for undefined variables is a pretty big annoyance. > > Does anyone see an issue with making error_reporting=E_ALL the default in > PHP 8? It can of course still be manually downgraded via php.ini and > php.ini-production will retain the existing recommendation that excludes > E_DEPRECATED/E_STRICT. > > PR: https://github.com/php/php-src/pull/4659 By the way - I'd consider going a bit further than that, and re-sync our internal defaults with the values of php.ini-development. In the past - when we had -dist and -recommended - the intended behavior was that having php.ini-dist as your php.ini would be identical to not having a php.ini file at all. I think it can be useful if we do the same for php.ini-development (by changing the internal defaults to correspond to it of course, not the other way around) instead of having to agree individually on each change. For the future, agreeing on a change in php.ini-development would directly imply changing the internal defaults. Zeev --- ## #106813 — Arvids Godjuks — 2019-08-30T10:02:11+00:00 URL: https://externals.io/message/106810#106813 · In reply to: #106810 пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include > E_NOTICE. > > Thankfully distros do tend to have more reasonable defaults, but if you > spend as much time with custom PHP builds as I do, not seeing *anything* > for undefined variables is a pretty big annoyance. > > Does anyone see an issue with making error_reporting=E_ALL the default in > PHP 8? It can of course still be manually downgraded via php.ini and > php.ini-production will retain the existing recommendation that excludes > E_DEPRECATED/E_STRICT. > > PR: https://github.com/php/php-src/pull/4659 > > Regards, > Nikita > +1 from userland. I always have edited the php.ini for production. I also usually edit development too to include all error levels, but yeah - having shipped php.ini with sane defaults would be very welcome. I do agree with Zeev that production file should probably resemble what php.ini-development is right now, so I'd say we need to go deeper ;) -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius --- ## #106814 — Javier Spagnoletti — 2019-08-30T10:13:35+00:00 URL: https://externals.io/message/106810#106814 · In reply to: #106813 Great step! +1 Thank you so much Nikita. El vie., 30 de ago. de 2019 07:02, Arvids Godjuks escribió: > пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > > > […] > our > > […] > > +1 from userland. > > I always have edited the php.ini for production. I also usually edit > development too to include all error levels, but yeah - having shipped > php.ini with sane defaults would be very welcome. > I do agree with Zeev that production file should probably resemble what > php.ini-development is right now, so I'd say we need to go deeper ;) > > -- > Arvīds Godjuks > > +371 26 851 664 > arvids.godjuks@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius --- ## #106815 — Olumide Samson — 2019-08-30T11:26:42+00:00 URL: https://externals.io/message/106810#106815 · In reply to: #106814 +1 > Great step! +1 > Thank you so much Nikita. > > El vie., 30 de ago. de 2019 07:02, Arvids Godjuks < > arvids.godjuks@gmail.com> > escribió: > > > […] > thing > > […] > *anything* > > […] > in > > […] > excludes > > […] --- ## #106816 — G. P. B. — 2019-08-30T11:50:48+00:00 URL: https://externals.io/message/106810#106816 · In reply to: #106812 > > > […] > our > > […] > E_NOTICE. > > […] > > By the way - I'd consider going a bit further than that, and re-sync our > internal defaults with the values of php.ini-development. In the past - > when we had -dist and -recommended - the intended behavior was that having > php.ini-dist as your php.ini would be identical to not having a php.ini > file at all. I think it can be useful if we do the same for > php.ini-development (by changing the internal defaults to correspond to it > of course, not the other way around) instead of having to agree > individually on each change. For the future, agreeing on a change in > php.ini-development would directly imply changing the internal defaults. > > Zeev > -- > > I'm not sure we can totally execute on that otherwise we would need to change the default of the short_tag directive, which from my understanding was one of the pain points of the Short Tag RFC. Other than that I wholeheartedly agree that syncing the dev one with the defaults would be a good idea but then I'm not totally sure what it's point *would* be. Best regards George P. Banyard --- ## #106817 — Peter Kokot — 2019-08-30T13:13:17+00:00 URL: https://externals.io/message/106810#106817 · In reply to: #106816 Hello, > > > > > […] > > > I'm not sure we can totally execute on that otherwise we would need to > change the default of the short_tag directive, which from my understanding > was one of the pain points of the Short Tag RFC. > Other than that I wholeheartedly agree that syncing the dev one with the > defaults would be a good idea but then I'm not totally sure what it's point > *would* be. > > Best regards > > George P. Banyard About the error_reporting, I always set this to `E_ALL` for all environments also, yes. Syncing with the php.ini-production would probably make more sense because there are production environments that might not use any ini files (a bit of an edge case but when developing adding ini file seems more natural and secure than the other way around I think). The short opening tags ini directive of course will now stay different than the PHP internal default. -- Peter Kokot