Selectively filtering errors from the WordPress debug.log

From time to time you need to filter stuff out of the WordPress debug.log. Notices or errors from your own code should be fixed, but what if your code is not the offender? Perhaps a plugin has not yet been updated to account for changes to WordPress core, polluting your log. Case in point:

PHP Notice:  Function _load_textdomain_just_in_time was called <strong>incorrectly</strong>. Translation loading for the <code>wp-migrate-db</code> domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the <code>init</code> action or later. Please see <a href="https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 6.7.0.) in /.../wp-includes/functions.php on line 6121

The log becomes useless for your own testing and debugging if it’s cluttered with other people’s garbage, and simply disabling the plugin isn’t always feasible.

Fortunately, there’s an action/hook you can leverage to selectively filter stuff out of the debug log, but you must configure the hook as an MU (must-use) plugin.

<?php
/**
 * Plugin Name: Suppress Errors
 * Description: Prevents certain errors from being logged in WordPress
 */

 add_action( 'muplugins_loaded', function() {

    // Override WordPress error handler for this specific case
    $original_handler = set_error_handler( function( $errno, $errstr, $errfile, $errline ) use ( &$original_handler ) {
        
        // Check if this is our specific error
        if ( str_contains( $errstr, '_load_textdomain_just_in_time' ) ) { 
            // Suppress this error only
            return true;
        }

        // Use the original handler for all other errors
        if ( is_callable( $original_handler ) ) {
            return call_user_func_array( $original_handler, func_get_args() );
        }

        // Default error handling
        return false;

    } );

}, 0 );

I’ll try to come back to this post later and step through what’s happening in this function, but for now, know the str_contains conditional is where you’ll check a bit of text that’s unique to the error you’d like to disable. Add multiple conditions as necessary.

I don’t recommend using this in a production environment. It could have performance implications or conflicts. I only occasionally use it my local dev environment, and only if I really have to. This should be considered a very temporary measure. Don’t block errors or notices indefinitely. Let the developers of the offending plugin know about the error. In the case of my example above from WP Migrate Pro, the issue was fixed before I was even able to publish this article.