By default, WordPress loads the version of jQuery that comes with the package. But there is an alternative way of doing it and that’s to use the AJAX Libraries API at Google Code – use their bandwidth, why not…

A few lines added to your functions.php in the theme you’re building and you’re ready to go.

wp_register_script() – the useful point is that you can use this function to access scripts hosted elsewhere…

Just add this code to your functions.php file:

add_action('template_redirect', 'js_head_load');

function js_head_load(){

if(is_admin()) return;

wp_deregister_script('jquery');
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js');
wp_enqueue_script('jquery');
// and then any other scripts to register and queue...
}

Notice the first line of the function ensures that the jQuery isn’t loaded on WP admin pages - if a script isn’t needed, don’t load it on the page – and in this case jQuery in noConflict mode can cause the admin rich text editor and the widget drag and drop interface to go awry..

The advantages:-
You’ll be able to update the version your site is using quickly and easily, probably a good thing.

Google Code tends to have a policy of only including versions demonstrated to be stable, jQuery 1.2.4 and 1.2.5 didn’t make the grade

The user may already have it cached in their browser via some previously visited site instead of downloading from a location on your site (and if enough sites do it, the chances are that much greater that they will have a copy in the cache).

Not just jQuery – check out jQuery UI
http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js
And MooTools, which seems seriously under-used in conjunction with WordPress
http://ajax.googleapis.com/ajax/libs/mootools/1.2.4/mootools-yui-compressed.js

Always grab the minified version.

And lastly, one disadvantage:- googleapis.com does go down very occasionally – but then again a site ought to function, more or less, without javaScript.

You’ve been hacking around in WordPress and you get…

Fatal Error – Cannot modify header information – headers already sent …

Why? Very simply, because the script has output something (… ie. printed it to your browser) before trying to execute a  PHP header(“…”) statement – which just isn’t allowed with PHP. Often, it’s a header(“Location: …”) command.

So the output might be an echo or a print you’ve just added in the wrong place – but much more likely it’s a blank space or line(s) outside the opening <?php or closing ?>  in a file.

Have a look at the error message to find which file has produced the warning and edit out the whitespace – remember, check top and bottom.

And always use a PHP/HTML text editor for this – or anything lo-tech… the big heavy word processing programs, Word, Open Office often insert hidden characters in the file. 

Since the arrival of WordPress 2.7, the true framework is based on the concept of parent/child WordPress themes.

A child theme is dependent on its parent – here, the framework – for its template files and functions, it’s not going work without it – ‘parasite’ might be a better name.

When you install a WordPress framework theme, it doesn’t look very impressive to start with – black and white – but that’s not the point. The basic idea is to cover all the fundamentals in the parent framework, the stuff every good theme needs, and keep separate the fancy styling, add-ons etc. in the child theme.

The art of a good framework is how it lets in the customization. Much like PHP frameworks, used wisely, they allow flexibility and concise code, quickly applied – used unwisely, they rapidly become a big old mess with far too many moving parts…

Any good WordPress theme developer will have ended up with a core code that does the job the way he or she thinks best – and this is the origin of a framework. Frankly, if you are are more programming-orientated as a theme designer than design-orientated, they may not be for you. Whether you stick with your code, or dip into your first framework child theme, up to you… but here are the current market leaders, as it were, in no particularly significant order.

Thematic
Produced by Ian Stewart, the prime mover in getting parent-child themes off the ground, Thematic has grids, CSS frameworks, and 13 different widget-ready areas. There’s a growing selection of child themes, free and premium, and support forums.

ThemeHybrid
Again, all the usual goodies, ThemeHybrid also comes with a good selection of child themes built up. For enhanced support in developing and customizing your own theme, ThemeHybrid has a paid club membership option (currently US$25).

Buffet
Buffet has a variety of jQuery features – Superfish menus, SuperSleight for png transparency in IE6, jBreadcrumb. It also offers 2 CSS frameworks – 960gs and the Blueprint CSS frameworks – and support for microformats, XOXO, hAtom, hCard…

Sandbox
Sandbox is probably the original – been around for years – a minimalist Wordpress Theme, designed for developers to build on and produce workable themes simply using CSS. But it’s fully widget-ready, XHTML valid and released under the GPL.

