I'm doing it right now with the following code:

function uw_load_scripts() {
    // De-register the built in jQuery
    // Register the CDN version
    wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array(), null, false); 
    // Load it in your theme
    wp_enqueue_script( 'jquery' );
add_action( 'wp_enqueue_scripts', 'uw_load_scripts' );

This works, but should I do this for everyone, like this, or for everyone but admin (so that backend uses the WordPress version?):

if (function_exists('load_my_scripts')) {  
function load_my_scripts() {  
    if (!is_admin()) {  
    wp_deregister_script( 'jquery' );  
    wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array(), null, false); 
add_action('init', 'load_my_scripts');

This version doesn't work at all actually, I get the WordPress jQuery-version and not the Google one.

Therefore, should I deregister the jQuery that is included in WordPress at all?

Also, how do I add my own scripts (slider scripts, modernizr and my own custom.js) the correct way? I guess I should do this via functions.php as well and not in the header like I'm doing it now, but I'm unsure of how I would do that.

6 Answers 6


First rule of thumb: do not deregister core-bundled scripts and replace with other versions, unless you are absolutely certain that no Theme, Plugins, or core itself will break due to the version change. Really, unless you absolutely need an alternate version of a core-bundled script, just use what is bundled with core.

Second, I strongly recommend hooking into wp_enqueue_scripts for script registering and enqueueing, rather than init. (It works at init, but from a play-nicely-with-others perspective, it's best to use the most semantically correct hook.)

Third, to enqueue your own custom scripts, you use the same methods as above:

function wpse45437_enqueue_scripts() {
    if ( ! is_admin() ) {
        $script_path = get_template_directory_uri() . '/js/';
        // Enqueue slider script
        wp_enqueue_script( 'wpse45437_slider', $script_path . 'slider.js', array( 'jquery' ) );
        // Enqueue modernizr script
        wp_enqueue_script( 'wpse45437_modernizr', $script_path . 'modernizr.js', array( 'jquery' ) );
add_action( 'wp_enqueue_scripts', 'wpse45437_enqueue_scripts' );

Just add whatever scripts you need to enqueue.

  • 4
    +1 on the absolutely need to! Too many (usually 'premium') themes register an outdated version of jQuery. It breaks plug-ins. Commented Mar 13, 2012 at 14:48
  • Adding this script into my functions file (without the php declarations since they are already there) gives me a 'Http-error 500 (Internal server error)'. Is there an error somewhere?
    – Johan Dahl
    Commented Mar 13, 2012 at 15:42
  • Yes; there was a syntax error in the wp_enqueue_script() calls. Commented Mar 13, 2012 at 15:45
  • Thanks now it works! However it is still outputted in the header. Is it not better if it where in the footer? If so, can I modify the code so it will?
    – Johan Dahl
    Commented Mar 13, 2012 at 16:07
  • You can certainly enqueue in the footer. Just set the $in_footer parameter to true in your call to wp_enqueue_script(). Commented Mar 13, 2012 at 16:13

Hope this helps, look up the codex for wp_enqueue_scripts for more information.

  1. Dont use init to enqueue. Use wp_enqueue_scripts for front-end stuff and admin_enqueue_scripts for admin side. You can use init to register scripts though.
  2. The hook wp_enqueue_scripts only fires on the front-end (and not on the log-in page) - so you don't have to check is_admin().
  3. Unless you have a specific reason to do otherwise, I would suggest registering and queuing scripts using functions.php for themes or in a plug-in otherwise. You simply put:

     function myprefix_load_scripts() {
       // Load scripts here
     add_action( 'wp_enqueue_scripts', 'myprefix_load_scripts' );
  4. If the aim is to enqueue a script when a shortcode is used, you may wish to use wp_enqueue_script in the shortcode callback to queue it only when needed (this will print it in the footer since 3.3).

  5. You shouldn't re-register the existing jQuery on the admin side. You may break something :D.

  6. Plug-ins should not re-register the existing jQuery.

  7. You should weigh up the pros and cons of re-registering jQuery. For instance it may break some plug-ins if you register an old version (maybe not now, but in the future...)

  • 1
    Ad 5) re-registering doesn't really matter. That's why we got the enqueue and register functions. :)
    – kaiser
    Commented Mar 13, 2012 at 14:54

Fair warning: deregistering WP's packaged version of jQuery in favor of your own can cause problems, especially if you aren't extra careful to make sure that you change the version you're pointing toward whenever WP updates its version. This goes doubly for plugins, which often (or often should, at least) write their plugins for maximum compatibility with the WP version of jQuery.

That said, your first version is correct - it's hooked to wp_enqueue_scripts. Your second function is hooked to init, which may be why it's not working properly.

Add your own scripts in a similar manner:

function bbg_enqueue_scripts() {
    // You should probably do some checking to see what page you're on, so that your
    // script only loads when it needs to
    wp_enqueue_script( 'bbg-scripts', get_stylesheet_directory_url() . '/js/bbg-scripts.js', array( 'jquery' ) );
add_action( 'wp_enqueue_scripts', 'bbg_enqueue_scripts' );

I'm assuming here that you are loading scripts from a js directory in your current theme directory; change the URI parameter if that's not true. The third parameter array( 'jquery' ) says that bbg-scripts depends on jquery, and so should be loaded afterward. See https://codex.wordpress.org/Function_Reference/wp_enqueue_script for more details.

if (function_exists('load_my_scripts')) {  
function load_my_scripts() {  
    if (!is_admin()) {  
    wp_deregister_script( 'jquery' );  
    wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array(), null, false); 
add_action('init', 'load_my_scripts');

This isn't going to do anything... I suspect you mean

if (!function_exists('load_my_scripts')) {

Your example will only load the function load_my_scripts if it already exists (which it doesn't so it won't and if it did it would create an error)


If, for performance reasons, you want to load jquery and other core js-files from a CDN, make sure you are loading the same version to prevent nasty things happening with core and plugin functions. Like this:

$wp_jquery_version = $GLOBALS['wp_scripts']->registered['jquery-core']->ver;
$jquery_version = ( $wp_jquery_version == '' ) ? '1.8.3' : $wp_jquery_version; // fallback, just in case 
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/'. $jquery_version .'/jquery.min.js', $jquery_version, false );

After checking all different methods for loading jquery (not only on this post), I realized that none of them do all of these:

  1. Register (and perhaps enqueue) jquery using a function , so it can be used by plugins.
  2. Load it from Google CDN with protocol relative url.
  3. Fallback to local copy if Google is offline.

There a lot of alternate versions doing some of these in the list, but not all, so I wrote my version combing and modifing some of the methods already available. Here it is:

function nautilus7_enqueue_scripts() {

    // Load jquery from Google CDN (protocol relative) with local fallback when not available
    if ( false === ( $url = get_transient('jquery_url') ) ) {

        // Check if Google CDN is working
        $url = ( is_ssl() ? 'https:' : 'http:' ) . '//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js';
        $resp = wp_remote_head($url);

        // Load local jquery if Google down
        if ( is_wp_error($resp) || 200 != $resp['response']['code'] ) {

            $url = get_template_directory_uri() . '/js/vendor/jquery-1.7.2.min.js';

        // Cache the result for 5 minutes to save bandwidth
        set_transient('jquery_url', $url, 60*5);

    // Deregister Wordpress' jquery and register theme's copy in the footer
    wp_register_script('jquery', $url, array(), null, true);

    // Load other theme scripts here

add_action('wp_enqueue_scripts', 'nautilus7_enqueue_scripts');

In order to save bandwidth and not ping Google every time the page is reloaded it remembers whether Google CDN is online or not for 5 minutes using the Wordpress Transient API.

  • Not recommended. Now you have to update the script after each WordPress update to match the exact jQuery version WordPress is using. Plus, Google fails to send the library compressed in some cases, so your page is loading slower now.
    – fuxia
    Commented May 6, 2012 at 15:11
  • I am not using wordpress' jquery. Read the code please. I am using the theme's version. And if you don't like google, you can use another cdn.
    – nautilus7
    Commented May 6, 2012 at 15:19
  • But that's the point: You should use the WordPress jQuery to make sure the version is correct.
    – fuxia
    Commented May 6, 2012 at 15:22
  • I don't follow you. I grab whatever version I need from google and I bundle the same version with my theme. That's how everyone is doing it. Wordpress can use (in the admin section) whatever version it comes with.
    – nautilus7
    Commented May 6, 2012 at 15:29
  • 1
    You can use what ever version of jQuery you want but if you are bundling it with a theme you are forcing this on your users. A few years from now when everyone is using jQuery 1.8.2 your users will be stuck on an outdated version unless they keep the theme up to date.
    – Chris_O
    Commented May 7, 2012 at 1:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.