All right, so big questions for WordPress hooks. What hooks exist for use? And what is the WordPress hooks firing sequence?
As in, what order do WordPress hooks fire within their actual context?
There are two resources, the WP Hook Database by Adam Brown and WordPress’ Code Reference to search for hooks. These two are great, but for someone still testing the waters in learning these concepts, it’s pretty overwhelming. Just imagine someone trying to learn the English language and you hand them the English dictionary.
What is all this? There’s just so much here, how do I know what words to use? How much of this do I need? Where do I even begin? And of course, alphabetical order isn’t going to help unless you converse in alphabetical order, right?
The same can be said for the above mentioned resources for hooks. They’re handy if you’re already familiar with hooks and/or if you have a true understanding of how WordPress builds itself in the background.
And so I thought to myself, maybe if I knew what hooks happen all the time in WordPress’ routine processing, and in what order, that might be a good starting point. A piece of the dictionary versus the whole doggone thing. Turns out I’m not the only person thinking this way. There doesn’t seem to be a unified and updated resource to the hook sequence, their definitions, and which ones happen depending on their environment.
So, I figured, if I had this resource, then I can start learning the language effectively – as in, the language of WordPress hooks. If said resource doesn’t exist – maybe it’s time I make one.
The Codex has a list of the typical actions run during a page request, but it’s based on WordPress 3.3.1 and using the Twenty-Eleven theme. Knowing that some content in the Codex can be outdated, I wanted to have this list of actions as up to date as possible. I was also interested in the filters available to me during a typical page run. Lastly, I wanted to provide a method for others that want to figure this out on their own WordPress installs.
Mission Start!
I set off to find the firing order of hooks. The order can vary depending on what’s being viewed, the theme, and any custom code and/or plugins. So to get the most basic order, this is what I did on a local copy of WordPress. On a fresh copy of WordPress 4.2.2 with a default theme, in this case, Twenty-Fifteen, I began. Do not attempt to do this on a live site.
- Install the Debug Bar Plugin
- Install the Debug Bar Actions and Filters Addon
- Activate both plugins and get a Word Doc out! ( Or in my case, this blog. ) It’s time to document!
For the sake of keeping this post as a starting point reference ( rather than the “entire dictionary” ), I decided to limit where I look for the actions/filters sequence to just the front page. The front page is where it automatically lists the recent blog posts in chronological order.
On the front page with both of these debug plugins active, while logged in, your admin bar will have a “Debug” option. Click there and a new screen appears. Here in this new screen, you can click either “Action Hooks” or “Filter Hooks” to see what’s happened in the background of the front page.
Step 1:
Step 2:
Then magic should happen.
Before we go any further, I wanted to give a gentle reminder while exploring WordPress’ core files. Do not edit these files ever, or as the saying goes: Do not hack core!
For those still unsure what “hacking core” actually means, I’ve got just the article for you!
What Developers mean when they say “Don’t Hack Core”: It’s a great read, also includes Drupal.
Moving on though, here are the results of my Debug bar testing.
61 Actions Fire on the front page:
Action definitions have been copied and pasted from the Code Reference. Some personal notes here and there.
Action: | Definition |
muplugins_loaded | Fires once all must-use and network-activated plugins have loaded. |
registered_taxonomy | Fires after custom taxonomies are registered (post categories/tags). |
registered_post_type | Fires after a post type is registered. |
plugins_loaded | Fires once activated plugins have loaded. |
sanitize_comment_cookies | Fires when comment cookies are sanitized. |
setup_theme | Fires before the theme is loaded. |
unload_textdomain |
Fires before the text domain is unloaded. Basically, “Is there a text domain we can use for translations?” |
load_textdomain |
Fires before the MO translation file is loaded. Basically, “Whoa, we DO have a text domain and let’s get those translations from the .mo file now!” |
after_setup_theme | Fires after the theme is loaded. |
auth_cookie_malformed | Fires if an authentication cookie is malformed. |
auth_cookie_valid | Fires once an authentication cookie has been validated. |
set_current_user | Fires after the current user is set. |
init |
Fires after WordPress has finished loading, but before any headers are sent. If you wish to plug an action once WP is loaded, use the wp_loaded hook below. |
widgets_init | Fires after all default WordPress widgets have been registered. |
register_sidebar | Fires once a sidebar has been registered. |
wp_register_sidebar_widget | Fires once for each registered widget. |
wp_loaded |
This hook is fired once WP, all plugins, and the theme are fully loaded and instantiated. Use this hook if you need to intercept actions once the WP has loaded and has access to taxonomies/post types/the user etc. |
parse_request |
Fires once all query variables for the current request have been parsed. Here’s a list of some of what those variables are, here WordPress’ global variables. Accessing others is not recommended. |
send_headers | Fires once the requested HTTP headers for caching, content type, etc. have been sent. |
parse_tax_query | Fires after taxonomy-related query vars have been parsed. |
parse_query | Fires after the main query vars have been parsed. |
pre_get_posts | Fires after the query variable object is created, but before the actual query is run. |
posts_selection |
Fires to announce the query’s current selection parameters. For use by caching plugins. |
wp |
Fires once the WordPress environment has been set up. I got this definition by looking up wp-includes/class-wp.php on line 616, there’s a comment. I couldn’t find it in the Code Reference… |
template_redirect | Fires before determining which template to load. |
wp_default_scripts | Fires when the WP_Scripts instance is initialized. |
wp_default_styles | Fires when the WP_Styles instance is initialized. |
admin_bar_init | Fires after WP_Admin_Bar is initialized. |
add_admin_bar_menus | Fires after menus are added to the menu bar. |
get_header | Fires before the header template file is loaded. |
wp_head | Fire the wp_head action. |
wp_enqueue_scripts | Fires when scripts and styles are enqueued. |
wp_print_styles | Display styles that are in the $handles queue. |
wp_print_scripts | Fires before scripts in the $handles queue are printed. |
get_sidebar | Fires before the sidebar template file is loaded. |
dynamic_sidebar_before | Fires before widgets are rendered in a dynamic sidebar. |
dynamic_sidebar | Fires before a widget’s display callback is called. |
pre_get_search_form | Fires before the search form is retrieved, at the start of get_search_form(). |
loop_start | Fires once the loop is started. |
the_post | Fires once the post data has been setup. |
loop_end | Fires once the loop has ended. |
parse_comment_query |
Parse arguments passed to the comment query with default query parameters. Couldn’t find this in the Code Reference so I got this definition from wp-includes/comment.php on line 428. |
pre_get_comments | Fires before comments are retrieved. |
wp_meta | Fires before displaying echoed content in the sidebar. |
dynamic_sidebar_after | Fires after widgets are rendered in a dynamic sidebar. |
get_template_part_content |
This one is tricky. From what I see, there is no literal hook called get_template_part_content. There is a hook called get_template_part where the slug is dynamic. For some reason the Debug Bar showed me this hook as get_template_part_content rather than get_template_part, but I digress. Fires before the specified template part file is loaded. |
add_option | Fires before an option is added. |
Yet again, there is no hook by this name. Instead this refers to the add_option hook and is_multi_author? From what I see on this old Track ticket, a transient is being used for on is_multi_author for a performance boost, but anyway yeah! Interesting! | |
added_option | Fires after an option has been added. |
set_transient__transient_is_multi_author |
Once again, there is no hook by this name. There is however, a set_transient hook. Looks like the is_multi_author transient is being set here. Fires after the value for a specific transient has been set. |
setted_transient | Fires after the value for a transient has been set. |
add_option__transient_twentyfifteen_categories *Specific to Twenty Fifteen. |
Looks like this is pulling off the same with transients as the previous is_multi_author “hooks”. You can find more on twentyfifteen_categories in the theme’s template-tags.php file in the inc folder. |
set_transient__transient_twentyfifteen_categories *Specific to Twenty Fifteen. |
Read directly above. |
get_footer | Fires before the footer template file is loaded. |
twentyfifteen_credits *Specific to Twenty Fifteen. |
This is a do_action in footer.php that isn’t hooked to any functions, but appears it’s there for the sake of theme developers to hook into themselves if they’d like. In other words, if you don’t use this for anything, it does nothing on it’s own. |
wp_footer | Print scripts or data before the closing body tag on the front end. |
wp_print_footer_scripts | Fires when footer scripts are printed. |
admin_bar_menu |
Load all necessary admin bar items. |
wp_before_admin_bar_render | Fires before the admin bar is rendered. |
wp_after_admin_bar_render | Fires after the admin bar is rendered. |
238-ish Filters that fire on the front page:
You can look up the functions in the Code Reference or the Codex. I’ve only linked out to the hook definitions below. Definitions to hooks are copied and pasted from the Code Ref. Some personal notes here and there if I couldn’t find the hook definitions in core or in the Code Reference.
pre_term_name
|
No definition in the Code Reference, but present in core. |
pre_comment_author_name
|
Filter the comment author’s name cookie before it is set. |
pre_link_name
|
No definition in the Code Reference, but present in core. |
pre_link_target
|
No definition in the Code Reference, but present in core. |
pre_link_rel
|
No definition in the Code Reference, but present in core. |
pre_user_display_name
|
Filter a user’s display name before the user is created or updated. |
pre_user_first_name
|
Filter a user’s first name before the user is created or updated. |
pre_user_last_name
|
Filter a user’s last name before the user is created or updated. |
pre_user_nickname
|
Filter a user’s nickname before the user is created or updated. |
term_name
|
Filter display of the term name in the terms list table. |
comment_author_name
|
Filter the comment author’s name cookie before it is set. |
link_name
|
No definition in the Code Reference, but present in core. It’s also connected to two deprecated functions: get_linkobjects and get_linkobjectsbyname. The up to date hook for this is now get_bookmarks. |
link_target
|
Read directly above. |
link_rel
|
Read back up to link_name. |
user_display_name
|
Filter a user’s display name before the user is created or updated. |
user_first_name
|
Filter a user’s first name before the user is created or updated. |
user_last_name
|
Filter a user’s last name before the user is created or updated. |
user_nickname
|
Filter a user’s nickname before the user is created or updated. |
pre_term_description
|
No definition in the Code Reference, but present in core. |
pre_link_description
|
No definition in the Code Reference, but present in core. |
pre_link_notes
|
No definition in the Code Reference, but present in core. |
pre_user_description
|
Filter a user’s description before the user is created or updated. |
pre_comment_author_email
|
Filter the comment author’s email cookie before it is set. |
pre_user_email
|
Filter a user’s email before the user is created or updated. |
comment_author_email
|
Filter the comment author’s returned email address. |
user_email
|
No definition in the Code Reference, but present in core. |
pre_comment_author_url
|
Filter the comment author’s URL cookie before it is set. |
pre_user_url
|
Filter a user’s URL before the user is created or updated. |
pre_link_url
|
No definition in the Code Reference, but present in core. |
pre_link_image
|
No definition in the Code Reference, but present in core. |
pre_link_rss
|
No definition in the Code Reference, but present in core. |
pre_post_guid
|
No definition in the Code Reference, but present in core. |
user_url
|
No definition in the Code Reference, but present in core. |
link_url
|
Refer to link_name notes. |
link_image
|
Refer to link_name notes. |
link_rss
|
Refer to link_name notes. |
comment_url
|
Filter the comment author’s URL for display. |
post_guid
|
No definition in the Code Reference, but present in core. |
pre_term_slug
|
No definition in the Code Reference, but present in core. |
pre_post_type
|
No definition in the Code Reference, but present in core. |
pre_post_status
|
No definition in the Code Reference, but present in core. |
pre_post_comment_status
|
No definition in the Code Reference, but present in core. |
pre_post_ping_status
|
No definition in the Code Reference, but present in core. |
pre_post_mime_type
|
No definition in the Code Reference, but present in core. |
post_mime_type
|
The closest I found to this hook was post_mime_types with an “s”. Filter the default list of post mime types. |
content_save_pre
|
No definition in the Code Reference. This appears to be tied to the kses_init_filters function. This function adds all Kses input form content filters. In plain English, this is for data sanitization on form fields. |
excerpt_save_pre
|
Refer to content_save_pre notes. |
comment_save_pre
|
Refer to content_save_pre notes. |
pre_comment_content
|
Filter the comment content before it is set. |
comment_author
|
Filter the comment author’s name for display. |
link_description
|
Refer to link_name notes. |
link_notes
|
Refer to link_name notes. |
bloginfo
|
Filter the site information returned by get_bloginfo(). ( Blog info refers to your site tagline – the one you fill out on the dashboard under Settings > General. ) |
wp_title
|
Filter the text of the page title. |
widget_title
|
Filter the widget title. |
the_content
|
Filter the post content. |
the_title
|
Deprecated. You can find this hook in wp-includes/deprecated.php for reference. Depending on what you need the filter, there are other hooks you can use to replace it. I’ve linked to the hook results in the Code Reference instead of one individual result. They should tell you what to use instead of the_title. |
comment_text
|
Filter the text of a comment to be displayed. |
single_post_title
|
Filter the page title for a single post. |
single_cat_title
|
Filter the category archive page title. |
single_tag_title
|
Filter the tag archive page title. |
single_month_title
|
This isn’t in the Code Reference as a filter so I’ve linked to it’s function definition. From what I’m seeing in wp-includes/default-filters.php, this is a hook though. The hook should filter the title for post archives based on date. |
nav_menu_attr_title
|
Filter a navigation menu item’s title attribute. |
nav_menu_description
|
Filter a navigation menu item’s description. |
term_description
|
No definition in the Code Reference, but present in core |
term_name_rss
|
No definition in the Code Reference, but present in core. |
wp_insert_post_parent
|
Filter the post parent — used to check for and prevent hierarchy loops. |
wp_update_term_parent
|
|
the_excerpt
|
Filter the displayed post excerpt. |
get_the_excerpt
|
Filter the retrieved post excerpt. |
comment_excerpt
|
Filter the comment excerpt for display. |
list_cats
|
Filter a taxonomy drop-down display element. |
wp_sprintf
|
Filter a fragment from the pattern passed to wp_sprintf(). I honestly have no idea what this means… |
the_title_rss
|
Filter the post title for use in a feed. |
the_content_rss
|
No proper definition in the Code Reference, but present in core. |
the_content_feed
|
Filter the post content for use in feeds. |
the_excerpt_rss
|
Filter the post excerpt for a feed. |
comment_author_rss
|
Filter the current comment author for use in a feed. |
comment_text_rss
|
Filter the current comment content for use in a feed. |
bloginfo_rss
|
Filter the bloginfo for display in RSS feeds. |
the_author
|
Filter the display name of the current post’s author. |
the_guid
|
Filter the escaped Global Unique Identifier (guid) of the post. |
wp_mail
|
Filter the wp_mail() arguments. |
option_ping_sites
|
No definition in the Code Reference, but present in core. |
option_blog_charset
|
No definition in the Code Reference, but present in core. |
option_home
|
No definition in the Code Reference, but present in core. |
option_siteurl
|
No definition in the Code Reference, but present in core. |
tiny_mce_before_init
|
Filter the TinyMCE config before init. |
teeny_mce_before_init
|
Filter the teenyMCE config before init. |
pre_kses
|
Filter content to be run through kses. |
sanitize_title
|
Filter a sanitized title string. |
check_comment_flood
|
Fires immediately before a comment is marked approved. |
comment_flood_filter
|
Filter the comment flood status. |
comment_email
|
|
option_tag_base
|
No definition in the Code Reference, but present in core. |
option_category_base
|
No definition in the Code Reference, but present in core. |
the_posts
|
Filter the array of retrieved posts after they’ve been fetched and internally processed. |
comments_open
|
Filter whether the current post is open for comments. |
pings_open
|
Filter whether the current post is open for pings. |
editable_slug
|
This is a multi-use hook. I linked to the Code Reference results showing all the hooks. |
nav_menu_meta_box_object
|
Another multi-use hook. Linked to Code Reference results. |
pingback_ping_source_uri
|
Filter the pingback source URI. |
xmlrpc_pingback_error
|
Filter the XML-RPC pingback error return. |
title_save_pre
|
No definition in the Code Reference. Appears to be tied to the kses_init_filters function. |
http_request_host_is_external
|
|
wp_head
|
Print scripts or data in the head tag on the front end. |
publish_future_post
|
Looks like this is a filter tied to the check_and_publish_future_post function. Refer to wp-includes/default-filters.php. |
wp_footer
|
Print scripts or data before the closing body tag on the front end. |
template_redirect
|
Fires before determining which template to load. |
wp_print_footer_scripts
|
Fires when footer scripts are printed. |
init
|
Fires after WordPress has finished loading but before any headers are sent. |
after_switch_theme
|
Fires on the first WP load after a theme switch if the old theme still exists. |
wp_print_styles
|
Fires before styles in the $handles queue are printed. |
login_head
|
Fires in the login page header after scripts are enqueued. |
login_footer
|
Fires in the login page footer. |
login_init
|
Fires when the login form is initialized. |
rss2_head
|
Fires at the end of the RSS2 Feed Header. |
commentsrss2_head
|
Fires at the end of the RSS2 comment feed header. |
rss_head
|
Fires at the end of the RSS Feed Header. |
rdf_header
|
Fires at the end of the RDF feed header. |
atom_head
|
Fires just before the first Atom feed entry. |
comments_atom_head
|
Fires at the end of the Atom comment feed header. |
opml_head
|
Fires in the OPML header. |
app_head
|
No definition in the Code Reference, but present in core. |
do_feed_rdf
|
No definition in the Code Reference, but present in core. |
do_feed_rss
|
No definition in the Code Reference, but present in core. |
do_feed_rss2
|
No definition in the Code Reference, but present in core. |
do_feed_atom
|
No definition in the Code Reference, but present in core. |
do_pings
|
No definition in the Code Reference, but present in core. |
do_robots
|
Fired when the template loader determines a robots.txt request. |
set_comment_cookies
|
Perform other actions when comment cookies are set. |
sanitize_comment_cookies
|
Fires when comment cookies are sanitized. |
admin_print_scripts
|
Fires when scripts are printed for all admin pages. |
admin_print_footer_scripts
|
Prints any scripts and data queued for the footer. |
admin_print_styles
|
Fires when styles are printed for all admin pages. |
plugins_loaded
|
Fires once activated plugins have loaded. |
shutdown
|
Fires just before PHP shuts down execution. |
post_updated
|
Fires once an existing post has been updated. |
publish_post
|
No definition in the Code Reference. Appears to be tied to the xmlrpc_publish_post hook somehow. Needs more investigation on my part… |
transition_post_status
|
Fires when a post is transitioned from one status to another. |
comment_form
|
Fires at the bottom of the comment form, inside the closing </form> tag. |
wp_scheduled_delete
|
It appears there’s a function that’s tied to an action hook by the same name? Once again wp-includes/default-filters.php for reference. |
wp_scheduled_auto_draft_delete
|
No definition in the Code Reference, but present in core. |
admin_init
|
Fires as an admin screen or script is being initialized. |
importer_scheduled_cleanup
|
No definition in the Code Reference, but present in core. |
upgrader_scheduled_cleanup
|
No definition in the Code Reference, but present in core. |
welcome_panel
|
Add content to the welcome panel on the admin dashboard. |
delete_post
|
Fires immediately before a post is deleted from the database. |
delete_term
|
Fires after a term is deleted from the database and the cache is cleaned. |
begin_fetch_post_thumbnail_html
|
Fires before fetching the post thumbnail HTML. |
end_fetch_post_thumbnail_html
|
Fires after fetching the post thumbnail HTML. |
pre_option_gmt_offset
|
No definition in the Code Reference, but present in core. |
admin_color_scheme_picker
|
|
default_option_link_manager_enabled
|
No definition in the Code Reference, but present in core. |
default_option_embed_autourls
|
No definition in the Code Reference, but present in core. |
heartbeat_settings
|
Filter the Heartbeat settings. |
admin_enqueue_scripts
|
Enqueue scripts for all admin pages. |
heartbeat_send
|
Filter the Heartbeat response sent. |
heartbeat_nopriv_send
|
Filter Heartbeat AJAX response when no data is passed. |
authenticate
|
Filter the user to authenticate. |
determine_current_user
|
Filter the current user. |
split_shared_term
|
Fires after a previously shared taxonomy term is split into two separate terms. |
setup_theme
|
Fires before the theme is loaded. |
wp_loaded
|
This hook is fired once WP, all plugins, and the theme are fully loaded and instantiated. |
delete_attachment
|
Fires before an attachment is deleted, at the start of wp_delete_attachment(). |
save_post
|
Fires once a post has been saved. |
update_option_start_of_week
|
No definition in the Code Reference. Looks like it’s an action hook tied to the delete_get_calendar_cache function. |
update_option_gmt_offset
|
Read directly above. |
admin_menu
|
Fires before the administration menu loads in the admin. |
before_delete_post
|
Fires before a post is deleted, at the start of wp_delete_post(). |
wp_trash_post
|
Fires before a post is sent to the trash. |
request
|
Filter the array of parsed query variables. |
term_link
|
Filter the term link. |
get_post_format
|
No definition in the Code Reference, but present in core. |
get_terms
|
Filter the given taxonomy’s terms cache. |
wp_get_object_terms
|
Filter the terms for a given object or objects. |
set_current_user
|
Fires after the current user is set. |
wp_default_scripts
|
Fires when the WP_Scripts instance is initialized. |
wp_print_scripts
|
Fires before scripts in the $handles queue are printed. |
print_scripts_array
|
Filter the list of script dependencies left to print. |
wp_default_styles
|
Fires when the WP_Styles instance is initialized. |
style_loader_src
|
Filter an enqueued style’s fully-qualified URL. |
wp_playlist_scripts
|
Print and enqueue playlist scripts, styles, and JavaScript templates. |
customize_controls_enqueue_scripts
|
Enqueue Customizer control scripts. |
nav_menu_item_id
|
Filter the ID applied to a menu item’s list item element. |
in_admin_header
|
Fires at the beginning of the content section in an admin page. |
wp_version_check
|
The hook is tied to a function by the same name. It appears that the function checks the WordPress version against the newest version. |
upgrader_process_complete
|
Fires when the bulk upgrader process is complete. |
load-plugins.php
|
No definition in the Code Reference, but present in core. |
load-update.php
|
No definition in the Code Reference, but present in core. |
load-update-core.php
|
No definition in the Code Reference, but present in core. |
wp_update_plugins
|
The hook is tied to a function by the same name. The function checks plugin versions against the latest versions hosted on WordPress.org. |
load-themes.php
|
No definition in the Code Reference, but present in core. |
wp_update_themes
|
The hook is tied to a function by the same name. The function checks theme versions against the latest versions hosted on WordPress.org. |
update_option_WPLANG
|
No definition in the Code Reference, but present in core. |
wp_maybe_auto_update
|
No definition in the Code Reference, but present in core. |
edit_form_advanced
|
Fires after ‘normal’ context meta boxes have been output for all post types other than ‘page’. |
wp_ajax_add-category
|
No proper definition in the Code Reference. I don’t think this is an actual hook. Debug bar might be trolling me… If it is, I couldn’t find it in core by that exact name, but there are several functions that begin with wp_ajax_add. |
wp_ajax_add-post_tag
|
Read directly above. |
wp_ajax_add-nav_menu
|
Refer to wp_ajax_add-category notes. |
wp_ajax_add-link_category
|
Refer to wp_ajax_add-category notes. |
wp_ajax_add-post_format
|
Refer to wp_ajax_add-category notes. |
future_post
|
No definition in Code Reference, could not find in Core by exact name. I don’t know much about this at this time, but you can investigate in wp-includes/post.php. |
future_page
|
No definition in Code Reference, could not find in Core by exact name. |
future_attachment
|
No definition in Code Reference, could not find in Core by exact name. |
future_revision
|
No definition in Code Reference, could not find in Core by exact name. |
future_nav_menu_item
|
No definition in Code Reference, could not find in Core by exact name. |
admin_bar_init
|
Fires after WP_Admin_Bar is initialized. |
_admin_menu
|
|
widgets_init
|
Fires after all default WordPress widgets have been registered. |
after_setup_theme
|
Fires after the theme is loaded. |
wp_enqueue_scripts
|
Fires when scripts and styles are enqueued. |
walker_nav_menu_start_el
|
Filter a menu item’s starting output. |
get_search_form
|
Filter the HTML output of the search form. |
edit_category
|
This hook has been deprecated. Use {$taxonomy}_add_form instead. |
excerpt_more
|
Filter the string in the “more” link displayed after a trimmed excerpt. |
customize_register
|
Fires once WordPress has loaded, allowing scripts and styles to be initialized. |
customize_preview_init
|
Fires once the Customizer preview has initialized and JavaScript settings have been printed. |
customize_controls_print_footer_scripts
|
Print Customizer control scripts in the footer. |
deleted_post
|
Fires immediately after a post is deleted from the database. |
switch_theme
|
Fires after the theme is switched. |
comment_post
|
Fires immediately after a comment is inserted into the database. |
edit_comment
|
|
transition_comment_status
|
Fires when the comment status is in transition. |
admin_head
|
Fires in head section for all admin pages. |
admin_bar_menu
|
|
admin_footer | Print scripts or data before the default footer scripts. |
body_class | Filter the list of CSS body classes for the current post or page. |
admin_body_class | Filter the CSS classes for the body tag in the admin. |
deprecated_function_run | Fires when a deprecated function is called. |
deprecated_file_included | Fires when a deprecated file is called. |
deprecated_argument_run | Fires when a deprecated argument is called. |
deprecated_function_trigger_error
|
Filter whether to trigger an error for deprecated functions. |
deprecated_file_trigger_error
|
Filter whether to trigger an error for deprecated files. |
deprecated_argument_trigger_error
|
Filter whether to trigger an error for deprecated arguments. |
wp_before_admin_bar_render
|
Fires before the admin bar is rendered. |
What I’ve learned from this experiment…

