Allow user to specify error reporting level

[wjm]

I have noticed that there is little control over the error reporting level that you can set,

you can set error_reporting() in your wp-config.php file, but it will be overriden in load.php (called by wp-settings.php) by wp_debug_mode();

this introduces a WP_ERROR_REPORTING constant, that will be checked and if set, error reporting will be set to that value.
either in WP_DEBUG mode or not.

so for example the, in the wp-config.php of the production installation, you use it like this,

define( 'WP_ERROR_REPORTING', ( E_CORE_ERROR | E_COMPILE_ERROR | E_ERROR | E_PARSE | E_USER_ERROR ) );

And it will throw no warning messages at all.

This is also useful in conjunction with WP_DEBUG and WP_DEBUG_LOG, as you will be able to specify the error level and also log any errors.

[nacin]

If we are to do this, what about requiring the use of WP_DEBUG to set this, and then having WP_DEBUG_LEVEL?

[wjm]

I am not sure about that, as WP_DEBUG right now is associated with developement installations not with productions ones, and this level may be used for production servers.

[Viper007Bond]

Replying to wjm:

I am not sure about that, as WP_DEBUG right now is associated with developement installations not with productions ones, and this level may be used for production servers.

Errors shouldn't be shown in production environments.

[wjm]

@Viper007Bond: As it is right now FATAL and WARNING errors are showed in production.
I think it's up to people to decide what they want to show.

I only want fatal errors to be displayed in production environments.
Other people will want both.
and some none.

[nacin]

Replying to wjm:

@Viper007Bond: As it is right now FATAL and WARNING errors are showed in production.
I think it's up to people to decide what they want to show.

That's not true. Fatals and warnings are reported. As long as WP_DEBUG is not set, then we don't touch the php.ini display_errors directive, which on a production server should be off.

At this point I'm -1 on this (unless it is tied to WP_DEBUG, possibly). There's an obvious potential that it would be misused to simply lower the reporting level instead of suppressing the display of warnings the proper way. Errors should be logged, not displayed, and errors we report (warnings/fatals) by default are the kinds that absolutely should be reported and logged.

[wjm]

Replying to nacin:

At this point I'm -1 on this (unless it is tied to WP_DEBUG, possibly). There's an obvious potential that it would be misused to simply lower the reporting level instead of suppressing the display of warnings the proper way. Errors should be logged, not displayed, and errors we report (warnings/fatals) by default are the kinds that absolutely should be reported and logged.

I was missing something. thanks Nacin for pointing it out.
I have read your articles about using WP_DEBUG ​http://www.andrewnacin.com/2010/04/23/5-ways-to-debug-wordpress/ and ​http://www.andrewnacin.com/2010/03/22/deprecated-functions-and-wp_debug/ and i understand the situation better.

Again, errors are displayed because by default wordpress doesn't set display_errors off in non-debuging mode.
That is what may be confusing people.

I always had WP_DEBUG off, because if I turned it off, I would get so many E_NOTICE errors that will be impossible to fix. That is confusing too, I think developers stay away from WP_DEBUG because of this,

I see it can be very useful to have this feature in conjuction with WP_DEBUG (to avoid the issues stated above) and there may be no need to have it outside of it.

Some ideas come into my mind.

1. Shouldn't be setting display_errors off when not in debug mode?
2. I see it as a security issue to have a fixed file name for the debug.log file. Maybe a constant can be defined to set its filename or maybe use a secret suffix.

[nacin]

Replying to wjm:

Again, errors are displayed because by default wordpress doesn't set display_errors off in non-debuging mode.
That is what may be confusing people.

Perhaps. It is also confusing in the context of WP_DEBUG_DISPLAY, which even if set to *false* does not actually force display_errors off; it only prevents WordPress from forcing it on.

I always had WP_DEBUG off, because if I turned it off, I would get so many E_NOTICE errors that will be impossible to fix. That is confusing too, I think developers stay away from WP_DEBUG because of this,

Also probably the case. But the notices are the main aspect to WP_DEBUG. (For deprecated functionality, which are also fired, I would recommend my ​Log Deprecated Notices plugin which does not require WP_DEBUG to be on.)

1. Shouldn't be setting display_errors off when not in debug mode?

