Ticket #5669 (assigned enhancement)

Opened 8 months ago

Last modified 1 month ago

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

Reported by: pishmishy Assigned to: jacobsantos (accepted)
Priority: normal Milestone: 2.9
Component: General Version: 2.3.2
Severity: normal Keywords: 2nd-opinion has-patch needs-testing logging logIO debug_fwrite debug dev-feedback
Cc: westi

Description

I'm looking at writing a logging infrastructure so that logIO() and debug_fwrite() can be consolidated into a single plugin replacable function (giving potential expansion into MySQL or syslog logging). I hope to follow this up with calls to the same function so administrative access can leave an audit trail.

Attachments

5669.wp-settings.diff (0.8 kB) - added by darkdragon on 02/04/08 07:10:21.
wp-settings.php based off of r6713
debug.php (9.9 kB) - added by darkdragon on 02/04/08 07:19:22.
Finished wp_log() function in new debug.php file.
debug.2.php (12.3 kB) - added by santosj on 02/05/08 02:48:31.
Completed WordPress
5669.wp-settings.2.diff (407 bytes) - added by darkdragon on 02/05/08 06:35:22.
Improved wp-settings.php file based off of latest trunk.
debug.3.php (9.4 kB) - added by darkdragon on 02/05/08 06:36:11.
wp-includes debug.php file which contains the WordPress Logging API
debug.4.php (3.7 kB) - added by darkdragon on 02/05/08 06:38:54.
Plugin which uses the WordPress Logging API
5669.r8535.patch (4.6 kB) - added by santosj on 08/04/08 20:26:34.
Updated WP_Logging API based off of r8535, uses pluggables instead.

Change History

01/14/08 20:43:40 changed by pishmishy

  • status changed from new to assigned.

01/30/08 12:56:48 changed by pishmishy

  • status changed from assigned to closed.
  • resolution set to invalid.
  • milestone deleted.

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

01/30/08 13:24:20 changed by darkdragon

  • status changed from closed to reopened.
  • resolution deleted.

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.

01/30/08 13:24:25 changed by darkdragon

  • milestone set to 2.6.

01/30/08 13:24:58 changed by darkdragon

  • owner changed from pishmishy to darkdragon.
  • status changed from reopened to new.

01/30/08 13:59:43 changed by pishmishy

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.

01/31/08 06:00:56 changed 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.

02/03/08 23:53:41 changed by darkdragon

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.

02/04/08 06:41:44 changed by darkdragon

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.

02/04/08 07:10:21 changed by darkdragon

  • attachment 5669.wp-settings.diff added.

wp-settings.php based off of r6713

02/04/08 07:19:22 changed by darkdragon

  • attachment debug.php added.

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

02/04/08 07:20:12 changed by darkdragon

  • keywords changed from logging logIO debug_fwrite dubug audit dev-feedback to 2nd-opinion has-patch needs-testing logging logIO debug_fwrite dubug audit dev-feedback.

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

02/05/08 02:48:31 changed by santosj

  • attachment debug.2.php added.

Completed WordPress

02/05/08 02:52:34 changed by santosj

  • keywords changed from 2nd-opinion has-patch needs-testing logging logIO debug_fwrite dubug audit dev-feedback to 2nd-opinion has-patch needs-testing logging logIO debug_fwrite debug dev-feedback.

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.

02/05/08 06:35:22 changed by darkdragon

  • attachment 5669.wp-settings.2.diff added.

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

02/05/08 06:36:11 changed by darkdragon

  • attachment debug.3.php added.

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

02/05/08 06:38:54 changed by darkdragon

  • attachment debug.4.php added.

Plugin which uses the WordPress Logging API

03/10/08 20:41:50 changed by westi

  • cc set to westi.

07/17/08 04:58:39 changed by jacobsantos

  • owner changed from darkdragon to jacobsantos.

07/17/08 04:58:42 changed by jacobsantos

  • status changed from new to assigned.

08/04/08 20:26:34 changed by santosj

  • attachment 5669.r8535.patch added.

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

08/04/08 20:27:37 changed by santosj

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