OnePress
The unique proposition for OnePress is its integration with phpBB, with a unified login and forum messages displayed on the blog – if you’re a jobbing site-builder this is certainly something that comes up as a very common client requirement.

Conclusion

There are other frameworks – many other frameworks – in different states of development. This is a hot topic in WordPress theme design and I’m sure the situation will continue to evolve – much like the arrival of javascript libraries, there’ll be a fair amount of competition before the winner(s) emerge.

Just at the moment the best font replacement technique around is cufón – so how to get this technique into your WordPress theme design?

You’ll need 3 javascript files – best to put them in the theme directory under /scripts

1. The Cufon javascript
2. The individual font javascript – downloaded from cufon – or use their excellent generator http://cufon.shoqolate.com/generate/ (not all fonts as .ttf will do the trick, there’s issues of licensing in terms of web embedding)
3. A custom script, very simple, just to activate.

The plan is to get the scripts loading in the WP header, and the best action hook for this is template_redirect – so, in functions.php

add_action('template_redirect', 'them_js_head_load');

function them_js_head_load(){

define(TH_TEMPLATE_URL, get_bloginfo('template_url'));

wp_register_script('cufon', TH_TEMPLATE_URL . '/scripts/cufon-yui.js', array('jquery'), '1.0');
wp_register_script('my_font', TH_TEMPLATE_URL . '/scripts/myfont.font.js', array('jquery'), '1.0');
wp_enqueue_script('fontsactivate', TH_TEMPLATE_URL . '/scripts/fontsactivate.js', array('jquery', 'cufon', 'them_font'), '1.0');
}

fontsactivate.js is as simple as you want to make it – just this, for example, will replace all post h2 headings on the page

Cufon.replace('.post h2');

Don’t imagine it’s a great idea to replace all the text on a page with a custom font, that’ll make the server chug a bit – stick with headings…

You’re producing a WordPress theme, or plugin, that is related to Twitter and for obvious reasons you want to include url-shortening functionality… How’s it, generally, done?

Just the briefest snippet of PHP, this example for is.gd:-

	function shorten_url($url)	{
		$request = 'http://is.gd/api.php?longurl=' . $url;
		return @file_get_contents($request);
	}

You might want to do a bit of error-catching on that. We’ve used file_get_contents() on the basis that we write themes and plugins that work on PHP5 – the ‘official’ WordPress way is probably still to use the bundled version of Snoopy. Or there’s always cURL – unless there isn’t on your server…

Any decent url-shortening service will have its own RESTful API location to do this – hunt in their Developer Tools

http://tinyurl.com/api-create.php?url={long_url}

et al… though some require login/password parameters to be passed, and some definitely require urlencoded parameters

But…. your own name

Don’t forget, in the particular case, if you’re customising your own WordPress installation, the possibility of using $_GET urls -these may well be short enough (if your domain name is short enough… obviously….) . Using your own domain name has 2 advantages, 1 significant

1. If third parties quote the link directly on their web pages it’s your site getting the link value.
2. Still works if the url-shortening site happens to die before your blog does…

And even if you have permalinks active, urls will redirect….

http://themocracy.com/?p=188 will redirect you to the pretty permalink version – job done.

Publicity, relationship-building, just plain keeping in touch – Twitter offers it all and the art is to integrate your tweeting into your blogging, if that doesn’t sound too salacious. Here’s a few scattered suggestions on the subject.

First up, to begin at the beginning, reply to @’s – I know it’s absolutely bleedin’ obvious, but if you’re going to use Twitter at all, then it does make sense to keep an eye on people taking the trouble to contact you – if the @message isn’t total spam, of course. And probably a good idea nowadays never to let a tweet out on the world without one #hashtag.

Display your twitterstream on the blog – there’s WordPress plugins for this – a lot of plugins, in all shapes, sizes and functionalities, such that the jury is still out on who’s the market leader. At the moment, the advice has to be download two or three, try them out and find the one that suits you…

Twitter Tools has a fair few features. Personally, I haven’t had much luck with this one – it seems to give up after a while and only start again when re-installed, and I haven’t got round to digging around the code to see if it’s a localised problem or intrinsic to the plugin. There’s also the issue of deleting manually, ie directly at the database level, any deleted tweets.

