Does anyone have a visual breakdown of core hooks and when they are fired?

Question

The title says it all really. I'd like to get an idea of the chronology of when the actions are fired and filters called for WordPress, preferably visually although I'm thinking of downloading, altering core to log to a file whenever an action or filter is registered, then again when fired and working with the output of that.

It'd essentially make my life much easier if anyone else has visualised it before.

Answer 1

The Action Reference in Codex has a roughly chronological list of actions called during both front-end and admin requests, though it's nothing fancier than a simple list.

Filters are a bit trickier, as they primarily handle output, so it's going to be specific to what theme and plugins you've got and what they're doing during different kinds of requests.

You can log when all actions and filters are invoked without editing core with the all action:

function wpd_log_all_filters(){
    var_dump( current_filter() );
}
add_action( 'all', 'wpd_log_all_filters' );

This will fire for both actions and filters, actions are a simple kind of filter under the hood.

Answer 2

I completely forgot about this until I was just reviewing my profile. I made a plugin that allows me to log the order of execution whilst debugging complex issues and analysing the content.

https://github.com/WordPress-Thinstall/working-files/blob/5ee79d55552fd2ecf58778783495e3c262bb6c83/plugins/wp-save-hooks-sql.php

It requires PHP7 (or to be more accurate it's tested on 7, 7.1, 7.2) and the 'all' special tag was pointed out by https://www.reddit.com/user/konradkar on reddit.

It should be noted that this may require a significant amount of RAM to execute, and will probably slow down a response, so shouldn't be used in production, but the RAW data will help you to understand for a request_uri, given certain specific inputs (logs post and get data), at a given time what hooks were fired, and in what order, function arguments, etc.

I found that searching the SQL log table gave me enough data to visualise fully per-request what was going on and when.