README

BH WP Logger

Zero-config logger UI for WordPress plugins.

$logger = Logger::instance();

Wraps existing PSR-3 loggers and adds some UI.

Uses KLogger by default, WC_Logger when specified, NullLogger when log level is set to "none".

Uses PHP's set_error_handler() to catch PHP deprecated/warning/notice/errors.

Hook into WordPress's deprecated function hooks (deprecated_function_run etc.) to log those only once per day.

Uses PHP's register_shutdown_function() to catch Exceptions related to the plugin.

Deletes log files older than 30 days on cron.

Records a full backtrace on errors. Records two steps of backtrace on every log when the level is Debug.

UI

Displays logs in WP_List_Table.

Shows a dismissible admin error notice each time there is a new error.

Adds a link to the logs view on the plugin's entry on plugins.php.

When log messages contain `wp_user:123` (NB: surrounded by single backticks) it will be replaced with a link to the user profile. This allows for logging useful references to users without logging their PII.

Similarly, any post type can be linked with `post_type_name:123`, e.g. `shop_order:123` will link to the WooCommerce order.

Use

Composer

composer require brianhenryie/bh-wp-logger

Expect breaking changes with every release until v1.0.0.

Instantiate

You should use brianhenryie/strauss to prefix the library's namespace. Then Strauss's autoloader will include the files for you.

The following will work, but it will be faster and more reliable to provide the settings:

$logger = Logger::instance();

Provide the settings:

$logger_settings = new class() implements BrianHenryIE\WP_Logger\API\Logger_Settings_Interface {
    use BrianHenryIE\WP_Logger\Logger_Settings_Trait;
    
	public function get_log_level(): string {
		return LogLevel::INFO;
	}

	// This is used in admin notices.
	public function get_plugin_name(): string {
		return "My Plugin Name";
	}

	// This is used in option names and URLs.
	public function get_plugin_slug(): string {
		return "my-plugin-name";
	}

	// This is needed for the plugins.php logs link.
	public function get_plugin_basename(): string {
		return "my-plugin-name/my-plugin-name.php";
	}
};
$logger = Logger::instance( $logger_settings );

Then pass around your $logger instance.

After the logger has been instantiated once, subsequent calls to ::instance() return the existing instance and any $logger_settings passed is ignored.

To use WooCommerce's native WC_Logger, use the WooCommerce_Logger_Interface interface (which just extends Logger_Settings_Interface) on the settings object.

