Provide single logging functions to replace logIO(), debug_fwrite() etc.

I've lost motivation to follow this up. Closing.

You might not have, but I'm willing to take over. I think a new logging library that is pluggable or hookable is a great idea for inclusion into the core, along with WP_DEBUG.

Cool. In my very rough drafts I'd defined actions, and default functions to hook into those actions for initializing (open a file, connect to a database), writing to, and closing logs (close database connection, close file). That way logs to files, databases and other places could be handled.

Each call to the logging function took two arguments a "facility" and a message. I left it up to the functions hooked into the actions to decide if the data should be logged in that function. For example authentication related logs could be sent as log("AUTH",$message); and a hooked function to log authentication messages to MySQL could look out for "AUTH".

Main problem was in deciding the earliest point where I could elegantly call the initialization and closing actions whilst still having all the plugin functionality available. I hope my thoughts give some idea of what you might do, or what not to do.

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.

I can't think of any one solution that would best implement this, so I'm just going to develop each of my ideas and have the core team choose the best one that works best.

The ideas I have so far.

1. A file that is included if WP_DEBUG is defined and wp-content/debug.php exists. A function will exist that will call the functions in that file or fail if WP_DEBUG is not defined and wp-content/debug.php doesn't exist.

The reason for this method is that, you'll want the function definition early enough to catch any mistakes during the installation. This kind of prevents the functions going into pluggable.php.

2. If installation errors are not important, then a pluggable function can go into pluggable.php and can be used to replace the normal WordPress debug call. I'm thinking about doing this anyway.

3. Defining a function in wp-settings.php that is pluggable and can be replaced if wp-content/debug.php exists. This does mean that the function definition must exist in wp-content/debug.php also.

There you have it, three methods I'm unsure about which one is the best, so I'm just going to develop all three.

debug.php has what I have so far for the logging and display function. The method I decided on is 3 and I'm not finished with wp-settings.php nor the display function.

The work flow of the wp_log() is that it can be used in any file, but when plugins are loaded, it will allow for a plugin to prevent logging of a certain type and severity. Also the display function will display notices at the footer of the theme in a nice(?) format for the user to see. It also includes filters so that a plugin can alter the appearance.

The method for a plugin to replace the functionality, is to have a file in wp-content named debug.php, which has the definition wp_log() and wp_log_shutdown() as well as the constants in debug.php.

Once I'm done with debug.php, it needs more phpdoc inline documentation and need to finish up the display code for the footer.

wp-settings.php based off of r6713

Finished wp_log() function in new debug.php file.

I'm making the assumption that this can still get into 2.5, but I might be wrong. Needs further feedback.

Completed WordPress

The new debug.php is deadly awesome. However, it will completely bypass the plugin sandbox (sorry), so plugins which would normally fail, will now be caught by the WordPress logging API.

This can be useful as all non-critical errors will be caught by the Logging API and will allow the plugin author to fix all those errors. This will also mean that a plugin will be in theory able to log and process all WordPress errors to a file.

I need a second opinion as for improvements. I'm unsure I like how this is set up and would like to improve it.

Improved wp-settings.php file based off of latest trunk.

wp-includes debug.php file which contains the WordPress Logging API

Plugin which uses the WordPress Logging API

Updated WP_Logging API based off of r8535, uses pluggables instead.

Updated implementation to allow for a plugin to replace the logging.