Setting error reporting level for wp_debug_mode

[aifrim]

Since PHP 5.4.0 E_STRICT errors appear as part of E_ALL and headers cannot be sent sometimes - stuff that can lead to a whole set of problems. For me, they are useless and annoying - but for others they can be useful.

I just want the possibility to set the error_reporting level used in wp_debug_mode(). I have applied a small patch to load.php as shown below.

I have defined a WP_DEBUG_LEVEL constant in wp-config.php like so: define( 'WP_DEBUG_LEVEL', E_ALL & ~E_STRICT ); because I do not want to see the E_STRICT warnings.

Afterwards I modified the wp_debug_mode function like so:

function wp_debug_mode() {
        if ( WP_DEBUG ) {
                if( !defined( WP_DEBUG_LEVEL ) )
                    define( 'WP_DEBUG_LEVEL' , E_ALL) ;
                    
                error_reporting( WP_DEBUG_LEVEL  );

                if ( WP_DEBUG_DISPLAY )
                        ini_set( 'display_errors', 1 );
                elseif ( null !== WP_DEBUG_DISPLAY )
                        ini_set( 'display_errors', 0 );

                if ( WP_DEBUG_LOG ) {
                        ini_set( 'log_errors', 1 );
                        ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
                }
        } else {
                error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
        }
        if ( defined( 'XMLRPC_REQUEST' ) )
                ini_set( 'display_errors', 0 );
}

Here's the ​gist of it.

[aifrim]

wp-incldues/load.php diff

[jeremyfelt]

Hi @aifrim, thanks for the ticket!

I don't think a WP_DEBUG_LEVEL would hurt, though I wouldn't want to encourage devs to silence messages that should be seen during development. Could removing strict notices be enough?

Related: #24357, where the decision to show E_STRICT in PHP 5.4 was made (accepting that it may be too much).

Also, an old duplicate of introducing some sort of log level constant exists in #14371, where it was decided at the time to let things be.

[aifrim]

Replying to jeremyfelt:

Hi @aifrim, thanks for the ticket!

I don't think a WP_DEBUG_LEVEL would hurt, though I wouldn't want to encourage devs to silence messages that should be seen during development. Could removing strict notices be enough?

Related: #24357, where the decision to show E_STRICT in PHP 5.4 was made (accepting that it may be too much).

Also, an old duplicate of introducing some sort of log level constant exists in #14371, where it was decided at the time to let things be.

Hy @jeremyfelt,

First, I am sorry for not replying faster to your response. The notification email must have hit spam. You make valid points by not wanting to encourage developers to silence such messages during development.

I made this ticket in order to get rid of the STRICT messages. I have been working a while on a project and it is still in development. Part of its code requires non strict programming and I have allowed WordPress to auto update because I want to launch it with the last available version of WordPress.

So, how about a WP_DEBUG_NONSTRICT constant that disables E_STRICT warnings?

[SergeyBiryukov]

#50227 was marked as a duplicate.

[SergeyBiryukov]

#59128 was marked as a duplicate.

[Jonathandejong]

How can we finally make this a thing please?!

It's been 9 years. It is such a simple simple thing that means giving power back to the developer with absolutely no drawbacks.

Especially now when a lot of people are facing the necessity to upgrade from PHP 7.4 to 8.n and a lot of WordPress eco system not quite caught up yet this is really REALLY useful.

why? Because the way WP by default sets the error_reporting means every single deprecation notice is also logged. This makes the use of WP_DEBUG basically unusable unless we override it.

I detail this a bit more in my duplicate here: https://core.trac.wordpress.org/ticket/59128

I don't agree one bit with the argument that we shouldn't allow developers control over what error_reporting level is set.
Why should we not? It's not up to WP to decide that.
And even if we did entertain the idea that this could mean that developers silence important messages.. guess what? They already can.

I've seen in many poorly written plugins that the author overrides the error_reporting in runtime in their own code. Which is horrible of course, but it's already possible to do like this.
So why not give the developers that actually run their WP instance the control to do it appropriately.

Right now, we have to run a custom MU plugin to override the deprecation flood in order to be able to run PHP 8.n on our dev environments and still make use of WP_DEBUG.
If we don't, most sites throw tens of log entries for WP core and third party plugins which we cannot do anything about anyway.

What do I need to do to get this into core now?? Please.

My proposal is to add a new constant used in wp-includes/load.php changing the setting of error_reporting.

This would introduce the constant WP_DEBUG_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_LEVEL if that is set.

Trac ticket: https://core.trac.wordpress.org/ticket/31839

[Jonathandejong]

​https://github.com/WordPress/wordpress-develop/pull/5494

Note that the failing check is welcoming new contributor 😅
​https://github.com/WordPress/wordpress-develop/actions/runs/6531361467/job/17732454001?pr=5494