I’m trying to enqueue jQuery from Google’s CDN and have it called in the footer rather than the header of my theme.
Here’s my code:
wp_deregister_script('jquery');
wp_enqueue_script('jquery', "http" . ($_SERVER['SERVER_PORT'] == 443 ? "s" : "") . "://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js", false, '1.10.2', true);
I found a couple of potential solutions that don’t work for me, they are:
1) Adding the following to my functions.php:
function ds_enqueue_jquery_in_footer( &$scripts ) {
if ( ! is_admin() )
$scripts->add_data( 'jquery', 'group', 1 );
}
add_action( 'wp_default_scripts', 'ds_enqueue_jquery_in_footer' );
2) Calling wp_enqueue_scripts like so (as I’m doing above really):
wp_enqueue_script('jquery','/wp-includes/js/jquery/jquery.js','','',true);
No matter what I’ve tried, jQuery is called in the header. Any suggestions?
The right hook
The
wp_default_scripts
-hook only runs in the admin as it’s called bywp_default_scripts()
on~/wp-admin/load-scripts.php
where it’s hooked at the end of the file.So to move jQuery in public to the footer, you have to use a different hook:
wp_enqueue_scripts
, which only runs in the public. No admin check needed.I’m using
PHP_INT_MAX
, the maximum nr your system/server/OS is capable of. It makes very sure that your action triggers last to ensure that all other hooks have run previously. Still, nothing is 100% secure when it comes to priorities, but you got a very fair chance that it will work out.Queueing the script
About your use of the
$_SERVER
superglobal: You should stay back from using that. Command line interfaces (short: CLI – like Git/GNU Bash, Shell, etc.) won’t be able to retrieve data from there. That means that all automated test environments like PHPUnit or SimpleTest will fail as well as all cronjobs or runwhen jobs won’t be able to get any data from it.The nice thing is, that schemeless, relative URls work out in all major browsers across all major versions. That means that
//code.jquery.com/jquery-latest.min.js
will always give you the latest version.The right version
If you stick with the “official”
latest
version, WP might choke on it. The reason is simple: Core doesn’t constantly use the latest version. Now we need to ensure that we’re always using the version that WordPress currently uses. To achieve that, we’re going to ask WP which version the current one is. That means that our script will always stay in line and up to date with core: