Debug WordPress by logging hook calls

Recently, I had to identify a rogue process on a WordPress / WooCommerce site which was causing a big delay when transferring a customer from the checkout to an external payment gateway. The data transfer in a WooCommerce payment gateway is handled by AJAX, so conventional debug tools such as Query Monitor were no use in this situation as they perform their analysis when the page is generated, not when an AJAX request is triggered.

There is a WordPress hook that runs on every action and filter, the ‘all’ action. Within our logging function, we can use the current_filter function to log the name of the hook. By examining the logs, we can identify which processes are taking an unusually long time, and we can focus our optimisation efforts there.

The snippet below goes in your theme’s functions.php. You will also need to enable WP_DEBUG_LOG in your wp-config.php file.

add_action( 'all', 'log_hook_calls' );
function log_hook_calls() {
	// Restrict logging to requests from your IP - your IP address goes here
	$client_ip = "123.123.123.123"; 
	// The full path to your log file:
	$log_file_path = "/path/to/your/log-hook-calls.log"; 
	if ($_SERVER['REMOTE_ADDR'] == $client_ip) { 
		if ( WP_DEBUG_LOG ) { 
			error_log(date("d-m-Y, H:i:s") . ": " . current_filter() . "\n", 3, $log_file_path); 
		}
	} 
}

Notes:

• There are many thousands of hook calls for every page generated, so these logs get really big really fast, and are very performance intensive. In my tests, logging a single page generation produced a log file of 5MB! So we definitely want to restrict our logging to our own requests. Running this log process unrestricted on a busy production site would probably take the site out in seconds, so beware!
• I have also restricted logging to when the WP_DEBUG_LOG parameter has been set in wp-config.php.
• We have to use PHP’s error_log function, not (say) WooCommerce’s WC_Logger() function since some hooks are called before the WC_Logger() function has been defined. Setting the message_type parameter to 3 tells error_log to log to a specific file.

Next steps:

Once you’ve identified the process that is taking a long time, you will have to investigate further:

• It may be obvious that a particular plugin is the culprit. You may have to disable it or find an alternative.
• If the culprit is the query hook, you will need to perform some database optimisation. You might need to add an index to your table, or optimise the SQL. Query Monitor may now come in useful.