CSS-Tricks suggests this code to load jQuery.

However, I'm curious if anybody has done the same thing in functions.php with two fallbacks: the Microsoft hosted jQuery being the first option and locally hosted jQuery being the second, that is, in the case the Google library decides not to load/crashes/gets eaten by a polar bear/etc.

if (!is_admin()) add_action("wp_enqueue_scripts", "my_jquery_enqueue", 11);
function my_jquery_enqueue() {
   wp_register_script('jquery', "http" . ($_SERVER['SERVER_PORT'] == 443 ? "s" : "") . "://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js", false, null);
  • +1 for the possibility of all Google servers "gets eaten by a polar bear" – ltfishie Jan 8 '13 at 20:31

I use a similar pattern to enqueue jQuery from the Google CDN (as the CSS Tricks example). However in my footer (typically footer.php) I'll usually hard code the following fallback.

<script type="text/javascript">
    if (typeof jQuery === 'undefined') {
        document.write('<script src="<?php echo get_stylesheet_directory_uri(); ?>/js/jquery.min.js" type="text/javascript"><\/script>');

Let me explain what this does and why I use it...

After jQuery is deregistered, registered, and enequeued, it'll be injected into the DOM at render time. The script example will need to be included after WordPress renderes wp_header or wp_footer (however you've queued it).

The script will check if jQuery is actually an object (if not, it'll be undefined because of a 404 error or whatever). Then it'll write out a script tag to load your own copy of jQuery from your theme.

What if the first CDN load fails? Doesn't that mean WordPress will think jQuery didn't load? No. WordPress won't have any knowledge of the CDN failing, but it'll still think some sort of external resource is being registered and enqueued (as jQuery) and you still gain the benefits of playing nice with other plugins that request jQuery.

I've not tried to create a method of attempting a load from Google's CDN and then Microsoft's CDN and then my own, however. I'd have to think further on a good way to asynchronously attempt that.

| improve this answer | |

To expand on what Jared Cobb wrote into a hook and a more simple check.

function inline_78740_jquery(){ ?>

<script type="text/javascript">
!window.jQuery && document.write('<script src="/wp-includes/js/jquery/jquery.js"><\/script>')

<?php }
add_action('wp_footer', 'inline_78740_jquery', 1);

There are real problems with this, if any plugins hook into wp_enqueue_script they might still break, especially is they are using $deps.

ps. I removed the Php for the src since you can use your theme dir or the wp-includes function includes_url, for example.

Honestly the small footprint loading Jquery locally provides is often a better solution to using a CDN, that way you don't have to worry about fallback or outdated CDN's.

Support local loading!

| improve this answer | |
  • Wyck, interesting method. What would cause a plugin hooking into wp_enqueue_script to still break? It would seem like the hook would happen, the CDN would fail to load, but the fallback would provide jQuery as normal. – Jared Cobb Jan 8 '13 at 20:19
  • Actually there is a chance they still work, I should have said "might", but a lot of plugins theme use $deps as an argument of enqueue, and I think this would could trouble, I'm not 100% sure but it's still a somewhat wonky solution. Also the Wp admin will soon require local loading. – Wyck Jan 8 '13 at 20:41
  • Gotcha. Also just a quick note for other readers on why my fallback uses get_stylesheet_directory_uri() in the href instead of the WordPress copy in /wp-includes/js/jquery/jquery.js... I typically use the latest version of jQuery at the time of my development and most of the time the native version in WP is slightly behind. Also, I usually install the core under a subfolder to avoid some common bot scanners from attempting automated vulnerabilities. – Jared Cobb Jan 8 '13 at 21:17
  • The problem with this, which is why the admin is soon removing the possibility, is that the latest is not future proof, what is new now is outdated very much in a few years, even though WP is typically only a couple months behind, at least you can be assured they update it. – Wyck Jan 8 '13 at 22:55
  • Oh, I understand what you mean now. Yes, I agree, in the admin section we shouldn't deregister/register/enqueue external jQuery. In fact, my pattern is to wrap that in if (!is_admin()) {//do it here}. I'm thinking about when a theme is assuming a certain version of jQuery, in addition to the benefits of a CDN, but "upgrade proof" in terms of the core being updated and not breaking the admin section. – Jared Cobb Jan 8 '13 at 23:21

As far as I can tell there is no fall back within their functions.php, what that functions.php is doing is telling JQUERY not to be loaded locally and load it via the CDN ensuring that no plugins can HOOK it in for a 2nd time.

If your looking for similar code but with a fall back here you go:

if( !is_admin()){ // Disabled for Admin Area to Avoid Conflicts
$url = 'http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'; // the URL to check against
$test_url = @fopen($url,'r'); // Requires FOPEN
if($test_url !== false) { // Tests to see if URL Exists
function load_external_jQuery() { // Loads the remote file
wp_deregister_script( 'jquery' ); // deregisters the default WordPress jQuery
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js'); // register the external file
wp_enqueue_script('jquery'); // enqueue the remote file
add_action('wp_enqueue_scripts', 'load_external_jQuery'); // initiate the function
} else {
function load_local_jQuery() {
wp_deregister_script('jquery'); // deregisters the default WordPress jQuery
wp_register_script('jquery', get_bloginfo('template_url').'/js/jquery-1.7.1.min.js', __FILE__, false, '1.6.2', true); // register the local file
wp_enqueue_script('jquery'); // enqueue the local file
add_action('wp_enqueue_scripts', 'load_local_jQuery'); // initiate the function
| improve this answer | |
  • A better example would be to test if jQuery is loaded but wp_enqueue_scripts does not support this. – Wyck Jan 8 '13 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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