Since the recent update of version 3.4, many users have started to experience issues with their sites not working correctly, particularly due to JavaScript features such as datepickers, autocompleters, etc. failing to work as before.
For plugin developers like myself, it’s a pain in the @!+ as I’m now seeing users run into this problem on a daily basis for a few weeks now, and it has become obvious that the problem in every case is the forced loading of jQuery library files from CDNs, particularly Google.
The aim of loading jQuery libraries from external sources is to speed up page loading time, so no wonder why theme makers jump at this quick speed upgrade.
However, whilst there’s nothing wrong with doing this theoretically, they way they’re going about it couldn’t be more wrong! The various misleading posts circulating the web are most likely the cause of such a widespread problem, and now we’re starting to see the consequences as time passes.
Why is this wrong?
As I mentioned above, there’s nothing wrong with loading files from a CDN, however, there’s two major things themes do wrong:
The first major issue is that I have yet to see a theme that does this load the latest jQuery version used by WordPress! This presents a load of problems because other plugins that rely on the jQuery library are forced to use outdated libraries which may conflict with some of the code written with later library versions in mind.
The second major mistake is that they’re taking it upon themselves to do this in the first place. My opinion is that themes have no place in messing with the jQuery libraries and WordPress dependencies. Themes should must take into account that plugins will be installed, and these plugins should have access to the standard libraries provided by WordPress.
How can I check if I have this problem?
The major browsers these days all have their own code viewers which makes it easy to check which scripts are loaded. The screenshots below show how this is done in Google Chrome, which is also similar to doing this with FireFox and the Firebug extension.
To bring up the developer window, right click anywhere on the webpage and the click on ‘Inspect Element’. You’ll see a window appear similar to the one below, click the Sources (in FireBug it’s Scripts) tab, and look at your scripts there:
As you can see, the location of the jquery.js file is on the Google server, and clicking on that file shows you the contents which includes the version number (it’s also usually in the URL). In this case, the theme is loading jQuery 1.4.4.
Where does my theme do this, and how do I fix it?
This is the most common question I get these days, which is what inspired this post. Thankfully, the approaches taken by most theme are the same, or similar therefore easy to identify. Unfortunately, not all will be so lucky.
In either case, when trying to find the location of where this is done, you’ll need to use search functions in your text editors.
Typical – functions.php
This is the usual situation.
wp_deregister_script('jquery'); wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js', false, '1.4.4'); wp_enqueue_script('jquery');
The solution is easy though, just delete it! WordPress will then start loading its own copy of the jQuery library.
Worse – header.php
Less often, but astoundingly too often, some themes go ahead and hard-code the jQuery file with pure html similar to:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js" />
This is worse because it goes against the whole dependency system WordPress uses to load the right scripts during the wp_head() function executed usually within the header.php file.
The fix involves one to three steps (depending on how many mistakes your theme maker made):
Step 1 – Remove the line above.
Step 2 (if step 1 fails) – Your theme may be doing something even naughtier which is failing to include the wp_head() PHP function in your document head, meaning plugins like Events Manager can’t include its own javascript files. Try replacing the line you just deleted with this:
<?php wp_head(); ?>
Step 3 (if Step 2 fails) – If you had to add wp_head(), chances are you’ll need to add wp_footer() too, which is done within your footer.php file above the body closing HTML tag.
The upside once you fix this is that your theme will now work with more plugins. However, if you had to do step 2 or 3, you may want to reconsider where you get your themes from (if you made it yourself, lesson learnt i hope!).
Worst of all – unknown
Your theme maker decided to get uber fancy and demonstrate their skills by making this modification somewhere in the myriad of custom included files. Your best bet is to use a search tool and look at all your theme files for words like jquery or google.com. Chances are if the mod isn’t done in your header.php file, they used the method for the function.php file.
If your theme has found another ingenious way of doing this… I’d say your theme is too smart to be used on WordPress, save yourself the headache and move on.
The ‘Right Way’ to host external libraries
Whilst there’s more ways than one to do this, the two most sensible ways to do this are:
- Use a plugin that does this for you, such as Use Google Libraries and makes sure the right jQuery version is loaded according to your WP version.
- Host all your javascript, css, image and other files on a CDN such as Amazon S3 or CloudFront. It’s cheap and effective. Caching plugins such as Super Cache or W3 Total Cache make this very easy to set up and are well documented.
Between the two, if you can make use of minify functions (W3TC has this function) to merge all js files into one cached file, then the best choice is the second one if your end goal is increasing your page speeds and/or reducing your server load. However, if you’re on a budget, or you’re having issues minifying your scripts with caching plugins then Use Google Libraries will still help a lot and is highly recommended.
As you can see, these have nothing to do with your theme, as it should be!