[wp-trac] [WordPress Trac] #14371: Allow user to specify error reporting level

[WordPress Trac]

#14371: Allow user to specify error reporting level
------------------------------+---------------------------------------------
 Reporter:  wjm               |       Owner:                 
     Type:  enhancement       |      Status:  new            
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Warnings/Notices  |     Version:  3.0            
 Severity:  normal            |    Keywords:  has-patch      
------------------------------+---------------------------------------------

Comment(by nacin):

 Replying to [comment:7 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
 [http://wordpress.org/extend/plugins/log-deprecated-notices/ 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14371#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software