Use wp_enqueue_scripts, not wp_print_styles, to enqueue scripts and styles for the frontend
If you are enqueueing scripts and styles, you will want to use one of these three hooks:
- wp_enqueue_scripts (for the frontend)
- login_enqueue_scripts (for the login screen)
- admin_enqueue_scripts (for the admin dashboard)
Don’t let the names fool you — they are for both scripts and styles. We’ll probably add equivalent *_enqueue_styles hooks in 3.4 just to make it more obvious, but these hooks have all existed for some time now.
A possible incompatibility with WordPress 3.3 could arise if you are using the wp_print_styles hook to enqueue styles — your styles may end up in the admin.
The fix: Use wp_enqueue_scripts instead. Yes, it’s that easy.
Edit: Yes, the same goes for registering styles. Registering or enqueueing (styles or scripts) should occur on *_enqueue_scripts.
(Background: #19510)
Jared 4:58 pm on December 12, 2011 Permalink
Whoops, I’ve been using wp_print_styles – thanks for the heads up!
Austin Passy 5:10 pm on December 12, 2011 Permalink
Will start the update to my plugins. Especially the
login_enqueue_scriptsthat should come in handy for my login plugin.Jamàl 5:18 pm on December 12, 2011 Permalink
Will this effect
wp_register_style();as well?Andrew Nacin 5:35 pm on December 12, 2011 Permalink
Registering should also occur on _enqueue_scripts.
Nikolay Bachiyski 9:17 pm on May 9, 2012 Permalink
@nacin, How do you make sure the script is registered before somebody tries to enqueue it?
Andrew Nacin 5:03 am on May 11, 2012 Permalink
@nbachiyski You can use `wp_script_is( $handle, ‘registered’ )` — but generally you are not going to see registration and enqueueing happen in such a way that the method and timing of registration is unknown to the code doing the enqueue.
Nikolay Bachiyski 11:26 am on May 11, 2012 Permalink
@nacin,
wp_script_is()will just tell me that the script isn’t registered, which isn’t very helpful. I want to have an easy way (adding hook priorities isn’t easy) to make sure the registering is done before the enqueuing.I’ll give you a practical example. On WordPress.com we have a library for AJAX spinners. It’s enqueued in many places, by many different pages. How do I register it, so that I’m sure nobody will try to enqueue it before that?
I see two solutions:
I hope I’m missing something obvious here
Banago 5:52 pm on December 12, 2011 Permalink
wp_enqueue_script used to put scripts i.e. JavaScript in the backend too. It it this behavior that has been changed?
Joachim Kudish 6:44 pm on December 12, 2011 Permalink
Just to make sure, this is backwards compatible (at least for 3.2) as well?
Andrew Nacin 8:21 pm on December 12, 2011 Permalink
Yes, 100% backwards compatible. login_enqueue_scripts was added in 3.1, but wp_enqueue_scripts and admin_enqueue_scripts were both added much earlier (2.8, I think).
Joachim Kudish 8:29 pm on December 12, 2011 Permalink
Right on.
camu 7:45 pm on December 12, 2011 Permalink
So, in other words, this article by Scribu is not valid anymore? http://scribu.net/wordpress/optimal-script-loading.html (linked from the official WP documentation, http://codex.wordpress.org/Function_Reference/wp_enqueue_script ) I’m asking because I need the registration and the “printing” to happen separately from each other. Unless there’s some other way to enqueue scripts in the footer. I’ve tried to use the last param in wp_enqueue_scripts, but if the template doesn’t call wp_head(), it fails… Separating registration and printing is the only way to solve this issue, afaik.
Camu
Andrew Nacin 8:30 pm on December 12, 2011 Permalink
That article is fine, and doesn’t have to do with the issue here. (You’ll note that the
wp_print_styleshook is not used.) However, WordPress 3.3 allowswp_enqueue_script()to work mid-page, which means most of that Jedi logic is no longer needed.Camu 8:41 pm on December 12, 2011 Permalink
Thank you for clarifying
ray 2:02 pm on March 15, 2012 Permalink
I’m doing this:
http://twentyfiveautumn.com/2012/03/14/loading-javascript-on-the-frontend-with-your-wordpress-plugin/
I don’t know it that helps or not…
kwight 7:58 pm on December 12, 2011 Permalink
How does wp_enqueue_style fit in to the mix (which I believe loads on both the front- and back-end)? I’ve just been wrapping it in an is_admin conditional up to this point…
kwight 7:59 pm on December 12, 2011 Permalink
Oops, just noticed the wp_register_style comment above – clears that up then.
Andrew Nacin 8:29 pm on December 12, 2011 Permalink
We’re only referring to the hooks
wp_print_stylesandwp_enqueue_scripts. The actual functions,wp_enqueue_style()orwp_enqueue_scripts()should be called from hooks, not directly in the plugin body. (Which is what the post is about.)Ken Newman 8:12 pm on December 12, 2011 Permalink
What about scripts/styles only for particular settings pages: any gotchas? (Is “admin_print_styles-$hook_suffix” still good or is there something better?)
Andrew Nacin 8:27 pm on December 12, 2011 Permalink
While admin_print_styles-$hook_suffix is not as bad as wp_print_styles, note that the admin_enqueue_scripts hook does pass the $hook_suffix as the first parameter:
do_action('admin_enqueue_scripts', $hook_suffix);Kenneth Newman 10:08 pm on December 12, 2011 Permalink
Very good then. I see lots of source do admin_print_styles… It’s in core, twentyeleven, and popular plugins (so it can’t be terrible) but I’ll stick with the better new hotness tho in future
Kenneth Newman 10:17 pm on December 12, 2011 Permalink
You’re post about get_current_screen() as an alternative to $hook_suffix is helpful related to this http://wpdevel.wordpress.com/2011/12/06/help-and-screen-api-changes-in-3-3/
redwall_hp 2:36 am on December 13, 2011 Permalink
That’s good to know. I don’t think I have any hooked on print_styles, but I think I might have on init on a few sites (with an if !is_admin() inside the function). That’s probably not great either, but at least it’s not going to blow up right away.