Add a new constant WP_DEBUG_LOG_LEVEL to resolve influx of Deprecation notices with PHP 8.n

[Jonathandejong]

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' );

[SergeyBiryukov]

Hi there, welcome back to WordPress Trac!

Thanks for the ticket, we're already tracking this enhancement in #31839.