Twitter itself supplies javascript snippets to produce a badge of tweet lists – just paste it on your page somewhere, somehow – in practice, not recommended simply because the request takes a while to come back from Twitter’s overburdened servers and your page will likely hang at times. Tho’ fair enough, things seem to be improving a lot in that direction recently – and I wouldn’t like the job myself of keeping Twitter up and running at that rate of growth.

Wider than just Twitter, there’s also the Lifestream WordPress plugin. Lots of features included, which do take a little bit of figuring out but you can merge twitter feeds, extra RSS and then any of the other social entities, Digg, FriendFeed etc etc.

One thing – if you’re going through a twitter-lazy period and all that appears in the sidebar is a set of auto-generated new blog posts 181 days ago, 193 days ago – that doesn’t look so good. A successful blog does actually require some work.

Among other Twitter-related WordPress plugins: -

TwitterLink Comments is a WordPress plugin which adds an input field to a post’s comment form for commenters to include their Twitter username – a follow me link is shown against that commenter’s profile – caution, a definite invitation for spam…

The slightly bilious TweetMeme retweet button does what it says – a link allowing visitors to your blog to quickly retweet the post. For the competitive, there’s also a display of number of retweets of that url across Twitter.

Do consider having a custom Twitter landing page on your blog. A relatively old dodge, but useful…

Instead of using your blog front page as your profile url without even thinking about it – take the trouble to produce a specialised landing page – a digest of who you are, what’s going on, all in a couple of hundred words. The logic behind this is that people using Twitter may well have different priorities and interests than your average blog-reader who’s arrived via search engine.

This profile url appears on your Twitter web page (and with the growth in non-browser-based twitter tools that gets viewed less and less) but also in various other places, directories etc. so it’s worth considering.

If you can give them what they want, grab their attention better, that’s one more connection made. Attention spans (of the young) are not very long nowadays…

And do watch out for shortened urls – don’t display or retweet anything you haven’t checked, and that definitely includes anything that arrives in a comment.

To refine a previous post on WordPress and jQuery and the use of the wp_enqueue_script function, its paths and dependencies.

As a barebones example, this is how we do it when we we’re enqueueing – if that’s a word – the jQuery Cycle plugin, so that we can make a slideshow on the page.

The important point is probably in the dependencies – firstly, the Cycle plugin depends on jQuery, so has to be loaded after – secondly, our custom script to run the whole process on depends on the jQuery Cycle plugin and therefore also on jQuery and is the last to load.

The custom script we’ve written is in them_directory/scripts/them.cycle.js – something very simple, like this:-

jQuery(document).ready(function($) {

$('#images').cycle({
//some parameters
 });
});

(Don’t forget, the dollar $ object isn’t defined in WordPress jQuery (historical reasons) – hence the form of the first line)

This is client-display side javascript, as opposed to admin-side, (which tends to follow slightly different rules in the WordPress setup) and in this case, the action hook ‘template_redirect’ is usually the time to do it.

To enqueue the jQuery library itself is simple – it’s already registered by default in WordPress, no need to specify other than the default path and version.

So in functions.php

add_action('template_redirect', 'them_js_head_load');

function them_js_head_load(){

	//register the plugin
	wp_enqueue_script('jquery-cycle', THEM_TEMPLATEURL.'/scripts/jquery.cycle.lite.min.js', array('jquery'), '1.0');
	//register the custom script
	wp_enqueue_script('them-cycle', THEM_TEMPLATEURL.'/scripts/them.cycle.js', array('jquery', 'jquery-cycle'), '1.0');

}

Note for convenience and efficiency, we’ve previously defined

define(THEM_TEMPLATEURL, get_bloginfo('template_directory'));

And what you end up with in the page source should be something like this – javascripts loaded in the right place in the page head, up and running

<script type=’text/javascript’ src=’http://localhost/test/wp-content/themes/this-theme/scripts/jquery.cycle.lite.min.js?ver=1.0′></script>

<script type=’text/javascript’ src=’http://localhost/test/wp-content/themes/this-theme/scripts/them.cycle.js?ver=1.0′></script>

If you’re going to be a WordPress plugin author, pretty soon you’ll have to get into the area of database operations, manipulating existing data or even adding your own tables – assuming you have a basic knowledge of PHP/MySQL, here’s how the fundamentals work

WordPress uses the ezSQL database wrapper – not a high-tech solution (WordPress isn’t high-tech, probably one of its strengths…), but simple, stable and useful. It wouldn’t be a bad idea here to grab a copy, read the FAQ and play around with the basic functions to understand the PHP syntax involved.

(I think) it’s safe to say that anything you can do with ezSQL, you can replicate inside the WordPress environment with $wpdb – but don’t quote me on that one….

The WordPress Database Object – $wpdb

$wpdb is the database object created by an instance of the ezSQL class – this part is already done for you.

Rule 1 for beginners – scope – remember to declare the object in any function in which you’re going to make use of $wpdb

<?php
	function my_wordpress_function(){
	global $wpdb;
		// etc....
	}
?>

Let’s jump in and try something – how to get the names and email addresses of the commenters on your blog:-

<?php
$commentEmails = $wpdb->get_results("SELECT comment_author, comment_author_email
FROM $wpdb->comments ORDER BY comment_date DESC LIMIT 20");
?>

You’ve got the raw data, as an object, you can dump it – print_r($commentEmails) – write it to a csv file and download it, whatever you need.

If you want the results as an associative array – maybe for further ordering, or some such – the method is to add ARRAY_A – see the ezSQL documentation.

<?php
$commentEmails = $wpdb->get_results("SELECT comment_author, comment_author_email
FROM $wpdb->comments ORDER BY comment_date DESC LIMIT 20", ARRAY_A);
?>

Most of this is straightforward MySQL syntax – the one significant point involves the specifying of the table, here, comments – there’s a database prefix involved, which will vary from one installation to another.

The current WordPress method is to use an associated variable of the database object – $wpdb->comments, and you’ll be selecting from the correct table. Again, this has already been declared for you. Similarly, $wpdb->posts will get you the posts table to work with, $wpdb->users, $wpdb->options etc…

It’s a better way than using $table_prefix from wp-config.php and adding this into the sql string. The slight complication comes when you start adding and using your own custom tables, not already a part of the $wpdb object – and that’s for later…

Meanwhile, try a few SELECTs and then maybe a few UPDATEs/INSERTs to see what’s going on.

If you’re a theme developer, you’ll (perhaps) be looking at keeping up with the latest in javascript/AJAX and incorporating a few tweaks into your brand new theme – in some ways, it’s been made very easy for you (and in one or two ways it’s just a little tricky…)

So, assuming you have a basic knowledge of PHP, theme design and javascript, here’s how it works:-

Loading up jQuery

WordPress arrives with jQuery already bundled, so this bit’s easy enough. But we need to get it loaded onto the page, which doesn’t happen automatically…

The plan here would be to get some nice tabbed divisions going, maybe in the sidebar, courtesy of jQuery.

<?php
add_action('template_redirect', 'them_js_head_load');

function them_js_head_load(){

 // we don't need this on admin pages, so...
	if(is_admin()) return;

      wp_enqueue_script('tabber', get_bloginfo('template_directory') . '/scripts/tabs.js', array('jquery', 'jquery-ui-core', 'jquery-ui-tabs'), '1.0');
}
 ?>

In this code, we’ve enqueued a custom script tabs.js, that’s going to initiate the whole process – and we’ve also declared its dependencies – jquery, jquery-ui-core, jquery-ui-tabs, the user interface sublibraries, also bundled into WordPress as standard.

These are already registered, so only the handle is required, here: ‘jquery-ui-tabs’, etc.

The full list of bundled libraries is at: WordPress wp_enqueue_script.

Vital! – The snippets of jQuery code you’ll find while out and about on the net make extensive use of the shortcut $ to express the jQuery global object. This isn’t going to work in WordPress, so at all times we use jQuery(document).ready(function($) – and then it will work… Once inside the function, we can use $ as a shortcut.

The reason for this slight complication is that Prototype and Scriptaculous libraries arrived first into WordPress and have got to hold on to using the $ shortcut. And don’t be tempted to dabble with jQuery.noConflict() here – you won’t get good results.

And from here, since you know what you want to put in your theme in terms of flashy javascript/AJAX add-ons, I’ll leave you to get on with thieving some snippets and getting them up and running….

* Update – some of this information is superseded by changes in the way WordPress handles the loading of javascript – there’s a follow-up here – More about WordPress and jQuery