That I am a WordPress masochist.
Okay I’m kidding, but documenting all of this was borderline insanity for me, I’ll admit. I didn’t publish any posts for June and I was determined to make July’s post totally worth it! Will power! Okay, back on topic…
The Code Reference is more boss than I am.
There are too many hooks for me to record them depending on their context. Hence why I only tackled just the front page. Holy moly, props to the Codex, Code Reference, the WP Hooks Database, and all their contributors for all of that documentation.
At a glance though from just the action hooks, the list I compiled seems pretty similar to the version based on WordPress 3.3.1 and using the Twenty-Eleven.
What we see vs What’s actually happening…
There is a LOT going on before the WordPress theme even kicks in on the front-end. I hadn’t realized that most of the hooks we see in WordPress, especially the filters, are all falling into place to build so much on the backend before we physically see anything. I also can’t guess the hook sequence by glancing at a WordPress site page. More than half of the action hooks have already happened before the loop even kicks in. The admin bar appears to be the last thing that happens.
Also realized that just because the hook isn’t in the Code Reference doesn’t mean it’s not present in core. Might be harder to figure out what the hook is since it will require more investigation through core files for the meaning. I’m also not sure if there’s a legit reason why some of these hooks are not in the Code Reference. By glancing at some of the hooks, especially the filters, I feel like most people would never have use for all of them. By most people, I mean those more likely to be tinkering with hooks as in theme or plugin developers. So perhaps that’s taken into account when a hook is documented in the Code Reference?
WP Core is a black hole.
Another realization now that I’m really jumping headfirst into trying to understand WordPress is that this endeavor is a black hole. Meaning you’ll jump in to figure out what function a hook calls, then what that function does, then find something you’ve never seen before, go look that up, find something else you’re not sure what it means, then look that up. The trail continues. Five minutes in you’ve learned about 4 or 5 new WordPress concepts/functions/slang only to forget where you originally started. This happened to me a lot while I documented this and I had to stop myself or else I’d never move onto the next hook. Each hook has it’s own depth. It’s hard to resist learning about each and every one to the detail. Or maybe that’s just me?
What I’m planning to do is pick a few that seem useful to me, and then dive into those. It’ll keep me from falling too far into core and becoming overwhelmed.
Now what?
Now that I’ve written all of these WordPress hooks by hand, I can actually name a few off the top of my head. You’d be surprised what a little writing does for memorization. I don’t recommend that everyone do exactly as I did, but maybe writing a few with their definitions might be helpful.
I can’t promise this is the most legit list WordPress hooks and their sequence, but I’m definitely going to refer to this in the future. I feel like it’ll be easier to glance at this list and find what I need versus taking a wild guess and then typing into the Code Reference search bar. Having a list in the order as it happens on a page has given me a better understanding of how WordPress, as a platform, is falling into place. I now have a better chance of knowing what point I want to hook functions into. I hope this list helps someone else along the way. Maybe I’ll make this into a downloadable file in the future for easier reference.
If anyone knows more about specific hooks, especially the ones without definitions in the Code Reference, I’d love to hear about it in the comments. 🙂 If I’m wrong anywhere in my notes, tell me that too. I really want to know.
Until next time, enjoy the summer!
Massively useful! Appreciate the huge amount of time this must have taken to compile. Thank you!
Hi Donna,
You’re welcome. If it helps at least one person, it was worth it haha! 🙂
This is incredibly useful! In all my time developing for WordPress I’ve never seen this documented so clearly. Thank you for taking the time to explain this in a referable format. I will definitely be referring to this and have exported an offline print to pdf.
Hi kfwebdev,
You’re welcome, happy it’ll be of use. 🙂
This will be very usefull to the “backpress revival” project. Great stuff. We are currently digging alot through core as well if you want to take part join us on Slack: http://www.advancedwp.org/awp-on-slack/
Currently two methods of extracting on modulerizing WP Core has been presented.
One thing you will also realise digging through core is that core does not utilize itself to the fullest extent. It does not use Core functions to do stuff. Not even close. There are also weird function calls that runs twice to accomodate undocumented scenarios.
Hi Andreas,
Awesome! Maybe I’ll check out Slack some time. I’m afraid I haven’t dug into core enough to really- wait, this post really contradicts anything I was about to say, doesn’t it? Okay, yeah, I will def check it out then haha.
I’m going to spend more time in core and see if I can find the places you mentioned, of functions not being used or potential strangeness. Looking forward to it.
Thanks for stopping by. 🙂
Thank you so much for this. I’ve wondered about this so many times and haven’t investigated thoroughly. I’ll be bookmarking this for future reference.
Hi Joseph,
Awesome! You’re welcome. 🙂
[…] WordPress Hook Firing Sequence – Rachel Vasquez has done some excellent research into the order in which WordPress’ core actions take place. This is a long read, but very insightful! […]
[…] that the standard resources were missing some crucial information for those new to the concept. Check out her post on the firing order of hooks, including a great list of 61 Actions Fire on the front […]
Thanks for sharing. It was and I did not know about the Debug tools that you mentioned.
The Don’t Hack Core url gives a 404, it has changed to:http://bethsoderberg.com/blog/what-developers-mean-when-they-say-dont-hack-core/.
Thank you for the trouble 🙂
I’m learning WordPress and got here by searching for the sequence in which WordPress loads. Was looking into some code which had a function in which a header() statement is included. I read that a header function should be sent to the browser before any html output so I was curious to see when the actual output to the browser is generated.
Thanks for this list from your investigations which will surely be very helpful for those learning WordPress development.
You’re welcome. Happy to help. 🙂
[…] The WordPress Hooks Firing Sequence! […]
[…] quienes han hecho un esfuerzo para documentar que hooks se usan y en que momento. Incluso puedes encontrar infografías muy buenas que te dan una […]
I am using this frequently too. Thank you so much for taking the time to make this available to all of us. Very much appreciated <3
You’re welcome. Happy to help. 🙂
Nice article. A bit lengthy though.
Jquery Training Blog
thank you for this article, it’s very helpfull
Lol I get lost in the black hole every time I use the codex. LOST! Great post!
Awesome article,Thank you!
You’re welcome! I’m glad this is still helpful even years later.
You rock, RachieVee. It’s great you had the patience to slog through this. Thank you thank you.
You’re welcome. 🙂
[…] a first note, you have to know when in WordPress’s hooks firing sequence to call get_queried_object(). In particular, if you call it too early, it won’t […]
Alhamdulillah. Mashallah. This is an extraordinary. Thanks ❤️
if you had a ‘table of contents’ in the beginning of this super useful post.
what order do WordPress hooks fire within their actual context?visit link my websiteTel-U