config: change the default error reporting level in production

[kenjis]

Description
There is no reason to change error level only in production.

In production, you may wish to set this to a less verbose level such as E_ALL & ~E_NOTICE & ~E_DEPRECATED, but in many cases E_ALL is also appropriate, as it may provide early warning of potential issues.
https://www.php.net/manual/en/language.errors.basics.php#language.errors.basics.handling

Checklist:

• Securely signed commits
• [] Component(s) with PHPDoc blocks, only if necessary or adds value
• [] Unit testing, with >80% coverage
• [] User guide updated
• Conforms to style guide

[michalsn]

I kindly disagree. In a production environment, we generally want to suppress certain types of errors and notices that will not impact the end user. This could potentially cause our logs to grow to horrible sizes. Also, the readability of logs would suffer.

Early warning and issues should be caught in a development environment or potentially in staging.

[kenjis]

Thanks for your comment.

I don't believe PHP's error level can tell the errors and notices will impact the end user or not.
In development environment, if a NOTICE is issued, it will be an ErrorException and it will stop the app.
It would be more frightening if the app continues to run without stopping in spite of the errors.
Personally, I don't like the behavior to change only in production environment.
We can't test that behavior in development/testing environment.

Of course, if your app works already with Warnings and Notices, you need to suppress errors.
You can do it with your config file.
However, I do not believe that such apps should be assumed as the default for the framework.

[github-actions]

👋 Hi, @kenjis!

We detected conflicts in your PR against the base branch 🙊
You may want to sync 🔄 your branch with upstream!

Ref: Syncing Your Branch

[MGatner]

I don't know that this is a place for the framework to exert a strong opinion. What are the defaults these days in production versus development php.ini files? I would consider either mirroring those or commenting this out entirely to pass handling to the INI.

[kenjis]

; error_reporting
;   Default Value: E_ALL
;   Development Value: E_ALL
;   Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

https://github.com/php/php-src/blob/a80b6d7b99ae885cb450a563a788f57917cef74e/php.ini-production#L107-L110

See https://wiki.php.net/rfc/reclassify_e_strict

[MGatner]

Hmm interesting. So it looks like E_STRICT doesn't do anything. So if we wanted to match php.ini in a >= PHP7 manner it would be:

E_ALL & ~E_DEPRECATED

That seems reasonable to me since deprecations are frequently unavoidable in production (I have third-party libraries trigger them all the time). There's a certain weight of argument though to the fact that we've been suppressing these since alpha 1.

[kenjis]

Okay, that seems reasonable. Changed to E_ALL & ~E_DEPRECATED.

[github-actions]

👋 Hi, @kenjis!

We detected conflicts in your PR against the base branch 🙊
You may want to sync 🔄 your branch with upstream!

Ref: Syncing Your Branch

[kenjis]

Rebased to resolve conflict.

[MGatner]

Good by me! @michalsn any further pushback?