[wp-trac] Re: [WordPress Trac] #5669: Provide single logging functions to replace logIO(), debug_fwrite() etc.

[WordPress Trac]

#5669: Provide single logging functions to replace logIO(), debug_fwrite() etc.
-----------------------------------------------------------------+----------
 Reporter:  pishmishy                                            |        Owner:  darkdragon
     Type:  enhancement                                          |       Status:  new       
 Priority:  normal                                               |    Milestone:  2.6       
Component:  General                                              |      Version:  2.3.2     
 Severity:  normal                                               |   Resolution:            
 Keywords:  logging logIO debug_fwrite dubug audit dev-feedback  |  
-----------------------------------------------------------------+----------
Comment (by darkdragon):

 Indeed. Thanks for the inspiration. I think with that, we have similar
 ideas, however what I envision probably won't be realized until probably
 2.6, like the wpdb::prepare(). If I can at least get the function in, then
 plugins can also use it whereas it might be another few versions before
 the entire !WordPress code base does.

 I'll have more to show (as patches) later, so if you're willing to give
 more feedback, it would be appreciated. I'm basically looking to replace
 all of the error handling methods in !WordPress and unify them, where a
 plugin can either log them to a file, database, or email them.

 As an addendum, I think also having severity, like in !OpenAds might be
 beneficial. You know, using obsolete functions might be a higher severity
 than just using deprecated ones. So the user and plugin can choose whether
 to log the ones based on the severity of the problem.

 I think the best thing however, is giving the user and plugins the power
 whether to run the logging. For me, I think if WP_DEBUG is not defined,
 then all debugging functions should just back out and silently fail. In
 this way, very little overhead will affect the !WordPress code and will
 still allow extreme amount of information when WP_DEBUG is defined on
 testing environments.

 Which is what I want out of this ticket. A way to not display warnings and
 notices, but still get that information without looking at some PHP/Apache
 log file I may or may not have access to.

 Also, if WP_DEBUG is on, I really don't think performance is an issue, but
 I think this is something that will have to be profiled when WP_DEBUG is
 off to make sure that performance of !WordPress is not adversely affected
 to deeply by any "enhancement."

 It is also highly possible that this will be bumped to 2.6 anyway, because
 of its enhancement status and how close it is to 2.5 release. Oh well, I
 think having a patch will at least give the next person an idea of where I
 want to go and conversation on where any future patches should go. The
 implementation shouldn't be that difficult.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/5669#comment:7>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software