Opened 9 years ago
Last modified 9 months ago
#31839 new enhancement
Setting error reporting level for wp_debug_mode
Reported by: | aifrim | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.1.1 |
Component: | Bootstrap/Load | Keywords: | dev-feedback |
Focuses: | Cc: |
Description
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.
Attachments (1)
Change History (11)
#1
follow-up:
↓ 2
@
9 years ago
- Keywords dev-feedback added
- Milestone changed from Awaiting Review to Future Release
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.
#2
in reply to:
↑ 1
@
9 years ago
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?
#5
@
11 months ago
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.
This ticket was mentioned in PR #5494 on WordPress/wordpress-develop by jonathan-dejong.
11 months ago
#6
- Keywords has-patch added
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
jonathan-dejong commented on PR #5494:
11 months ago
#8
Note that the failing check is welcoming new contributor 😅
https://github.com/WordPress/wordpress-develop/actions/runs/6531361467/job/17732454001?pr=5494
#9
@
9 months ago
I'm happy for anyone to join the discussion.
This is something I know me, the people I work with and many dev friends would love to see in some way, shape or form make it into core.
It would be very helpful in my opinion at least, to make the debug.log a productive part of every-day dev ops for WordPress Devs.
wp-incldues/load.php diff