$logger_settings = new class() implements BrianHenryIE\WP_Logger\WooCommerce\WooCommerce_Logger_Settings_Interface {
    ...

WooCommerce Settings

Something like this can be used for WooCommerce Settings API.

$log_levels        = array( 'none', LogLevel::ERROR, LogLevel::WARNING, LogLevel::NOTICE, LogLevel::INFO, LogLevel::DEBUG );
$log_levels_option = array();
foreach ( $log_levels as $log_level ) {
    $log_levels_option[ $log_level ] = ucfirst( $log_level );
}

$setting_fields[] = array(
    'title'    => __( 'Log Level', 'text-domain' ),
    'label'    => __( 'Enable Logging', 'text-domain' ),
    'type'     => 'select',
    'options'  => $log_levels_option,
    'desc'    => __( 'Increasingly detailed levels of logs. ', 'text-domain' ) . '<a href="' . admin_url( 'admin.php?page=plugin-slug-logs' ) . '">View Logs</a>',
    'desc_tip' => false,
    'default'  => 'notice',
    'id'       => 'text-domain-log-level',
);

Filters

Two filters are present, to modify the log data as it is being saved, and to modify the log data as it is being presented.

E.g. change the log level for specific log messages:

/**
 * Modify the log data array or return null to cancel logging this entry.
 * The library php-http/logger-plugin is using INFO for detailed logging, let's change that to DEBUG.
 *
 * @hooked {$plugin_slug}_bh_wp_logger_log
 * 
 * @pararm array{level:string,message:string,context:array} $log_data
 * @param Logger_Settings_Interface $settings
 * @param BH_WP_PSR_Logger $bh_wp_psr_logger
 */
function modify_log_data( array $log_data, \BrianHenryIE\WP_Logger\Logger_Settings_Interface $settings, \BrianHenryIE\WP_Logger\API\BH_WP_PSR_Logger $bh_wp_psr_logger): ?array {
    
    if ( 0 === strpos( $log_data['message'], 'Sending request' ) ) {
        $log_data['level'] = LogLevel::DEBUG;
    }

    return $log_data;
}
add_filter( "{$plugin_slug}_bh_wp_logger_log", 'modify_log_data', 10, 3 );

E.g. turn text in logs into hyperlinks as it is being displayed in the logs table:

/**
 * Update ` `wc_order:123` ` with links to the order.
 * Use preg_replace_callback to find and replace all instances in the string.
 *
 * @hooked {$plugin_slug}_bh_wp_logger_column
 *
 * @param string                                                          $column_output The column output so far.
 * @param array{time:string, level:string, message:string, context:array} $item The log entry row.
 * @param string                                                          $column_name The current column name.
 * @param Logger_Settings_Interface                                       $logger_settings The logger settings.
 * @param BH_WP_PSR_Logger                                                $bh_wp_psr_logger The logger API instance.
 *
 * @return string
 */
function replace_wc_order_id_with_link( string $column_output, array $item, string $column_name,\BrianHenryIE\WP_Logger\Logger_Settings_Interface $logger_settings, \BrianHenryIE\WP_Logger\API\BH_WP_PSR_Logger $bh_wp_psr_logger ): string {

    if ( 'message' !== $column_name ) {
        return $column_output;
    }

    $callback = function( array $matches ): string {

        $url  = admin_url( "post.php?post={$matches[1]}&action=edit" );
        $link = "<a href=\"{$url}\">Order {$matches[1]}</a>";

        return $link;
    };

    $message = preg_replace_callback( '/`wc_order:(\d+)`/', $callback, $column_output ) ?? $column_output;

    return $message;
}
add_filter( "{$plugin_slug}_bh_wp_logger_column", 'replace_wc_order_id_with_link', 10, 5 );

WP_Mock

If using WP_Mock for your tests, and you are instantiating this logger, the following should help:

\Patchwork\redefine(
    array( Logger::class, '__construct' ),
    function( $settings ) {}
);

Test Plugin

The test-plugin folder contains a small plugin with buttons to trigger the types of errors that can be logged.

Best Practice

From my limited logging experience, I find it useful to add a debug log at the beginning of functions and an appropriate info...error as the function returns.

TODO

~~Check log directory is not publicly accessible~~
Check uploads dir chmod (is writable). => see brianhenryie/bh-wp-private-uploads
Add current user to context
~~Don't log empty context (WC)~~
Option for what level of errors to display as admin notices
Option for user capability for displaying admin notices (filter, at least)
~~Zero-config WC_Logger: detect "wc", "woo" in plugin names~~
~~Use Code prettify on the context json~~ : Used caldwell/renderjson
Paging and filtering
~~Hyperlinks in messages~~
~~Record timestamp the logs were last viewed at, make the plugins.php link bold if new logs are present.~~
~~Auto-delete old logs~~
~~Log notice should dismiss when the log page is visited~~
~~Redact sensitive data. e.g. use userid:123 in the saved logs and replace it with richer data when displaying them~~
Add errors to dashboard Site Health widget
Ensure output is properly escaped

Minor concerns:

Debug logging could maybe be moved to a shutdown handler
Transients to suppress duplicate logs might be inefficient

Status

To date I think it has been used mostly by me, i.e. internal projects. There are no egregious issues. It should work for everyone but I would like some feedback from others on how well it works for you.

I'll start at Semver 1.0.0 once I've caught up with WPCS, PhpStan and PhpUnit. There's about 65 tests and 43% coverage. WPCS + PHPStan are both pretty good.

I think that's higher code-quality than most WordPress plugins.

brianhenryie / bh-wp-logger

Maintainers

Details