[wp-hackers] DEBUG config and blocking notices

[Mike Schinkel]

On Jul 19, 2010, at 3:02 PM, Andrew Nacin wrote:
> On Mon, Jul 19, 2010 at 2:56 PM, Jeremy Clarke <jer at simianuprising.com>
> wrote:
> 
>> If you don't want notices then you shouldn't be using WP_DEBUG.
> 
> But you should want notices. Just saying.
> 
> Speficially, running WP_DEBUG is pretty much mandatory for any core
>> development
> 
> because all the core devs have it turned on
> 
> Also true.
> 
> Writing your own code to not generate notices is easy and good for business
> in all kinds of ways. The process of declaring/checking your variables
> before use leads you to avoid a lot of mysterious and rare bugs down the
> line, and helps you clean up your code in the process.

Andrew & Jeremy,

I can't speak for Andrew Gray but I think one of the reasons he might be interested in just errors is because that many (most?) plugins were not developed with WP_DEBUG and spew lots of errors.  So while it may be a great idea to use WP_DEBUG when hacking on core or building a plugin in a vacuum, it is often impractical when working on plugins or themes on real world website implementations.  So in general I (am rarely in a position where I can) develop with it.

OTOH I'd really *prefer* to using WP_DEBUG but what is stopping me are the plugins the client wants or needs that were not coded with WP_DEBUG.  Part of the problem is that very few places recommend WP_DEBUG (I didn't even learn about it until a few months ago by reading someone else's off-hand remark on the hackers list) but more importantly there is no place in the WordPress.org repositories where a plugin or  theme can be lauded for their use of WP_DEBUG.  For the "3.org" refresh, Is there a way we can automatically verify which plugins actually do support WP_DEBUG and which do not?  That would go a huge way towards allowing us to actually use WP_DEBUG when developing for real world implementations

-Mike
P.S. I tried it again and it seems that it even throughs errors in core code (or at least it seems that way.)  The following error came from my call to add_submenu_page() in an admin_menu hook:

Notice: has_cap was called with an argument that is <strong>deprecated</strong> since version 2.0! Usage of user levels by plugins and themes is deprecated. Use roles and capabilities instead. in /Users/mikeschinkel/Sites/client/trunk/wp-includes/functions.php on line 3321

Call Stack:
    0.0007     740168   1. {main}() /Users/mikeschinkel/Sites/client/trunk/wp-admin/admin.php:0
    0.3520   32696800   2. require('/Users/mikeschinkel/Sites/client/trunk/wp-admin/menu.php') /Users/mikeschinkel/Sites/client/trunk/wp-admin/admin.php:93
    0.3663   32754208   3. do_action() /Users/mikeschinkel/Sites/client/trunk/wp-admin/menu.php:328
    0.3671   32738840   4. call_user_func_array() /Users/mikeschinkel/Sites/client/trunk/wp-includes/plugin.php:395
    0.3671   32738872   5. WP_InitializeSite::admin_menu() /Users/mikeschinkel/Sites/client/trunk/wp-includes/plugin.php:0
    0.3671   32739264   6. add_submenu_page() /Users/mikeschinkel/Sites/client/trunk/wp-content/plugins/wp-initialize-site/wp-initialize-site.php:67
    0.3672   32739840   7. current_user_can() /Users/mikeschinkel/Sites/client/trunk/wp-admin/includes/plugin.php:929
    0.3672   32740712   8. call_user_func_array() /Users/mikeschinkel/Sites/client/trunk/wp-includes/capabilities.php:1067
    0.3672   32741096   9. WP_User->has_cap() /Users/mikeschinkel/Sites/client/trunk/wp-includes/capabilities.php:0
    0.3673   32741416  10. _deprecated_argument() /Users/mikeschinkel/Sites/client/trunk/wp-includes/capabilities.php:722
    0.3673   32741928  11. trigger_error() /Users/mikeschinkel/Sites/client/trunk/wp-includes/functions.php:3321