[wp-hackers] Better Error Handling for both Development and Production Servers

Andrew Nacin wp at andrewnacin.com
Fri Dec 31 21:05:56 UTC 2010

On Fri, Dec 31, 2010 at 3:37 PM, Andrew Gray <andrew at graymerica.com> wrote:

> Does anyone think that a patch for an improved error handler in
> wp-includes/load.php would be well received or implemented into the core.
> I would love a setting to only show Fatal / parse errors when developing.
>  Something that only show these errors and ignores all the deprecated,
> notices and other errors that come from plugins and from the core wordpress
> when I was developing.  Or at lease improve the options available for
> WP-config from DEBUG only.

Parse errors can't be suppressed during runtime. Why would you want to
suppress E_WARNING though? The only use case really for suppressing E_NOTICE
is if *other* plugins are spitting out a ton of notices. But if you're
developing on just core and your plugin, then you should really want to
prevent all E_NOTICE issues. (If you ever find one in core, *please* report

Thus, this really just comes down to WP_DEBUG versus not. If WP_DEBUG is on,
you get all notices. If it's off, you don't get any notices. What's the
third option you're looking for?

Also, an error handler for production websites that is something other than
> a blank page.    Something with a little data or that could be customized
> with a theme.  I was thinking of using
> http://php.net/manual/en/function.set-error-handler.php  and a shutdown
> function (when possible) to improve the user experience.

display_errors should never be enabled on a production site. You should log
these instead, via the php.ini error_log setting. If you really want to use
an error handler or shutdown function, you can do that yourself for sure.

> Of course all of this would be optional, and not included in the code
> unless people turn it on.
> Also if you enable define('E_DEPRECATED', false) ; I get a Fatal error:
> Unsupported operand types in ****/wp-includes/load.php on line 260

You shouldn't define E_DEPRECATED. It's a core PHP constant. We're only
doing that to detect whether you're on PHP 5.3 or not. I just committed this
comment to trunk: http://core.trac.wordpress.org/changeset/17194, so I hope
that helps.

Does anyone think that if I worked up a patch for all this, it would be
> accepted.

Improvements here would certainly be considered. Could you read through my
feedback and re-propose what you'd like to see?


More information about the wp-hackers mailing list