WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 4 years ago

Last modified 3 years ago

#5669 closed enhancement (wontfix)

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

Reported by: pishmishy Owned by:
Milestone: Priority: low
Severity: minor Version: 2.3.2
Component: Bootstrap/Load Keywords: debug needs-patch
Focuses: Cc:

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 (7)

5669.wp-settings.diff (819 bytes) - added by darkdragon 10 years ago.
wp-settings.php based off of r6713
debug.php (9.9 KB) - added by darkdragon 10 years ago.
Finished wp_log() function in new debug.php file.
debug.2.php (12.3 KB) - added by santosj 10 years ago.
Completed WordPress
5669.wp-settings.2.diff (407 bytes) - added by darkdragon 10 years ago.
Improved wp-settings.php file based off of latest trunk.
debug.3.php (9.4 KB) - added by darkdragon 10 years ago.
wp-includes debug.php file which contains the WordPress Logging API
debug.4.php (3.7 KB) - added by darkdragon 10 years ago.
Plugin which uses the WordPress Logging API
5669.r8535.patch (4.6 KB) - added by santosj 10 years ago.
Updated WP_Logging API based off of r8535, uses pluggables instead.

Download all attachments as: .zip

Change History (32)

#1 @pishmishy
10 years ago

  • Status changed from new to assigned

#2 @pishmishy
10 years ago

  • Milestone 2.6 deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

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

#3 @darkdragon
10 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

#4 @darkdragon
10 years ago

  • Milestone set to 2.6

#5 @darkdragon
10 years ago

  • Owner changed from pishmishy to darkdragon
  • Status changed from reopened to new

#6 @pishmishy
10 years ago

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.

#7 @darkdragon
10 years ago

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.

#8 @darkdragon
10 years ago

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.

  1. 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.
  1. 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.

#9 @darkdragon
10 years ago

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.

@darkdragon
10 years ago

wp-settings.php based off of r6713

@darkdragon
10 years ago

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

#10 @darkdragon
10 years ago

  • Keywords 2nd-opinion has-patch needs-testing added

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

@santosj
10 years ago

Completed WordPress

#11 @santosj
10 years ago

  • Keywords debug added; dubug audit removed

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.

@darkdragon
10 years ago

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

@darkdragon
10 years ago

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

@darkdragon
10 years ago

Plugin which uses the WordPress Logging API

#12 @westi
10 years ago

  • Cc westi added

#13 @jacobsantos
10 years ago

  • Owner changed from darkdragon to jacobsantos

#14 @jacobsantos
10 years ago

  • Status changed from new to assigned

@santosj
10 years ago

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

#15 @santosj
10 years ago

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

#16 @jacobsantos
10 years ago

BackPress already implements something like this. Will have to check that to see what solution it provides.

#17 @jacobsantos
10 years ago

Confirmed, BP_Logging can be used for WordPress and will create patch for that.

#18 @jacobsantos
10 years ago

  • Keywords needs-patch added; 2nd-opinion has-patch needs-testing logging logIO debug_fwrite dev-feedback removed

#19 @jacobsantos
9 years ago

  • Owner jacobsantos deleted
  • Status changed from assigned to new

#20 @Denis-de-Bernardy
9 years ago

  • Component changed from General to Warnings/Notices
  • Priority changed from normal to low
  • Severity changed from normal to minor

#21 @Denis-de-Bernardy
9 years ago

  • Milestone changed from 2.9 to Future Release

#22 @hakre
8 years ago

As an alternative suggestion, which does not need a new infrastructure:

Error logging is handeled with wordpress debug / php logging settings. Error logging can be enabled in wordpress (or PHP settings). Errors can be triggered by the trigger_error function, which also will put errors to the log if logging is enabled.

#23 @giuliom
7 years ago

  • Cc giulio.mainardi@… added

#24 @nacin
4 years ago

  • Component changed from Warnings/Notices to Bootstrap/Load
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

There seems to be no traction for a logging interface for the moment.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.