andrewwoods / wp-debug-logger Goto Github PK

Allow my plugin user to specify a constant in their wp-config to determine the minimum log level for writing. On production i'd recommend "error", then notice for "staging", then "debug" in their development environment

Only try to write the wp-content/debug.log file when WP_DEBUG and WP_DEBUG_LOG constants are both true. Without respecting these constants, the users logfile will needlessly fill up. This would be bad in a production environment. Users should have confidence in their settings.

The wp-content/debug.log will represent the syslog.

Add an email channel for when things go really bad. At least one person should get emailed, maybe more.

Other possible channels:

• DIscord
• Slack
• Twilio via SMS
• Vonage via SMS

Provide instructions on how to update wp-config.php constants for normal local debugging. Make it easy for developers so they don't have to search the web for debugging instructions.

On occassion, you need to var_dump a variable with an unknown structure. Passing the var_dump value to one of the standard log level methods will add a level of structure - which is not ideal. Create a separate method named dump.

Describe the problem you want to solve

Problem: The $context parameter in the log methods only supports passing an array of data.

Background:
It is not currently possible to (sanely) pass a WP_Error object to the $context parameter in any of the log methods outside of passing it inside an array in order to adhere to the typehinting rules.

A central feature of error logging in WordPress is the ability to leverage the WP_Error object to log errors against, and I would think a WordPress logger utility should handle for that eventuality as elegantly as it can.

Describe the solution you'd like

Ideally, $context would be allowed to accept mixed types: either an array or WP_Error object. Naturally, such a change would mean the typehinting on the $context parameter in all of the logging method signatures would have to be dropped.

Describe alternatives you've considered

I've been using a sort of simplified version of a logger similar to this one in private and commercial WordPress products for years. When our $data parameter (similar in use to $context) was initially introduced, it was blind to the input, I think it just supported any kind of input and was output as a string similarly to how the new dump() method introduced in #6 works.

At a certain point, DRY principles necessitated adding WP_Error support to handle for first- and third-party integrations that returned WP_Error object. This feature was initially implemented to support WP_Error objects containing just a single error, though it was later expanded to handle for WP_Error objects containing multiple different errors that could be "collated" together into a cohesive string of output.

Additional context

Changing $context to accept something other than an array (and dropping the array typehints) would constitute a break in backward compatibility for anyone extending the Log or Logger classes.

On occassion, you need to print_r a variable with an unknown structure. Passing the print_r value to one of the standard log level methods will add a level of structure - which is not ideal. Create a separate method named print.