Take the 2-minute tour ×

I am using WordPress 3.1.4 by now. I am confused with where (which hook) do I use:

  • to register and/or enqueue
  • scripts and styles
  • on front- and back-ends?


  • Which are right hooks to use?
  • All front end register/enqueue scripts/styles in init?
  • Why is there no admin_print_styles-{xxx}?
share|improve this question

1 Answer 1

up vote 49 down vote accepted

Why registering and queuing properly matters

  • it should be in time - earlier than script/style is up for being output to page, otherwise it is too late;

  • it should be conditional - otherwise you are loading stuff where you don't need it and cause performance and functionality issues, for this you need WP environment loaded to late stage.

The three stages of the process

  1. register - this explains WP details about script/style and makes it store that info;

  2. enqueue - (often lumped together with register in one wp_enqueue_*() call) - this tells WP to add scripts/style to the queue, according to its settings (dependencies, header/footer loading).

  3. print - this happens when WP processes queue, tries to load something specific for itself or when you explicitly do it with wp_print_*() function.

Front-end structure of functions and hooks

  • wp_head()

    • wp_head

      • (1) wp_enqueue_scripts()

        wp_enqueue_scripts « this is what you need

      • (8) wp_print_styles()

      • (9) wp_print_head_scripts()

  • wp_footer()

    • wp_footer

      • (10) wp_print_footer_scripts()

It goes much deeper, but this is simple and good enough for important points:

  • wp_enqueue_scripts is most appropriate hook for registering and queuing scripts and styles on front end and it is there specifically for that;

  • init has nothing to do with this, it will work, but - past Codex recommendation to use only it was incorrect;

  • you can get away with queuing scripts (not styles) for footer at any point before wp_print_footer_scripts() call;

  • wp_print_* hooks are NOT appropriate for register/queue, they are points in code when output is already happening. They are appropriate for manual/custom script/style output.

What about admin?

Well, the functionality there is even more complex, elaborate and nested.

  • for starters just use admin_enqueue_scripts hook (it gets passed $hook_suffix global for conditional stuff) for everything, it will do nicely for most cases;

  • when you need something complex - look through admin-header.php and dig from there for appropriate hooks.

What about login?

There's a specific hook named login_enqueue_scripts.

share|improve this answer
Hmm in another answer to another question, I was recommended admin_print_scripts-{xxx}. I found that admin_print_scripts was called but not with -{xxx} eg. -edit.php for example. How right is that answer of enqueuing in admin_print_scripts-xxx and what will you recommend instead - suppose I want to include scripts/styles in a custom post type add/edit page (for metabox) –  JM at Work Jun 30 '11 at 9:33
@JM at Work as above my personal opinion - stay away from *print* hooks unless you really know why you need them. And overall they are for print, not queue. admin_enqueue_scripts hooks passes $hook_suffix variable that is same as used in those dynamic hooks. –  Rarst Jun 30 '11 at 9:40
+1 for the great in depth explanation. –  Hameedullah Khan Jun 30 '11 at 9:41
$hook_suffix looks like post.php in my edit portfolio page why is that? I thought it was edit.php also, how do I then determine if I am editing/posting a portfolio & not a normal post? –  JM at Work Jul 8 '11 at 2:44
@JM at Works honestly that variable is somewhat nasty :) In own plugin it's easier to deal with it (return of add_*_page() function), but in native WP screens it can be different things. –  Rarst Jul 8 '11 at 15:36

Your Answer


