Make error_reporting=E_ALL the default

  106810
August 30, 2019 09:32 nikita.ppv@gmail.com (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
  106811
August 30, 2019 09:37 zeev@zend.com (Zeev Suraski)
> On 30 Aug 2019, at 12:33, Nikita Popov ppv@gmail.com> wrote: > > 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
August 30, 2019 09:45 zeev@zend.com (Zeev Suraski)
> On 30 Aug 2019, at 12:33, Nikita Popov ppv@gmail.com> wrote: > > 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
  106816
August 30, 2019 11:50 george.banyard@gmail.com ("G. P. B.")
On Fri, 30 Aug 2019 at 11:45, Zeev Suraski <zeev@zend.com> wrote:

> > > On 30 Aug 2019, at 12:33, Nikita Popov ppv@gmail.com> wrote: > > > > 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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
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
August 30, 2019 13:13 peterkokot@gmail.com (Peter Kokot)
Hello,

On Fri, 30 Aug 2019 at 13:51, G. P. B. banyard@gmail.com> wrote:
> > On Fri, 30 Aug 2019 at 11:45, Zeev Suraski <zeev@zend.com> wrote: > > > > > > On 30 Aug 2019, at 12:33, Nikita Popov ppv@gmail.com> wrote: > > > > > > 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 > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > 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
  106813
August 30, 2019 10:02 arvids.godjuks@gmail.com (Arvids Godjuks)
пт, 30 авг. 2019 г. в 11:33, Nikita Popov ppv@gmail.com>:

> 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
August 30, 2019 10:13 phansys@gmail.com (Javier Spagnoletti)
Great step! +1
Thank you so much Nikita.

El vie., 30 de ago. de 2019 07:02, Arvids Godjuks godjuks@gmail.com>
escribió:

> пт, 30 авг. 2019 г. в 11:33, Nikita Popov ppv@gmail.com>: > > > 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 >
  106815
August 30, 2019 11:26 oludonsexy@gmail.com (Olumide Samson)
+1

On Fri, Aug 30, 2019, 11:13 AM Javier Spagnoletti <phansys@gmail.com> wrote:

> Great step! +1 > Thank you so much Nikita. > > El vie., 30 de ago. de 2019 07:02, Arvids Godjuks < > arvids.godjuks@gmail.com> > escribió: > > > пт, 30 авг. 2019 г. в 11:33, Nikita Popov ppv@gmail.com>: > > > > > 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 > > >