We leave it up to the local configuration. It makes sense as WP_DEBUG is not really an on or off state, it's more like an on state or let the server handle itself state.

2. I see it as a security issue to have a fixed file name for the debug.log file. Maybe a constant can be defined to set its filename or maybe use a secret suffix.

Security by obscurity doesn't do much. It would need to be outside public_html. Point is, WP_DEBUG is designed for development only, and WP_DEBUG_LOG is *certainly* development only. Many do run WP_DEBUG on production, but then use the php.ini directive for error logs, versus WP_DEBUG_LOG.

That said, I would not go so far as to call WP_DEBUG_LOG on a production site (not recommended!) a security issue. It is, but that brings us back to display_errors, which is also a security issue. In an ideal production setup (to me, anyway):

display_errors = false
error_log = path to private log
WP_DEBUG = true
WP_DEBUG_DISPLAY = false
WP_DEBUG_LOG = false (the default)

That's also an ideal setup for development for many, as they then tail the log. (debug.log also works here.)

There's a lot of tickets that discuss these constants, ranging from their initial introduction to tickets similar to this one, where I have gone through long explanations on optimal setups and why things are the way they are.

[wjm]

Thanks nacin for your time and explanations,
I didn't mean you to repeat yourself ;-)
it is much clearer now.

So...
Shall I submit a new patch that will only work when WP_DEBUG is on.
Do you think WP_DEBUG_LEVEL is a good name?

[nacin]

I'm wondering if, at the risk of introducing another confusing boolean in this family, WP_DEBUG_NOTICES (default true) is best. It should probably not suppress deprecated notices however.

Then again, I'm really not sure what the benefits are of WP_DEBUG if it doesn't reveal notices as well. You can just as easily change the display_errors and error_log directives to your liking. And, as I said previously, I don't see why our default error reporting threshold would need to be raised.

[wjm]

well, the benefit is that will have more control over what is to be displayed when WP_DEBUG is on.
I would not turn WP_DEBUG on as it works right now, as I need to see error messages on screen, but not that many! (so it is not about not revelaing notices, it is about revealing a reasonable amount)
so in response to that i endup not using WP_DEBUG and i think the whole idea is to use it in development.

Maybe we should give it a little bit of time to see other people's responses...

[scribu]

As discussed on wp-hackers, if you don't want to see notices, just call error_reporting() in wp-config.php instead of setting WP_DEBUG.

No need to reinvent the wheel. Suggest closing as worksforme.

[wjm]

Replying to scribu:

As discussed on wp-hackers, if you don't want to see notices, just call error_reporting() in wp-config.php instead of setting WP_DEBUG.

No need to reinvent the wheel. Suggest closing as worksforme.

Scribu, that is what I thought too, but that is not what happens.

you can set error_reporting() in your wp-config.php file, but it will be overriden in load.php (called by wp-settings.php) by wp_debug_mode();

wp_debug_mode() will override whatever you set in wp-config.php .
that is what this patch tries to solve.

[hakre]

Each time wordpress is loaded (done by including load.php) wp_debug_mode() will be called. In any case, WP_DEBUG being true or false, the configured error_reporting() setting will be overwritten.

There is no method until now to prevent this - as reported in this ticket. This is still teh case.

But it should be much easier to circumvent that shortcomming.

I suggest to introduce WP_DEBUG being 'CONFIG' (a string) to leave over the configuration to the system settings. I'll add a patch to illustrate that.

It then possible to use the own error_reporting setting directive(s) in wp-config.php or inside the php.ini and to signal wordpress core to not bother with stuff.

My patch does not reflect all the places which check for WP_DEBUG for any type and not bool in specific so far.

[hakre]

Full Patch, incl. WP_DEBUG usage.

[hakre]

Those who want to configure error reporting only need to set WP_DEBUG to 'CONFIG' and they are done (this patch applied).

If you need to track errors that are (still) supressed (some supressions are prevented by WP_DEBUG = 'CONFIG' but not all), you need to create your own error handler.

That can be an option as well in case you don't want to deal with the ini settings. The error handler can be called all the time regardless wether something is not reported as by ini/configuration and/or supression:

​set_error_handler()
​error_reporting()
​display_errors directive