Think of WordPress execution as a series of rungs on a ladder: WordPress climbs one rung, then the next, then the next, and so on.
Think of action hooks as the rungs themselves. Here is a (slightly abbreviated, I think) list of those actions, or “rungs” executed during a typical WordPress request.
Thus, an add_action()
call is simply an instruction to execute a function on a specific rung on the ladder. As long as you make that add_action()
call on a rung earlier than the run on which you want the specified function to execute, then it doesn’t matter, per se which rung you use to make the add_action()
call. However, there are reasons to use specific rungs to execute functions.
To take your example: a Theme’s functions.php
file executes at (I believe) after_setup_theme
. So, you simply can’t use a Theme to add an action to any rung prior to after_setup_theme
, because WordPress has already executed those actions (i.e. WordPress has already climbed those “rungs” on the ladder).
If you try to execute wp_enqueue_script()
in a callback hooked into an action before init
, WordPress will generate a _doing_it_wrong()
notice, because wp_enqueue_script()
should not be executed before init
, and most correctly should be executed at either wp_enqueue_scripts
(front end) or admin_enqueue_scripts-{hook}
(admin).
However:
Can I chuck stuff like this in there too?
add_action('get_header', 'enable_threaded_comments'); add_action('widgets_init', 'unregister_default_wp_widgets', 1); remove_action('wp_head', 'rsd_link');
All of these are perfectly fine being called at after_setup_theme
, since all of the specified actions fire later than after_setup_theme
. With add_action()
, you’re simply telling WordPress, “queue up this callback at the specified action.” With remove_action()
, you’re simply telling WordPress, “remove this callback from the specified action.”
Edit
In re:
Great answer – thanks. I understand most of it, but a little confused why all my calls to hooks with the
add_action
andremove_action
are ok but the call towp_enqueue_scripts
isn’t? They all fire afterafter_setup_theme
. I know you said it’s because I can’t executewp_enqueue_scripts
beforeinit
; though without you telling me that how would I know? For example, how do I know if there is anything else that can’t be executed before something else.
Because add_action()
simply queues up a callback, inside of which functions are actually executed. But functions like wp_enqueue_script()
or wp_enqueue_style()
are actually functions, that execute wherever you call them.