Question about the way that wp_register_script works

Ok so I’m using the Roots Theme for WordPress (https://github.com/retlehs/roots), which, is sort of a starter theme or theme framework.

I’m confused about the way that it deregisters the WordPress loaded version of jQuery and but it registers it again without specifying the exact location of the script.

Read More

So in the header.php of the theme there’s this code:

...
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js"></script>
  <script>window.jQuery || document.write('<script src="<?php echo get_template_directory_uri(); ?>/js/libs/jquery-1.6.4.min.js"></script>')</script>
...

,which, reads to me: ‘download the Google hosted jQuery script but if for some reason the jQuery object isn’t present then just create a script element that loads the script that comes with the theme.

However, inside a theme file called roots-cleanup.php that is included in the functions.php of theme there is this code that deregisters the jQuery script that comes with WordPress but immediately registers jQuery again without really specifying the script’s url:

...
function roots_head_cleanup() {
  ...

  // don't load jQuery through WordPress since it's linked in header.php
  if (!is_admin()) {
    wp_deregister_script('l10n');
    wp_deregister_script('jquery');
    wp_register_script('jquery', '', '', '', true);
  }
}

add_action('init', 'roots_head_cleanup');
...

Now I went to see what the documentation says about this and it says something like: “This parameter [the location parameter] is only required when WordPress does not already know about this script.”

So I’m wondering, by including the script tags that load jQuery in the header.php does that mean WordPress is aware of them as far as calling wp_register_script goes? Like so:

wp_register_script('jquery', '', '', '', true);

I’m asking because I wanted to try this technique but I didn’t get the results I expected. Namely, javascripts that I included using wp_enqueue and that depended on jQuery still loaded even when I removed the script tags that includethem in the header, which, means the javascripts I loaded failed because there was no jQuery being loaded. This also tells me that WordPress isn’t necessarily aware of the jQuery script if I don’t specify the location paramater.

Related posts

Leave a Reply

1 comment

  1. For the record this entirely the wrong thing to do.

    Themes should avoid (read never!) de-register the WordPress registered jQuery scripts (plug-ins should absolutely never do this).

    If a theme is to de-register the jquery script (to replace it) then it should re-register it properly:

     wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js');
    

    Here-in lies the problem. The above is taken from the codex. The jQuery version above is now out of date, and potentially, could break plug-ins. This is why themes and plug-ins should avoid replacing the jQuery version.

    The theme above is a wonderful demonstration of poor practise. Not only does it not re-register jQuery properly, but it then proceeds to print it directly in the header (regardless of when its needed).

    In answer to:

    So I’m wondering, by including the script tags that load jQuery in the header.php does that mean WordPress is aware of them as far as calling wp_register_script goes?

    No.

    I’m asking because I wanted to try this technique but I didn’t get the results I expected. Namely, javascripts that I included using wp_enqueue and that depended on jQuery still loaded even when I removed the script tags that includethem in the header, which, means the javascripts I loaded failed because there was no jQuery being loaded

    Yup, WordPress thought jQuery was being loaded (but actually ” was passed as the path to the file – this probably should have caused an error.). Hence your scripts were still loaded, even when jQuery wasn’t actually loaded.

    wp_register_script (and the related functions) exist to load javascript, while handling dependencies, in a conflict-free way. Not using it, as this theme is trying to do, breaks things.