[wp-trac] [WordPress Trac] #59128: Add a new constant WP_DEBUG_LOG_LEVEL to resolve influx of Deprecation notices with PHP 8.n

[WordPress Trac]

#59128: Add a new constant WP_DEBUG_LOG_LEVEL to resolve influx of Deprecation
notices with PHP 8.n
-------------------------------+-----------------------------
 Reporter:  Jonathandejong     |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Bootstrap/Load     |    Version:  6.3
 Severity:  normal             |   Keywords:  dev-feedback
  Focuses:  php-compatibility  |
-------------------------------+-----------------------------
 == What problem does this address?


 While WordPress 6.3 supports PHP 8.n (8.0 and 8.1 specifically,
 https://make.wordpress.org/hosting/2023/05/15/is-wordpress-compatible-
 with-php-8/). There are still some Deprecation notices. Not to mention the
 crazy amount of Deprecation notices coming from third party plugins.

 All this means that people using WP_DEBUG are seeing a huge amount of
 logged deprecations in their logs or printed on their page if they upgrade
 to PHP 8.

 In many cases these aren't things that a developer of a specific WordPress
 project can do anything about and they primarily just pollute their
 primary means of debugging WordPress PHP.

 There's many forum posts etc. out there asking how to resolve this with
 some answers being to use a MU plugin to change the `error_reporting`
 level to overriding some filter hooks in wp-config. For example:
 https://wordpress.stackexchange.com/questions/406490/wordpress-6-x-php-8-x
 -deprecated-warnings-in-development-environment

 I argue that not being comfortable upgrading to PHP 8 due to inability to
 make use of WordPress standard (and only out-the-box) way of debugging
 your code is a security concern that WordPress can easily aid in
 resolving.



 == What is your proposed solution?


 My proposal is to add a new constant used in `wp-includes/load.php` on
 line 460 changing the setting of `error_reporting` from:
 {{{
 if ( WP_DEBUG ) {
                 error_reporting( E_ALL );

 }}}

 to

 {{{
 if ( WP_DEBUG ) {
                 if ( WP_DEBUG_LOG_LEVEL ) {
                         error_reporting( WP_DEBUG_LOG_LEVEL );
                 } else {
                         error_reporting( E_ALL );
                 }

 }}}

 This would introduce the constant `WP_DEBUG_LOG_LEVEL` which developers
 can use to set their own level of error reporting in `wp-config.php` while
 defaulting back to the same value it has always been in WordPress.

 It would not cause issues with any existing WordPress install.
 It would allow developers that want to upgrade to PHP 8 while still being
 able to use WP_DEBUG in their development environment.
 It would overall support the use of a single constant for a WordPress
 install to use for determining the desired error reporting level. This
 means that plugin developers can also use this constant to set their
 desired log level in their code. An example of a valid case of such can be
 found in the WP Sentry plugin where there's a constant called
 `WP_SENTRY_ERROR_TYPES` used.
 This could default to using `WP_DEBUG_LOG_LEVEL` if that is set.

 An example of it used in `wp-config.php`:

 {{{
 define( 'WP_DEBUG', true );
 define( 'WP_DEBUG_LOG', true );
 define( 'WP_DEBUG_LOG_LEVEL', 'E_ALL & ~E_DEPRECATED' );
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59128>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform