This is a topic that has been covered numerous times, including several times on this site, but I still find theme and plugin developers that are either unaware of the negative consequences or simply disregard them. I’d like to talk a bit about why exactly removing the default version of jQuery in WordPress and loading one from elsewhere, such as Google, is terribly irresponsible.



The process of removing the default jQuery in WordPress and making it load from Google looks like this:

1 2 3 4 5 6 7 8 function pluginprefix_load_scripts ( ) { if ( ! is_admin ( ) ) { wp_deregister_script ( 'jquery' ) ; wp_register_script ( 'jquery' , 'http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js' , false , '1.9' ) ; wp_enqueue_script ( 'jquery' ) ; } } add_action ( 'wp_enqueue_scripts' , 'pluginprefix_load_scripts' ) ; function pluginprefix_load_scripts() { if ( !is_admin() ) { wp_deregister_script('jquery'); wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js', false, '1.9'); wp_enqueue_script('jquery'); } } add_action( 'wp_enqueue_scripts', 'pluginprefix_load_scripts' );

It’s an unfortunately very common practice for themes, and some plugins, to do this. Usually the developer does it because he or she believes they are improving the load times of the site using the theme/plugin, or perhaps they’re gaining access to new features in the latest version of jQuery that isn’t yet available in WordPress core. I’ve seen themes and plugins do this simply because they read a tutorial that said it was the best thing to do.

The big question is: why is this bad?

There are many reasons, and I will touch on each briefly.

1. WordPress Loads jQuery in noConflict Mode

The purpose of noConflict mode is to help ensure there are not compatibility problems between jQuery and other javascript libraries loaded into WordPress. In short, noConflict mode means that the standard $ short cut used in jQuery (and other javascript libraries) is not usable, and must be replaced with jQuery.

As shown by the WordPress codex,

1 2 3 $ ( document ) . ready ( function ( ) { $ ( #somefunction ) ... } ) ; $(document).ready(function(){ $(#somefunction) ... });

becomes

1 2 3 jQuery ( document ) . ready ( function ( ) { jQuery ( #somefunction ) ... } ) ; jQuery(document).ready(function(){ jQuery(#somefunction) ... });

or

1 2 3 4 jQuery ( document ) . ready ( function ( $ ) { // $ has been declared as a "short cut" to jQuery $ ( #somefunction ) ... } ) ; jQuery(document).ready(function($){ // $ has been declared as a "short cut" to jQuery $(#somefunction) ... });

You can also use your jQuery like this (when in noConflict mode):

1 2 3 ( function ( $ ) { // $() will work as an alias for jQuery() inside of this function } ) ( jQuery ) ; (function($) { // $() will work as an alias for jQuery() inside of this function })(jQuery);

So why is loading jQuery from Google (or anywhere else) bad? It’s bad because it is not loaded in noConflict mode, and that can very often result in error messages, such as this:

Uncaught ReferenceError: jQuery is not defined and Uncaught SyntaxError: Unexpected token <

This kind of error happens because the non-standard jQuery library loaded expects you to write your jQuery like this:

1 2 3 $ ( document ) . ready ( function ( ) { $ ( #somefunction ) ... } ) ; $(document).ready(function(){ $(#somefunction) ... });

instead of the proper (in WordPress) way:

1 2 3 jQuery ( document ) . ready ( function ( $ ) { $ ( #somefunction ) ... } ) ; jQuery(document).ready(function($){ $(#somefunction) ... });

Since WordPress loads jQuery in noConflict mode and plugin/theme developers (who are doing it right) rely on jQuery being loaded that way, choosing to force WordPress to use a Google library that is NOT in noConflict mode is hugely irresponsible as it can often result in jQuery errors getting thrown when plugins expecting jQuery to be loaded as default from WordPress are used.

2. Increased Support Load for Other Developers

One of the arguments I often see for loading jQuery from Google (and ignoring the advice of many, many prominent members of the WordPress community) is that "it doesn't cause any problems".

Theme developers (sometimes plugins) often feel it's perfectly acceptable to load jQuery from Google because they have not personally received support tickets indicating there is a problem.

If developers of the themes loading jQuery don't get problem reports, how do they know there is a problem? It's simple: plugin developers get support tickets from users of the theme.

Plugin developers are almost always blamed (by the users) for problems in themes because the plugin is installed after the theme, so when a problem pops up after a plugin is installed, it is naturally assumed that the plugin caused it. When in the case of jQuery conflicts, however, it is nearly always the theme causing the problem. I say it's nearly always the theme simply because plugins that have a need for loading custom jQuery are much further and far between, but that doesn't mean plugins aren't the culprits too.

I have personally spent 100 hours or more on support tickets related to problems caused by themes or plugins loading custom jQuery.

Yesterday a theme developer told me "I have never gotten problem reports about jQuery, so how can it be bad?". He can think that but I know for fact that I (and my support team) have received at least 10 tickets directly related to jQuery conflicts caused by his theme.

It is hugely irresponsible as a developer to assume your code doesn't cause problems simply because you don't get reports of it when other developers are giving you report after report.

3. Themes Should Not Modify Core WordPress Behavior

Another topic that has been discussed at length is whether themes should add functional "features" to (or take away from) WordPress. Here's an article I wrote on it for WP Tuts+.

The key point of the discussion is simply that themes should mostly control the appearance of your site and plugins should control the functionality (e-commerce, custom post types, sliders, etc).

Plugins and WordPress itself rely on jQuery for tons of tasks, which means that when jQuery is modified the hundreds of tasks performed by plugins or WordPress core are also modified. In short, swapping out the default jQuery for a different version is a direct modification of the default behavior of WordPress, and a behavior that plugins rely on (and should be able to rely on).

Themes should never take it upon themselves to try and improve the performance of a site, except to ensure that all queries and layouts in the theme are performant. Attempting to improve performance of plugins or WordPress core itself is something themes have no business doing.

Assuming that your needs in a theme are more important than the needs of WordPress core and thousands of possible plugins is hugely irresponsible. There is a very good reason WordPress ships with its own version of jQuery: all developers can safely rely on it.

4. WordPress Updates the Bundled jQuery Version Frequently

One of the other reasons I've heard for loading your own jQuery is that WordPress doesn't always use the latest version available. This is a fair point, especially if the jQuery you are writing requires a newer version.

Interestingly, this is pretty ironic. Want to know what version of jQuery is almost always being loaded on sites that have conflicts? 1.4.4.

Yes, that's right, 1.4.4 (or other similarly old versions).

So the same developers that are arguing that they need newer versions than WordPress ships with are neglecting to update their code to load the new versions?

This is actually probably not so much because of the developers forgetting to update their versions (sometimes it is), but is more likely because a user of the theme has never updated to the new version that includes the updated jQuery. This is really, really common because users simply don't like to update. They especially do not like to update their theme.

A user is much more likely to update WordPress core than they are to update their theme. Know what happens when WordPress core is updated? jQuery is updated. Know what happens when a theme that loads an old version of jQuery is not updated? Conflicts galore.

The easy way to avoid this problem is to simply not offload jQuery.

5. There is One Good Way to Load Custom jQuery

If you absolutely must use a new version of jQuery, then I implore you to please, please do it only via the Use Google Libraries plugin. This is a plugin that will retrieve the Google libraries you need and load them exactly as WordPress code does (jQuery in noConflict mode for example), meaning that plugins relying on one of the core WordPress scripts will continue to function perfectly fine.

It is trivial to require a plugin in a theme.

There is only one reason a theme should ever need to require a newer version of jQuery, and that is simply if the newer version includes methods used in the theme that do not exist in the current version loaded in WordPress.

[divider]

If you do not believe or agree with any of this, I strongly encourage you to write a plugin that relies on jQuery and release it. Once the plugin has been used by a large number of users, I guarantee you that conflicts with themes or plugins loading their own jQuery will be encountered and you will then fully understand why this is so incredibly frustrating.

6. Addendum: Theme Repositories Do Not Permit Replacing jQuery

Many theme repositories, including the official WordPress.org repository and ThemeForest.net, do not permit themes to replace the default version of jQuery. If you wish to have your theme listed in one of the large, popular repositories, do yourself a favor and don't even try.