I have a few questions relating to WordPress loading / unloading up javascript tools. After reading a nicely written response to a question by Pieter Goosen, that got me to do a bit of studying and a clean up of the code I'm using to load up my libraries. This code is from my child-theme's function.php file. I've got a few functions on my site that use the datepicker calendar tools. Additionally there are a few plugins that I'm sure use jQuery.

function jquery_loadup() {
        //wp_deregister_script('jquery');    <--- ?H
        wp_enqueue_style('jquery-style', 'http://ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/themes/smoothness/jquery-ui.css');

I was under the impression that the line wp_deregister_script('jquery') essentially resets/clears all previous 'requests' for the jquery scripts so they don't interfere with one another. That line followed by wp_enqueue_script('jquery'); should result in a minimal clean load of jQuery via the WordPress commonly used scripts registered handle / script paths system, no? I would think that the deregister call tests for the presence of a previous 'install' for jquery, and if it finds one or more, stops their loading, if none are registered, do nothing.

What I'm seeing is that when I use the wp_deregister_script('jquery') I'm get an error on the websie "ReferenceError: jQuery is not defined". When this happens, all of my JavaScript functions fail. What the heck? When remarked out, the site functions fine.

Questions: Am I missing something? What am I not understanding about the deregister call? Why would I be getting an error message?

Note, the line in there for jquery-migrate is supposed to be for software using older versions of jQuery. I tested it, but I can't see that it does anything on my site, so I've taken it out to improve download and response times. Question: Is that a bad idea?


  • wp_deregister means you unregister 'jquery'. So when you call 'jquery' with wp_enqueue_script('jquery'), WordPress could not find jquery, because you already unregister. So, your app that needs jQuery also fail.
    – ucon89
    Jul 3, 2014 at 7:41
  • Huh? Oh.. now I get it... that makes total sense. That zero's out the jquery scope now defined by Wordpress system. Nobody wants to mess with that. But wait... how does wordpress know how to stop the mess left by 8 different plugins all trying to add different versions of jquery? Also, go ahead and reply to the question so I can vote you up?
    – zipzit
    Jul 3, 2014 at 7:53

2 Answers 2


Wordpress has essentially two groups of methods to handle scripts, both of which should be used:

  • wp_register_script Registers a script in Wordpress. It does not get called, it is just available for Wordpress, if it is needed.
  • wp_deregister_script is the exact opposite. It deletes the definitions made in wp_register_script, the script is no longer available as a dependency or for enqueueing.

The registered scripts do not output anything in code. They just define the script programmatically so WP can react on dependencies and enqueues.

  • wp_enqueue_script actually defines and queues a script for outputting in the header/footer of the HTML page.
  • wp_dequeue_scriptdoes the exact opposite and dequeues a script for outputting.

The actual printing happens on the action 'wp_head' or 'wp_footer', depending on the register details.

An example:

wp_register_script('jquery', ("https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"), false, '1.9.1', true);

wp_enqueue_script( 'script-1', get_template_directory_uri() . '/js/example1.js', array('jquery'), '1.0.0', false );
wp_enqueue_script( 'script-2', get_template_directory_uri() . '/js/example2.js', array('jquery'), '1.0.0', true );
wp_enqueue_script( 'script-3', get_template_directory_uri() . '/js/example3.js', array('jquery'), '1.0.0', true );
wp_enqueue_script( 'script-4', get_template_directory_uri() . '/js/example4.js', array('jquery'), '1.0.0', true );
wp_enqueue_script( 'script-5', get_template_directory_uri() . '/js/example5.js', array('jquery'), '1.0.0', true );

In this example I deregister jQuery. It is no longer avalable and I would get the same error as you, if I would not register it again. (This time from the Google CDN in the hope, that it speeds up my page.)

But upon line three jQuery will not be printed. It will not appear anywhere. But from line four I call a bunch of scripts, which all have jquery as a dependency. The first one resides in the header, all the others in the footer. Due to the dependencies, jQuery gets automatically enqueued in the header, because it is first needed there.

So, with the scripts system of Wordpress, which is quite solid, there is no need to handle interferences or previous requests. Registered scripts are called when needed once, and only when needed.

In your example you deregister the script in line 1 of the function and call it again in line 2. But due to deregistering Wordpress has forgotten all of the details as URL, Version, dependencies, and so forth. The correct function in you logic would have been wp_dequeue_script, but even that isn't needed. Wordpress evaluates the need by either looking at the enqueued scripts, or the dependencies.


how does wordpress know how to stop the mess left by 8 different plugins all trying to add different versions of jquery?

The last instance of registering jquery before the wp_print_scripts action is the one that get's printed. That is essentially what the priority system in actions/filters is for.

  • That makes more sense to me now... Two notes 1) As do more searching I see that in wordpress core jquery = jquery.js & jquery-migrate.js (oops.. answered my other question right there!) per codex.wordpress.org/Function_Reference/…. 2) I'm still confused what happens when 8 different plugins all try to REGISTER and then enqueue their own version of jquery. Which one trumps? Is this like CSS specificity?
    – zipzit
    Jul 3, 2014 at 8:12
  • The last register call that runs is the one that trumps. Keep in mind: Nothing ever runs simultaneously, everything runs after one another, you just have to understand the order at which things run. Jul 3, 2014 at 8:16

Just to chip in,first of all, thanks for the complement, appreciated.

You are using a child theme, of which the parent theme should have enqueued the jquery library built into wordpress. Like I said in the post you are refering to, it is bad practice, my emphasis, for any parent theme to not enqueue jquery by default.

You have a couple of problems with your code. First of all, never deregister the default jquery library, you will break somethings later on. The correct way is to dequeue the script using wp_dequeue_scripts.

Just one question though here, why do you need to dequeue jquery and requeue it. This is usually used by plugin authors just to make sure that jquery doesn't load twice, the reason being here, plugins works on all themes, so it is impossible to know if the theme a user is using with the plugin have jquery loaded. You are running a child theme that will only work on that specific parent theme, so you will know if the parent theme have jquery loaded. So there is no need to dequeue and requeue.

Secondly, you will have to look at priority. add_action have 4 parameters, the third one being priority ($priority). Usually plugins and child themes load their scripts after a parent theme to ensure that it doesn't get overrun later on. So it is wise and good practice to run your action dead last. To to this, you will need a very low priority, ie very high number.

  add_action( 'wp_enqueue_scripts', 'jquery_loadup', 999 );

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.