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

[Philip M. Hofer (Frumph)]

I'm going to jump in for a second.  The notices and warnings that are shown 
can sometimes have consequences that do not give fatal errors, some notices 
that say passing wrong property type are very important to fix in someones 
code.   Not to mention deprecated messages and the such.   Disabling those 
will be more of a hinderance to a developement machine since ALL of those 
are there for a purpose and developers need to adjust their code 
appropriately when they are found.

I guess this is to Andrew, wordpress itself does not give warnings or 
notices, they are coming from your plugins and themes, that of which when 
they are developed need to be fixed so that those messages do not appear by 
fixing their code.

The most common of which is the undefined index notice, basically thats just 
checking if the index exists first if you use it,  if 
(isset($someindex['indexname']) && ($someindex['indexname'] == 'blahblah')) 
{


----- Original Message ----- 
From: "Jeremy Clarke" <jer at simianuprising.com>
To: <wp-hackers at lists.automattic.com>
Sent: Sunday, January 02, 2011 10:55 AM
Subject: Re: [wp-hackers] Better Error Handling for both Development and 
Production Servers


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

>
> 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.
>
>
I've found that adding the following core-PHP definitions into wp-config.php
has the effect of showing me errors rather than the WSOD, but not all the
notices that WP_DEBUG spits out:

ini_set('display_errors', 1);
error_reporting (E_ALL);
ini_set('display_startup_errors','1');

Why not just use that on your dev installs?

Despite that I'd still favor some configurability for WP_DEBUG, maybe with
some secondary constant like WP_DEBUG_NOTICES which you could set to false
to disable them.

I personally use WP_DEBUG as much as possible and love the notices it
generates for my plugins but unless you're only working with core and no
external plugins the effect is that you are bombarded with warnings from
plugins you don't control (e.g. Supercache, proof that even core
contributors generate notices sometimes). I send out emails to the plugin
authors a lot but some are ignored and others take a long time to implement
the fixes.

Nacin is right that for your own plugins you should eliminate all notices.
It is easy to do and at least in my case I find and easily fix lots of "real
bugs" while going through and cleaning up the various "aesthetic bugs"
identified by WP_DEBUG and causing notices.

Disabling all plugins other than "the one you are working on" is often an
undesirable hack, as you end up not seeing the problematic interactions
between your plugin and the ones it will co-exist with until they are
running together on the live server. Taking Supercache as an example I think
we can all imagine how this is not ideal.

I'm not sure if we really need a solution other than GEEZ GUYS PLEASE TURN
ON WP_DEBUG AND FIX THE NOTICES IN YOUR PLUGINS but having one would be
nice. My fantasy would be that notices remain active for *my plugin* but not
others installed on the site (i.e. that while developing I can somehow flag
plugins that I am actively working on). I am not good enough at PHP to think
of a good way to do so though, so maybe that idea can just serve as an
unpractical solution to put possible but less-effective ones in perspective.

-- 
Jeremy Clarke • jeremyclarke.org
Code and Design • globalvoicesonline.org
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers