WordPress has really made some huge leaps forward in recent versions making it a truly powerful content management system. Not coincidentally, WordPress custom theme design and development has really become a passion of mine… one of the fruits of which is a tried and true collection of customizations and tweaks I always start off with when creating a new custom theme for a client. In this post I’ll share some of them and explain a little about why I think they’re important. These are of course all intended for the backbone of any WordPress theme, the functions.php file. I often see these kinds of function tweaks referred to as “hacks” which I find unfair… they really aren’t hacks as the WordPress architecture is designed to allow these kinds of customizations!

Under The Hood Performance and Javascript

These snippets all pertain to streamlining the end user page loading experience. Obviously the faster we get our pages to load the better, so we want to get the important stuff (content) out as soon as possible letting embellishments come in after. To that end, I regularly apply these three concepts:

“Smart” Script Inclusion

JQuery is a popular and powerful javascript library that gives us the ability to easily add visual embellishments such as animations, event handling for interactivity, DOM manipulation, and more. Once upon a time the drill was to upload a copy of the library to your server for inclusion in your pages, and WordPress includes a copy of the JQuery library in it’s core install to this end. What we do here in this tweak is to include the library from a public source instead of our own server. Here’s what it looks like:

[codesyntax lang=”php”]

// cdn jquery inclusion
if (!is_admin()) {
	wp_deregister_script('jquery');
	wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"), false);
	wp_enqueue_script('jquery');
}

[/codesyntax]

This allows us to cut down on http requests to our server and lets the browser grab the script in bandwidth saving parallel. In this example we’re getting it from the Google Libraries API content distribution network (CDN), an amazing initiative in it’s own right!

 Moving Scripts To The Page Footer

Next thing we want to do is to make sure we are loading our javascripts AFTER all of the content itself is loaded. The end user’s browser will wait to load an entire script before moving on so loading these before content in most cases should be avoided. By default WordPress includes its built in scripts in the header, as do most plug-ins, so this snippet allows us decide we want them at the foot of the page loading hierarchy.

[codesyntax lang=”php”]

// Move scripts to footer for faster loading
remove_action('wp_head', 'wp_print_scripts');
remove_action('wp_head', 'wp_print_head_scripts', 9);
remove_action('wp_head', 'wp_enqueue_scripts', 1);

add_action('wp_footer', 'wp_print_scripts', 5);
add_action('wp_footer', 'wp_enqueue_scripts', 5);
add_action('wp_footer', 'wp_print_head_scripts', 5);

[/codesyntax]

Note that some plug-ins will still force their javascripts into the head of the document even with this code, and there are times when it’s necessary for a script to load before the body. For all the rest, down to the bottom you go!

Load Scripts Only On Required Pages

Many scripts included by WordPress or plug-ins are not needed on every page of a site, so loading them on every page wouldn’t make sense. To avoid slowing things down needlessly, we set up some PHP conditional checks. For every page that doesn’t need a particular script we stop it from loading. In this example I’m removing the comments scripts included with WordPress from pages that don’t have comments, as well as the scripts for two common plug-ins I frequently include with a custom WordPress install: Contact Form 7 and WP JQuery Lightbox.

[codesyntax lang=”php”]

// Filter scripts from pages where not needed
add_action( 'wp_print_scripts', 'gawd_deregister_javascript', 100 );
function gawd_deregister_javascript() {
  if ( !is_page('Contact') ) {
    wp_deregister_script( 'contact-form-7' );
  }
  if ( !is_page('Portfolio') ) {
	wp_deregister_script( 'wp-jquery-lightbox');
  }
  if ( !is_single() ) {
	wp_deregister_script( 'comment-reply');
  }
}

[/codesyntax]

So, for every page that’s not named “Contact”, the CF7 script gets skipped… Not Portfolio? No lightbox script! And in this case I have comments enabled only on single post pages, so they’re the only ones that get the WordPress comments script. The thing to bear in mind is that the wp_deregister_script() function needs the term used by the plug-in to initially register itself. The term for Contact Form 7 happens to be “contact-form-7”. Finding the term for each plug-in means hunting through the php code of the plug-in itself looking for the wp_enqueue_script() function. Hey, it’s good practice for your code reading skills!

Wrapping Up

So there’s a taste of the kinds of simple but effective tweaks to the WordPress codebase that make up an important part of any developing custom theme. I focused on smart management of javascripts in this post and coming up next in Part 2 I’ll look at customizations related to the client and their brand. That’s when we really start to put the “custom” in customization… stay tuned!