Let’s lay some groundwork:

1. This example would go in your functions.php file.
2. This example assumes your theme is a parent theme.

In this example, I’m registering four scripts, and enqueuing two. I’ll explain it afterward.

<?php
/*
 * WordPress Sample function and action
 * for loading scripts in themes
 */
 
// Let's hook in our function with the javascript files with the wp_enqueue_scripts hook 

add_action( 'wp_enqueue_scripts', 'wpcandy_load_javascript_files' );

// Register some javascript files, because we love javascript files. Enqueue a couple as well 

function wpcandy_load_javascript_files() {

  wp_register_script( 'info-caroufredsel', get_template_directory_uri() . '/js/jquery.carouFredSel-5.5.0-packed.js', array('jquery'), '5.5.0', true );
  wp_register_script( 'info-carousel-instance', get_template_directory_uri() . '/js/info-carousel-instance.js', array('info-caroufredsel'), '1.0', true );

  wp_register_script( 'jquery.flexslider', get_template_directory_uri().'/js/jquery.flexslider-min.js', array('jquery'), '1.7', true );
  wp_register_script( 'home-page-main-flex-slider', get_template_directory_uri().'/js/home-page-main-flex-slider.js', array('jquery.flexslider'), '1.0', true );

  wp_enqueue_script( 'info-carousel-instance' );
  
  if ( is_front_page() ) {
    wp_enqueue_script('home-page-main-flex-slider');
  }

}
?>

Now let’s break it down

We are using an action hook called wp_enqueue_scripts(). It’s your best friend. This hook ensures that your function is registering and enqueuing scripts in the right place and only on the front end.

We’ve prefixed our function. Because, you need to prefix all the things. Use a prefix that makes sense, but isn’t “wp” or something else that could be used by core or other plugins. Your full initials, sitename, etc. are good possibilities.

As a sidenote, I recommend adding the action in your own theme setup function.

We’re registering the scripts with wp_register_script(). Read that page. Get in the practice of providing every parameter of the function every single time you register a script.

1. Handle – A name this script will go by. This is how you will enqueue it the short way, or if your user has a child theme and doesn’t want your script, they can dequeue it with this handle.
2. Source – The path to the file. I used get_template_directory_uri(), which is a WordPress function that finds the parent theme directory. Never, ever, hard code the path with /wp-content or anything else. Use this function. It works. It’s great. If you are registering your script in a child theme, use get_stylesheet_directory_uri() instead. It’s the same thing, for child themes.
3. Dependencies – These are the scripts your script depends on. You may recognize my scripts I’m loading. They’re two different slider scripts. They both depend on jQuery. You can pass multiple dependencies in this array, if necessary. For the script called “info-carousel-instance”, it relies on the “info-caroufredsel” script. Therefore when I enqueue “info-carousel-instance”, WordPress will know it needs to enqueue “info-caroufredsel” as well, if it hasn’t been enqueued already.
4. Version – The version of the script you are loading. If you update your script, you can bump the version, and when you change the version here, WordPress will be sure to load the new one, and reset any caching that’s been used on the previous version of your script.
5. Load in footer – If you set this to true, your script will be loaded in the footer, and therefore after much of the rest of the page has loaded. I always do this for things like sliders, because that way my slider script won’t prevent more important things on my page from loading. Just think about what you’re loading when you consider whether or not to do this.

wp_enqueue_script()

wp_enqueue_script() will enqueue scripts.

Definition: to place something into a queue; to add an element to the tail of a queue (line).

This function simply puts the script it is enqueueing in line to be loaded onto the page. WordPress is also smart enough to know if a script you are trying to enqueue has already “been through the line”, if you will, and won’t load the same scripts more than once. Whenever you see a website loading jQuery mutliple times, you now know why – they aren’t enqueueing, or at least not properly.

I’m enqueueing two of my four scripts. My carousel instance and the home page flex slider instance. The carousel will be loaded on every page, and the flex slider only on the homepage, as that’s the only place it’s used. If you don’t need a script on every page, don’t load it on every page. You can use conditional tags inside the wpcandy_load_javascript_files() function, around the instances of wp_enqueue_script() that are to be loaded conditionally. Automattic’s _S theme also has good examples of loading scripts with conditionals (like a script for comments – a common one to load this way).

wp_enqueue_script() takes the same arguments as wp_register_script(), but if you register your scripts first, you can just call them by the handle in wp_enqueue_script, as my example above shows.

As of WordPress 3.3, you can even enqueue scripts in specific page templates. It will load the script in the footer automatically! For instance, I could have enqueued the “home-page-main-flex-slider” script directly in the template part with the slider code.

Register vs. Enqueue

In our function, we’re registering four scripts, and enqueing two. Registering a script makes it available for use. Enqueuing actually pulls the script to the theme. You can register without enqueuing. But to load the script on the page, you need to enqueue. If you register the script as I show, you can then enqueue it by its handle alone. If you don’t register it ahead of time, you’ll need to provide the full parameters in the enqueue function.

The reason I register all of my scripts in this function is simple: it helps me keep track. Sure, I could just enqueue them all in this function with conditionals, but sometimes conditionals get confusing, and I like to take advantage of the ability to enqueue in templates, because it’s simple. I could also skip the register function for the scripts I enqueue right away, but again, I do it for organization. I register them there, together, so that I know what I’ve got and I know what I’m loading on every page versus in specific places. I also tend to make notes in comments by the register function to note where I’m enqueuing, if not immediately.

Notes

To load scripts in plugins, plugins_url() will replace get_template_directory_uri() for the path, and your function would be in your plugin file instead of functions.php. To load them in the admin, you’d use the admin_enqueue_scripts() function instead of wp_enqueue_scripts().

But this tutorial is just to show you how to load scripts in themes – meant for the frontend. Please start doing this. If you aren’t, you are doing yourself and your customers (whether buyers of themes or clients) a disservice and certainly causing future headaches.

Also, you’ll see I used the version of jQuery included in WordPress. So should you. You’re making a theme. Use the jQuery included with WordPress. It will always be up to date and compatible with core. It will always work. I’ve seen Otto argue with enough people about this (including me). He’s right. If you think Google’s jQuery is better, use this plugin, or recommend it to your users. For themes you release, just use the WordPress bundled version.

I hope this has helped clear things up for some of you. I’m not the first person to write about it. But maybe I helped it click for some. And as Carl Hancock said (he deals with conflicts daily), “it needs to be drilled into them [me, you, all of us]. So the more articles the better.” Oh, and if I screwed something up, or you have something to add, please let me know.

The SEO overlords say “Thou shalt provide links on your 404 page”, or something to that effect. Consider this quick tip simply a word of caution for you power users.

Typically a WordPress 404 page will not be cached by your performance plugin of choice or even Varnish in most cases. And a typical 404 page template may look something like:

• wp_list_pages( 'title_li=' );
• wp_list_categories( 'sort_column=name&title_li=' );
• wp_list_authors( 'exclude_admin=0&optioncount=1' );
• wp_get_archives( 'type=monthly' );
• wp_get_archives( 'type=postbypost );

All fair and good, right? 95% no harm no foul. Except in possibly these two following circumstances:

1. Your site has 500, 1000, or even 10,000 posts/authors/categories/tags etc.
2. Your permalinks get botched by a plugin, and everything but your homepage is 404′ing. (We see this at Page.ly from time to time; some plugins just love to rewrite permalinks — poorly.)

Here is the cascading effect of multiple 404 pages on a big blog under a large amount of traffic:

• the web server opens a connection,
• pings Mysql to make these queries (grabs 242 pages, 634 categories, 25 authors, 6325 posts…),
• holds open the connection while Mysql burns,
• more connections to the web server stack up, waiting,
• New Zealand falls into the ocean.

But wait, there must be an easy fix you say! Indeed there is: use the limit, depth, number, and other arguments that will typically add a LIMIT or more narrowly focused SELECT to the Mysql queries. This will help a 404 page render much faster.

So we would modify our list above to look like this:

• wp_list_pages( 'title_li=&depth=1' );
• wp_list_categories( 'sort_column=name&title_li=&depth=1&number=10' );
• wp_list_authors( 'exclude_admin=0&optioncount=1&number=10' );
• wp_get_archives( 'type=monthly&limit=10' );
• wp_get_archives( 'type=postbypost&limit=10 );

The W3 Total Cache plugin also has a setting to handle 404′s, basically letting the web server serve up the default (and less attractive) 404 page, with no pain of loading the WordPress stack.

And of course, always try to identify your 404′s thru your access logs and 301 redirect them to a working page.

Happy blogging.

Additional resources:

• http://codex.wordpress.org/Function_Reference/wp_list_pages
• http://codex.wordpress.org/Function_Reference/wp_list_categories
• http://codex.wordpress.org/Function_Reference/wp_list_authors
• http://codex.wordpress.org/Function_Reference/wp_get_archives

One thing I spend some amount of time thinking about each week is managing my multi-author blog at WPCandy. There are only a handful of authors that have joined WPCandy in the last year, but we’ve still spent a good deal of time improving our workflow as a multi-author blog. I’ve even picked up a few (what I would call) tips in the process.

If you find yourself in a similar position, hopefully some of these tips will help you along. If you run a blog with a number of authors, be sure to jump down into the comments and share your experiences too.

Establish a team blog

If you want your team to feel like, well, a team, they need a place to come together and chat about what they’re working on. One hundred percent of my team of contributors is distributed all over the planet, so if we didn’t have a team blog of some sort we all wouldn’t have as many chances to talk.

I’ve opted to use the P2 theme from Automattic, because like many others I think it fits nicely between the traditional blog and a chat room. I’d recommend setting up a private P2 instance at a sub domain of your site, like at team.yoursite.com, and making sure that everyone on your team is always able to use it.

In addition to P2, I’ve found that using Subscribe to Comments and Subscribe2 cover our bases when it comes to post notifications. This is also just a matter of preference, but I like to keep a list of useful links in the sidebar of the P2 blog along with a list of all the authors on the blog.

Of course you don’t have to use P2. The key is to have a location where your team can easily chat about what’s going on. Do whatever works best for your particular group.

Establish proper author/editor capabilities

This one will highly depend on your needs, but in my case I’m kind of a (what’s the word?) control freak. Because of this I still personally edit every word that gets published on WPCandy, so authors on WPCandy don’t have the ability to publish but can only submit posts for review.

There are a couple of ways to do it, but I opt to manage capabilities using Members by Justin Tadlock. Really I haven’t done much more than remove the publish capability from authors.

Just as important as the technical side of things is making sure that roles and abilities are known by your editorial team. Make sure everyone knows what’s expected of them and what they can do on their own, either using a team blog (see above) or help text (see below).

Use Edit Flow

I tried the Edit Flow plugin around a year ago, and just didn’t think it was quite there yet. I’m happy to say that wherever the aforementioned there is, Edit Flow is squarely in the middle of that location. The developers, led by Automattician Daniel Bachhuber, released version 0.7 this week and it brought some features that really got me excited to use it—features like a drag and drop editorial calendar:

In short, Edit Flow is a plugin that gives your WordPress Dashboard a newspaper-like editorial workflow. Along with the editorial calendar I mentioned above, Edit Flow gives more granular control over post statuses (like Pitch, Assigned, and Changes Needed in addition to Draft and Pending Review), enables author-only editorial discussion of posts as they come together, and  allows authors and editors to be notified when changes are made to posts.

Before Edit Flow the WPCandy team was using a ticketing system—on a sub blog using WooThemes’ FaultPress, actually—but the changeover was worthwhile. The old system, while it worked, also required a layer of translation between the ticketing system and WPCandy itself. When a post was started in one place, a ticket in another place had to be updated. Notes for the post (sources, contacts, etc.) had to be pulled from the ticket and used to write the post. And when a post was published, the ticket elsewhere had to be updated again.

Kind of a mess, right?

There’s nothing wrong with FaultPress, of course. Edit Flow is just perfect for multi-author blogs because it streamlined this process so that it all happens in one place.

Author checklist for post submissions

This is one of those tips that is useful not only for your site’s authors, but likely for yourself (at least it was for me). As you edit and publish content on your blog, pay attention to the steps you take over and over. If there’s a way to streamline those steps, such as setting a new default category to better represent the majority of your content, then definitely do that. But for other things it’s worth maintaining a checklist.

I’ve resorted to posting the checklist to the team blog or our help section (see below) but I’ve also see options like Blogging Checklist before. I haven’t tried it myself, but it could be something useful if your authors need to run down a few key steps for every post they write.

In general, though, communicate best practices to your authors to make the editing process (and hopefully the writing process, in the long run) as efficient as it can be.

Proper author attribution

If you have other authors on your blog it’s important to give them credit where it’s due. You want them to know they are receiving proper credit for their work, but it’s also important to make sure readers know who they’re reading.

Bylines are the most important thing to get right here. As an author, seeing your name presented prominently next to your work is important. It’s important at such a basic level, really, that it’s weird to mess this one up.

And as a reader, I can’t tell you how disappointed I end up being when I find out a post I’m looking at doesn’t have proper author attribution. I want to know who I’m reading just as much as what I’m reading.

If you wonder exactly how you should pull this one off, a good rule of thumb is to put other author’s names in the same place you’d put your own. In addition you might consider an area, perhaps beneath the post, where more information about the author is given. We have used these on WPCandy for a while and they tend to work pretty well.

One of my favorite social WordPress plugins is WordTwit from BraveNewCode. WordTwit is a handy plugin that will tweet out messages (either automatically or manually generated) when you publish new posts. In a recent update they made it really easy to automatically mention the author’s Twitter name in the tweets, and we’ve started using that here for the bulk of our posts. For a site like ours, where a lot of our community and traffic comes from Twitter, I think it’s important to give credit to post authors there too.

Set up author emails

This isn’t something you can set up within WordPress itself, but believe me when I say it will make your multi-author blog all the more professional. I prefer using Google Apps to run my domain-specific emails, and I highly recommend it, but honestly use whatever you have to and get that done.

Not only will having theirname@yoursite.com give your authors a sense of ownership in the site, but it will make their emails with people for your site all the better.

Share a group RSS subscription

I talked before about the number of RSS feeds I follow to keep up with WordPress company and project blogs. It’s quite a few. One small but helpful way to make the process of tracking new and interesting stories a bit easier is to open it up to the rest of your team and allow them to review potential story ideas too. This one will take a good deal of trust in your authors, but it can really be worth it once you have more than a few feeds/sources that are updating daily.

For the group RSS account I use one of my Google Apps emails set up with a Google Reader account. I have intended to move the various Twitter accounts I follow into one that the whole team can use, but I just haven’t gotten to it yet.

Maintain author help texts

You can establish this copy anywhere you like, really, but I prefer to keep as much within the bounds of the WordPress Dashboard as I can. It keeps things simpler and, to be honest, I just like it better.

So I really like WP Help, a plugin by Mark Jaquith that lets you keep help text for the authors on your blog.

There are other ways to maintain this sort of information, but this one’s my favorite. In our help section we try to keep things like:

• what to do as a new author on the site,
• tips for writing posts,
• how to use our taxonomies properly,
• the types of images we generally like to use,
• WPCandy logos that authors can use, and
• how to modify the parts of the site they can modify.

How about you?

There are undoubtedly more things to consider when running a blog with more than one author. I’ve based these tips only on my own experiences, which aren’t even that expansive. If you’ve run a multi-author blog (using WordPress or even something else) please jump down to the comments and share your experiences and tips.

I always intend to write about how I build things around WPCandy, but when the time comes it doesn’t always happen. I fully intended to write about the creation and development of the Pros section, but then I didn’t. I started working on the discussion board, which in turn I never wrote about either. Around that time work began on The WPCandy Quarterly, which was only just announced the other day. Today, I’m determined to write about the building of the Quarterly micro-site at wpcandy.com/quarterly before moving on to any other projects.

When planning things out, I knew that I wanted to keep a trend going with the Quarterly that I had started with Pros and the forum: keeping everything on this domain, and simply adding new sections to the site. I’ve been avoiding subdomains and brand new sites for some time, really for the sake of simplicity and because I prefer the way it looks within the site. So I set about creating a micro-site just for The WPCandy Quarterly, which I’ll walk you through in this post.

In this post you can expect a smattering of code snippets, a good deal of me explaining my weird website preferences, and of course some bouncing between functions.php files and functionality plugins.

Planning the addition to the site

I knew the Quarterly would need its own landing page, as well as a specific page for each issue. This way discussions around specific issues and articles could easily be linked up, and it would be simple for anyone to jump back through back issues. At the same time, I knew I would need a shopping cart to manage the billing, shipping, and checkout process.

Each issue of the Quarterly would need a description and issue photos, as well as a listing of the authors and (ideally) the articles that they contributed. So I’ll want to be able to not only associate posts on the site with an issue, but eventually discussions on the forum as well.

Just to be clear, then, in this post we’ll be:

1. setting up a new section of the site for the Quarterly and
2. setting up basic shopping cart functionality.

Setting up the Quarterly issue pages

The requirements for this section of the site demand — as you might expect — a custom post type. The PHP I’m using is below:

<?php
// Custom post type creation
function wpcandy_cpt() {

	//Other post types created above

	// Quarterly post type
	register_post_type( 'wpcandy_issue',

		array(

			'labels' => array(

				// There could be more labels here, but I was lazy I suppose.			
				'name' => __( 'Quarterly' ),
				'singular_name' => __( 'Quarterly Issue' ),
				'add_new_item' => __( 'Add New Issue' )

			),

		'exclude_from_search' => true,
		'capability_type' => 'page',
		'has_archive' => true,
		'menu_position' => 20,
		'public' => true,
		'publicly_queryable' => true,
		'rewrite' => array( 'slug' => 'quarterly', 'with_front' => false ),
		'show_ui' => true,
		'supports' => array( 'editor', 'title', 'thumbnail', 'excerpt', 'page-attributes' ),
		'taxonomies' => array( 'post_tag' )

	));

}

// Add action
add_action( 'init', 'wpcandy_cpt' );

This PHP went into my functionality plugin, since of course I’ll want it to stick around when I switch themes.

Notice that I defined an archive for this post type so I can include a special archive template to display them. This is important, since I’ll be using this template to make the Quarterly section of the site entirely unique.

I’m also enabling the post tags taxonomy, for a reason that I’ll explain in a minute.

With the post type in place, and a quick visit to the Permalinks Settings page on the Dashboard to get the URLs working, I could visit wpcandy.com/quarterly and any specific issue at /quarterly/issue-0x. As you might imagine, though, at the time those pages looked just like any other page on WPCandy, which of course wouldn’t do. I created the archive-wpcandy_issue.php and single-wpcandy_issue.php templates, but of course those were still using the same styles and scripts from the rest of the site.

In order to clear the palette, so to speak, I added a few new lines to my functions.php file. In this case I’m dealing with the presentation layer, and not the functionality, so there’s no reason to resort to a functionality plugin.

This is what I set out to do. If viewing a Quarterly archive or single page:

1. remove the core site styles, and any plugin styles that won’t be used,
2. remove the core Javascript, ana again those added by plugins that won’t be used,
3. add back the styles and (and maybe scripts) specific to the Quarterly.

By doing this, I’m creating a sort of theme-within-a-theme. Sort of. I can now use a simple, smaller, and very specific stylesheet just for the Quarterly section, leaving my main site CSS file untouched.

In order to do that, here’s what I used:

<?php
// Just for the Quarterly

add_action( 'wp_print_styles', 'quarterly_styles' );
add_action( 'wp_enqueue_scripts', 'quarterly_scripts' );

function quarterly_styles() {

	if ( is_post_type_archive( 'wpcandy_issue' ) || is_singular( 'wpcandy_issue' ) ) {
		wp_dequeue_style( 'master' );
		wp_enqueue_style( 'quarterly', THEME_CSS_URI . '/quarterly.css', null, '1.0' );
	}

}

function quarterly_scripts() {

	if ( is_post_type_archive( 'wpcandy_issue' ) || is_singular( 'wpcandy_issue' ) ) {
		wp_dequeue_script( 'scripts' );
		wp_dequeue_script( 'live-blogging' );
		wp_dequeue_script( 'jquery-ui-accordion' );
		wp_enqueue_script( 'quarterly', THEME_JS_URI . '/quarterly.js', array('jquery'), '1.0', true );
	}

}

I added this to my theme’s functions file, since it’s specific to the theme I’m currently using.

Now I have a clean slate to work from, which is exactly what I did. I styled the navigation, the issue post type content, and the special section with the list of contributors to a specific issue.

Oh right, the contributors section. Here’s how I did that.

Listing the contributors to an issue

In all likelihood, at some point in the future Quarterly articles will end up on the blog. Not right away, of course, but eventually. So the first thing I did was create draft posts (standard posts, not the issue post type posts) authored by each of the Quarterly contributors. For each of them I also tagged them with a Quarterly issue-specific post tag. I made sure the issue post they belong to also included the same tag.

Then I added the query below to my templates:

<h3>In this issue</h3>

<ul>

<?php $issue_terms = get_the_terms( $post->ID , 'post_tag' );

	if ( $issue_terms != '' ) {

		foreach ( $issue_terms as $issue_term ) {
			$issue_slug = $issue_term->slug;
			$issue_query = new WP_Query( 'post_type=post&showposts=-1&post_status=any&orderby=rand&tag=' . $issue_slug );

		while ( $issue_query->have_posts() ) : $issue_query->the_post(); ?>

		<li class="contributor">

			<div class="avatar">
				<?php echo get_avatar( get_the_author_meta( 'user_email' ), 60 ); ?>
			</div>

			<div class="title">
				<p><?php the_title(); ?></p>
				<p class="author"><span>by</span> <?php the_author(); ?></p>
			</div>

		</li>

		<?php endwhile;
		wp_reset_postdata();
	}
} ?>

</ul>

This I added to the Quarterly-specific loop, which was called into each of my two new template files so I wouldn’t repeat myself.

And that, along with some CSS, created this:

I now have a simple, elegant way to list the contributors with each issue. It will be easy to link up these article titles to their posts, too, since they’re already querying the drafts themselves from WordPress. With a bit of CSS, I now have a method of displaying issue contributors that I can use and reuse.

Setting up the shopping cart functionality

If I were only in need of a simple digital purchase I likely wouldn’t bother with a full shopping cart setup. Paid Pros accounts (which I lovingly call Sweet Pros) are, after all, simply a PayPal subscription created using a Gravity Forms signup form. However the Quarterly is a physical product, which necessitates a more complete shopping cart experience. Having a shopping cart on the site is also helpful, since it makes the process of adding additional physical products to the site in the future a lot simpler.

I toyed around with just about every e-commerce plugin out there before ultimately deciding on WP e-Commerce. To be honest I was thoroughly impressed by each plugin that I tried out, and my final decision was WP e-Commerce primarily because it has been around for so long.

Before now, my only extended experience with the WP e-Commerce plugin was years ago, around 2008 or so; it wasn’t a very pleasant experience at all. I’m happy to say it’s much better now, and the setup was pretty much seamless.

The Quarterly section of the site is separate from the shop for a few reasons. One, I want to have the flexibility of controlling the URLs, layout, and elements within the Quarterly micro-site. If I knew the Quarterly would be the only physical product I’d ever sell in the store, then perhaps I would have relied on that entirely. But I don’t know that, so the shopping cart (or WPCandy Shoppe) is separate from the Quarterly site.

This separation wasn’t a big deal, since simple shortcodes are available with the WP e-Commerce plugin to add specific purchase buttons to any section of your site. I used these within the pages of the Quarterly site to create a nice transition from micro-site to cart and checkout.

At least, I think it’s pretty slick.

Additional thoughts on WordPress and e-commerce

It will certainly be worthwhile to spend more time surveying e-commerce options and reviewing them more fully in the future, but in the meantime I thought I’d offer up a few thoughts. One comment I have that applies to all of the e-commerce plugins I tried out is this: the initial setup process is quite overwhelming. During my toying process I set up the basic Quarterly sales items and process for each plugin on a testing location. Without exception, each plugin presented me with options I never ended up needing, or didn’t even care about. I realize that WPCandy’s shopping cart needs aren’t as complicated as some, but that made me wish for a simplified setup process even more.

It would be great to see these plugins take more of a “decisions over options” approach. When that isn’t possible, stashing less vital options in an advanced section would lessen the initial impact of a screen full of checkboxes and dropdowns.

Easily the most delightful part of the e-commerce setup, for me, was using BraveNewCode’s Piggy plugin to enable purchase notifications to my phone. The setup was simple, it integrates well, and I love being notified of sales. It was an easy $25 to spend, and I would recommend anyone using an e-commerce plugin (it integrates with a number of them) check it out.

Reflecting on the development process

I’m much happier with the development of this addition to the site than any other addition I’ve done. I approached it intelligently (for me at least) and completed the development in an efficient and future-thinking way. I wish that I had developed Pros in as clean a fashion, and will definitely revisit the methods I used when I launch Pros 2.0.

What do you think? Have you used any of these techniques before, or do you have even better ways of pulling this off? Oh, and while I’m asking questions: have you pre-ordered your copy of the Quarterly yet?

I ran across a fun code snippet today by Tammy Hart that automatically creates posts to a WordPress custom post type from your Dribbble RSS feed. The post type is called “shot” and all it requires is for you to change your Dribbble name in the fetch_feed( ) function.

In addition to Tammy’s creation of the Shot post type, I put together a simple archive template that you can use in your theme. I used markup consistent with the Twenty Eleven theme, and it simply pulls the meta data defined in the post type for the entry title and post image. It also links to the original Dribbble post.

You can get Tammy’s code from her post on Forrst, and the archive template after the jump. Thanks to Tammy for sharing her fun implementation of custom post types!

To use this archive template, you’ll want to put it in a file named archive-shot.php. This name is important so that WordPress will know to pull from the shot post type. You can read about template hierarchy in the codex for more information.

<?php
/**
 * The template for displaying Dribbble Shot Archives.
 *
 * Learn more: http://codex.wordpress.org/Template_Hierarchy
 *
 * @package WordPress
 * @subpackage Twenty_Eleven
 * @since Twenty Eleven 1.2
 */

get_header(); ?>

		<section id="primary">
			<div id="content" role="main">

			<?php if ( have_posts() ) : ?>

				<header class="page-header">
					<h1 class="page-title">Dribbble Shots</h1>
				</header>

				<?php twentyeleven_content_nav( 'nav-above' ); ?>

				<?php /* Start the Loop */ ?>
				<?php while ( have_posts() ) : the_post(); ?>

					<article <?php post_class(); ?> id="post-<?php the_ID(); ?>">
					<header class="entry-header">
						<h1 class="entry-title"><?php the_title(); ?></h1>
					</header><!-- .entry-header -->

					<!-- Let's show the image with the 'image' post meta -->
					<img class="thumb" src="<?php echo get_post_meta($post->ID, 'image', true) ?>" alt="<?php the_title(); ?>" />

					<div class="entry-content"><?php the_content(); ?></div>

					<!-- Let's link out to the dribbble shot with the link_url post meta -->
					<div class="link-out"><a href="<?php echo get_post_meta($post->ID, 'link_url', true); ?>">View this shot on Dribbble</a></div>

					</article><!-- #post-ID -->

				<?php endwhile; ?>

				<?php twentyeleven_content_nav( 'nav-below' ); ?>

			<?php else : ?>

				<article id="post-0" class="post no-results not-found">
					<header class="entry-header">
						<h1 class="entry-title"><?php _e( 'Nothing Found', 'twentyeleven' ); ?></h1>
					</header><!-- .entry-header -->

					<div class="entry-content">
						<p><?php _e( 'Apologies, but no results were found for the requested archive. Perhaps searching will help find a related post.', 'twentyeleven' ); ?></p>
						<?php get_search_form(); ?>
					</div><!-- .entry-content -->
				</article><!-- #post-0 -->

			<?php endif; ?>

			</div><!-- #content -->
		</section><!-- #primary -->

<?php get_sidebar(); ?>
<?php get_footer(); ?>

Siobhan McKeown attended WordCamp Portsmouth and, as far as I can tell, did a killer job covering the event. One session McKeown covered, and published notes on, was a panel all about improving local WordPress meetups. Now I’m encouraged and have a list made to get back on top of our local event.

If you’ve read through part 1 of our introduction to WordPress Hooks, you should be well aware of what constitutes an “action” or “filter” hook and where they can be used. Today we’ll be exploring a little further down the rabbit hole, as we discuss pluggable functions and the concept of creating our own “action” and “filter” hook points, as well as how we can leverage these and create relationships between themes and plugins using various WordPress Hooks.

Note: This tutorial isn’t for the faint of heart (there are a few advanced bits). If you haven’t read part 1, I strongly suggest doing so before reading on.

What are custom action and filter points?

As we discussed previously, it’s possible to use actions to run your own code at key points during a WordPress page load, as well as using filters to modify text, settings or just about anything with a filter on it, to tailor your WordPress installation to be exactly as you’d like it. What about themes and plugins though? How do I inject my own custom goodness in there? That’s where custom action and filter points come in.

Using the same functionality built within the WordPress core itself, we can create our own action points (such as `wp_head` or `wp_footer`) within our themes and plugins. This is, at it’s core, relatively straight forward and can be used in either a standard or a more advanced way. Assuming we’re working on a plugin called, for example, “WPCandy News”, we could add the following to the top of, say, a widget that displays the latest news:

<?php do_action( 'wpcandy_news_widget_before' ); ?>

This is the core of what makes up a WordPress action point. The do_action() function instructs WordPress to look for any hooks attached to whatever tag is specified (in our case, that would be “wpcandy_news_widget_before”) and run that function. Simple, right?

Hold on a moment, that’s not all. The `do_action()` function can also accept multiple arguments (parameters) which are then passed through, if desired, to the function we’re hooking on. Sounds complicated, right? Not really. Let’s use the same example above, but extend it a bit.

<?php do_action( 'wpcandy_news_widget_before', $limit, $id ); ?>

To the snippet, I’ve added 2 extra arguments; a `$limit` variable and an `$id` variable. These are example variables that would be created by the plugin, holding the number of articles to display and the ID we’re assigning to an element in the widget respectively. If we setup our `add_action()` call correctly, we should receive these values in our function, ready for us to use.

Hold on, where does add_action() come into this?

Without add_action(), `do_action()` means nothing. The `add_action()` function allows us, and other themes or plugins, to assign functions to be run when WordPress reaches our action. At it’s core, an example of how we’d hook onto our new action point would be:

<?php add_action( 'wpcandy_news_widget_before', 'wpcandy_news_widget_before_content' );
function wpcandy_news_widget_before_content () {
     echo '<p>' . __( ' This is our custom text.', 'wpcandy' ) . </p>';
} // End wpcandy_news_widget_before_content() ?>

Now that’s great and all, but what about `$limit` and $id`? Enter our last two parameters; the “priority” and the “accepted arguments”.

Priority allows us to optionally specify an ordering for when our action should be executed, if multiple actions are assigned to the same `do_action()` call. This can be extremely useful in controlling the flow of your theme or plugin. Additionally, the accepted arguments number allows us to optionally specify that multiple arguments will be passed through to our action. The default value is 1, so no need to specify anything if you only have 1 argument going through.

This is what our modified code would look like:

<?php add_action( 'wpcandy_news_widget_before', 'wpcandy_news_widget_before_content', 1, 2 );
function wpcandy_news_widget_before_content ( $limit, $id ) {
     if ( $limit > 5 ) {
          echo '<p>' . __( ' This is our custom text.', 'wpcandy' ) . </p>';
     }
} // End wpcandy_news_widget_before_content() ?>

We’ve made several minor changes here, which are as follows:

1. Added the “priority” and “accepted arguments” parameter values, set at 1 and 2 respectively.
2. Added `$limit` and `$id` values to our function, to be passed through by `do_action()`.
3. Made example use of our `$limit` variable inside the function.

Often, for scalability’s sake and keeping things clean and future proof, developers often encase these `do_action()` calls within functions. An example of this would be the `wp_head()` function, added to the vast majority of WordPress themes (so much so, that it is deemed a requirement). This function, in essence, runs `do_action( ‘wp_head’ )`, which is as straight forward as explained above. Magical, right?

Okay, but what about filters?

The concept of custom filter points is much the same as for custom action points, except it relates to filters. As we discussed in part 1, it’s possible to place a filter on just about anything, from a snippet of content to an array of settings or options. The requirements here are much the same as with `do_action()`, except for two aspects; the first being that we’re using the `apply_filters()` function and the second being that we require two parameters instead of just the tag. The second parameter involved is the core of what makes the `apply_filters()` function necessary- the data itself.

Lets dive right into an example of how we’d put this into action. Continuing the example of our “WPCandy News” plugin, lets place a filter on our widget’s title. The code for this would look as follows:

<?php $title = apply_filters( 'widget_title', $title ); ?>

This code says; “take the value of the `$title` variable, apply any filters attached to the ‘widget_title’ hook, and assign the filtered value back to the `$title` variable”. Simple, right?

If you’re familiar with PHP, a basic comparison I like to make when explaining how filters work is to compare them to string-related functions in PHP such as `str_replace()`. We’d use the `str_replace()` function in a much similar to way our snippet above, as follows:

<?php $title = str_replace( 'one', 'two', $title ); ?>

The concept is that we’re passing a value through to our function and getting a value back. This is the core of what a filter function does.

Much like `do_action()`, the `apply_filters()` function can also accept additional arguments. These function in exactly the same way as with `do_action()` and are made available using the “priority” and “accepted arguments” parameters on the `add_filter()` function, in the same way as they are used on `add_action()`. As can be seen, the differences between “action” and “filter” hooks and how they are created is marginal (they both function off of the same backbone code).

Even if you don’t intend to create your own action and filter points, it’s important to understand the full scope of how they work and how the `add_action()` and `add_filter()` functions fit into the grand scheme of things. If you use themes such as Canvas, for example, you’ll notice these types of custom hooks in use, which are there to allow maximum flexibility and control over the way you’d like the theme to display and function.

Enough about hooks, what are these “pluggable function” things?

The concept of a “pluggable function” has become popular within the WordPress community, particularly in the realm of parent themes and theme frameworks. These are functions that are overrideable by simply creating a new instance of the function within a child theme or in a part of the theme that’s triggered before the function’s original location (this is commonly the root of the `functions.php` file). This concept is option used for functions that generate commonly customised areas of themes, such as the post metadata below the title on a theme’s blog posts archives, or the area below the post content on single blog post screens. As with “action” and “filter” hooks, there are virtually infinite uses for pluggable functions.

Okay, I get it. How do I create these?

This part is really simple. It involves two skills; the first being knowing which functions in a theme are pluggable (and therefore, knowing the theme) and the second being knowing how to make the modification you’d like to make.

An easy way of finding out which functions in a theme are pluggable is by searching for the following code:

if ( ! function_exists( 'insert_function_name_here' ) ) {

This line is the beginning of a conditional statement that would commonly wrap around a function with the name “insert_function_name_here”. This just says that the function should only be created if it doesn’t already exist, which leaves room for the function to be overridden. Lets create an example of this.

This would be our original function, with the conditional statement wrapping around it:

<?php if ( ! function_exists( 'wpcandy_display_recent_news' ) ) { 
     function wpcandy_display_recent_news ( $limit = 5 ) {
          // This is where we'd run the meat of the function.
     } // End wpcandy_display_recent_news()
} ?>

Overriding this in our child theme is as simple as copying the code and removing the conditional statement (the first line and the bracket at the end), and placing this in our child theme, where we can then make any modifications to it that we desire, without needing to modify the parent theme.

Hooks and pluggable functions are great, but when do I use which?

A general rule of thumb that I like to stick to is: a function should only be made pluggable if not attached to an “action” or “filter” hook. The reason for this is that it’s possible to remove functions from hooks, as well as to override them using the “priority” setting explained above, which renders the pluggable nature of the function redundant. This also makes it easier to decipher the nature of a function (if it’s pluggable, it’s not attached to a hook), which can speed up development time as well as making it easier for developers who are looking at the code for the first time to decipher what’s going on under the hood.

And that, ladies and gentlemen, is a tutorial on how to create your own action and filter points, as well as a brief introduction into the concept of pluggable functions, how to use them and when to use which techniques.

A common, yet unfortunate practice in the WordPress community involves filling theme functions.php files with tweaks and functionality that is key to a site. The reason this is a bad idea, in short, is that it will tie your critical site functionality to a theme that will eventually change. Good news, though: there is a much better, smarter alternative. It’s called a functionality plugin.

We’re going to create a very simple, very specific functionality plugin that you can (hopefully) use to replace your theme’s functions.php file. After all, the poor guy deserves a break, doesn’t he?

What (and why) is a functionality plugin?

First of all, the thing to realize with plugins is that, for all intents and purposes, they behave no differently than your theme’s functions.php file. I won’t say there are no differences, of course, but a plugin file should not be treated as something foreign and strange. If you’ve edited your functions.php file — even if you’ve just edited it by dropping in PHP that you found searching online — then you are familiar enough to manage your own plugins.

You can think of it as a portable functions.php file that you can take with you when you change themes.

Having said that, when I refer to a functionality plugin, I’m talking about a certain type of plugin intended to belong to a specific website. You can think of it as a portable functions.php file that you can take with you when you change themes.

Functionality plugins should contain all of the code that is important for the necessary structure and functionality of your website. By creating a plugin specifically for your website you have the ability of taking the most important parts of your site with you from theme to theme.

Let’s look at a couple of examples. One common thing often added to functions.php files is a register_taxonomy function. This sort of function will create a custom taxonomy (like categories or tags, but defined by you) to allow you to organize your content further. This is what it would look like:

function people_init() {
 register_taxonomy(
    'people',
    'post',
    array(
      'label' => __('People'),
      'sort' => true,
      'args' => array('orderby' => 'term_order'),
      'rewrite' => array('slug' => 'profiles'),
    )
  );
}add_action( 'init', 'people_init' );

If we include this in our WordPress theme’s functions.php file we may run into a surprise when (not if) we change our theme in the future and don’t see our custom taxonomy on the Dashboard anymore. In order to maintain our taxonomy we would have to scour the functions.php file before the theme change to make sure we didn’t miss anything important.

Or, and this is what I recommend, we could create a plugin named after our site and put the function in there. Then we can change themes freely, knowing that our most important, core functionality is preserved safely in a plugin. I call these special types of plugins functionality plugins.

What belongs in a functionality plugin?

To decide what belongs in a functions.php file and what belongs in a functionality plugin, think long term. Rather than thinking about how your website will look and behave this week, think about how it will look and behave five years from now. With few exceptions, I bet all of our sites will have new and upgraded themes in five years’ time.

For every item we might instinctively want to add to our functions.php file, we should stop and consider whether our site will depend on that functionality in five years or not. Consider the following list of functions, for example:

1. register_post_type() and register_taxonomy(), for creating a custom content type and related taxonomy.
2. add_shortcode(), to create a shortcode for publishing certain kinds of content more easily.
3. add_theme_support( 'post-thumbnails' ) and add_image_size(), to enable post thumbnails and set a certain size.

Let’s take the first example, register_post_type() and register_taxonomy(). In five years will you still want these types of content available to you on the Dashboard and on your site? Of course you will, that’s your site’s content! Your content and how you can access it shouldn’t be determined by the particular theme you’ve chosen. These, and others like it, should be included in a functionality plugin, not your functions.php file.

In the second example, add_shortcode(), we’re adding a way to drop in potentially complex code into our content. There’s a rule of thumb I have for determining what belongs in a plugin: if it modifies or interacts with content it belongs in a plugin. In this case we’re quite literally creating content, and if this function is missing our content will display in the raw shortcode format. In this case as well, it belongs in a functionality plugin.

For more on shortcodes and their use in WordPress themes, see Justin Tadlock’s recent post.

Finally, the third item add_theme_support( 'post-thumbnails' ) and add_image_size() add a post thumbnail and particular size to your site. This is one case that I would say is debatable, since post thumbnails, and in particular sizes, may depend largely on the particular display of your site. In my own case I define post thumbnails in a plugin, but I could see the argument for including them in theme files instead. So, in this case: it depends.

What belongs in functions.php?

Your theme’s functions.php file is for any functions or declarations that are necessary for your theme’s appearance. As long as what you’ve added there don’t effect your content in any way, you should be just fine.

There are a number of examples of functions best kept in your theme’s functions.php file:

1. registern_nav_menus()
2. register_sidebar()
3. wp_enqueue_script() and wp_enqueue_style()
   

The register_nav_menus() is appropriately placed in a theme’s functions.php file, since the placement of the navigation menus themselves depend on the given theme you are using. Keeping this function in a plugin would give you menu placement options on the Dashboard that wouldn’t actually display anywhere in your theme.

register_sidebar() should also stay in your functions.php file, since once again registering sidebars in a plugin could mean you have active plugins on the Dashboard that don’t actually show up anywhere on your site. That would be pretty silly.

wp_enqueue_script() and wp_enqueue_style() are both similar, and I would say depend on the situation. If you are creating a child theme they belong in functions.php. If you are adding them for another purpose (modifying the WordPress admin bar, for instance) then a plugin would likely be more appropriate. As in our earlier examples, this third example requires a bit of context to be sure whether it belongs in functions.php or a plugin.

How to create your first functionality plugin

Creating a functionality plugin is easy, particularly if you understand it as an extension of your functions.php file. You’ll want to start with a plugin file with the appropriate comment header, like this:

/*
Plugin Name: Your Site's Functionality Plugin
Description: All of the important functionality of your site belongs in this.
Version: 0.1
License: GPL
Author: Your Name
Author URI: yoururl
*/

Save that as a PHP file within its own folder in your site’s plugin directory. I would also recommend maintaining a basic readme.txt file for your own sake. Trust me, you-in-five-years will thank you for starting it today. Document the changes you make to your functionality plugin, as well as what everything does.

If you’d like, download our blank functionality plugin to help you get started.

Now head to your WordPress plugins page and activate your plugin. Congrats, you just activated your own plugin: your own comment-only, functionally empty plugin, but your own plugin nonetheless! It won’t do anything, but the nice part now is that you have a file on your site, a plugin file, that will behave much like you’re used to functions.php behaving. And instead of abusing your functions.php file with code you will need later on, you can use your new functionality plugin.

What goes in our plugin?

Now comes the fun part, where we move over site-vital functions to our plugin. To briefly recap, we’re interested in moving functions that are vital to our site’s operation stuff we will want around when (not if) we change our theme in the future.

Everyone’s functions.php file will be slightly different, as well as what will count as “vital site functionality”. But here’s a table with a handful of functions I’ve seen floating around, and where I think they belong:

There are plenty of other examples I could use here (actually, limitless examples) but these should be enough to deliver my point.

Your future creating plugins

Sometimes even the functionality plugin may not provide as much universality as we want. Sometimes it may be better to create our own plugins to create unique functionality in each one. If you’re anything like me, functionality plugins like this will be your first foray into WordPress plugin development. I’m much closer to the beginner side of the spectrum than I am the expert side, but what I’ve learned the past 6 months or so has been driven in large part by working in plugins rather than functions.php.

Next time you are copying and pasting a function from a website, or perhaps you managed to piece together code doing just what you need for your purposes, consider abstracting it, writing yourself some solid documentation on what it does, and turning it into a plugin of its own. Likely this won’t require anything more than moving that function into a plugin file with the appropriate commented header (seen above). By doing this you will have tiny portable pieces of functionality you can enable on sites whenever you need them.

I, for instance, created a few super simple plugins just this month:

• Admin Bar Hover Intent: This one I’m proud of, because I actually released it into the wild on the plugin directory (something I’ve only done once before). It simply implements jQuery hoverIntent on the dropdowns, requiring a deliberate pause over them before they drop down.
• Admin Bar Cleanup: Sometimes I create plugins that tweak things to operate just the way I like them. In this case, Admin Bar Cleanup just hides the WordPress search bar from the admin bar for me. I don’t use it on every website of mine, but on a few it’s definitely active.
• Login Redirect Home: This plugin simply, when active, redirects all login activity back to the home page. I use this one sparingly: only on team P2 blogs, team wikis, and task tracking sites.

Not long ago I would have just added it to my site’s functionality plugin (or worse the functions.php file) and moved on, only to likely re-do the same work later in another project.

But each of these plugins requires less than twenty lines of code. All I did was stop myself from adding functionality to only my own site, and stepped back to consider the usefulness of the functions outside of the current project. If there was use for it, I whipped up a quick plugin file and dropped the code in.

What are your thoughts?

Your turn to speak up. What are your thoughts on functionality plugins? Looking through your theme’s functions.php file, do you see anything which would be better off in a functionality plugin to preserve it for your next theme choice?

WordPress hooks are arguably the basis of WordPress development, forming a large part of the core functionality and used by almost every plugin and theme available to date. The concept of hooks can also be somewhat daunting for users who are starting out with developing for WordPress. Today, we’ll jump in and find out a bit more about just what exactly WordPress hooks are and how they can help you on your way to WordPress rock stardom.

What exactly *are* WordPress hooks anyways?

WordPress hooks are, essentially, triggers of sorts that allow users to, with short snippets of code, modify areas a WordPress theme or plugin, or add their own code to various parts of WordPress without modifying the original files. An example of this could be along the lines of either “when WordPress chooses which template file to load, run our custom code” or “when you generate the content for each post, add social bookmarking links to the end of the content”. These examples will be expanded upon once we’re a bit more familiar with what exactly the different types of hooks are.

Hooks can be divided into “Action” and “Filter” hooks, the former allowing for insertion of custom code at various points (not unlike events in JavaScript) and the latter allowing for the manipulation of various bits of content (for example, the content of a page or blog post). Lets take a closer look at each of these, shall we?

Action Hooks

Action hooks are designated points in the WordPress core, theme and plugin code where it is possible for outside resources (outside of the scope of where the hook is… either in the core, theme or plugin) to insert additional code and, there by, customise the code to do additional functions they may desire. An example of this is the commonly used wp_head action hook, used by many themes and plugins to inject additional CSS stylesheets, processing code or anything else they require to sit between the <head> and </head> tags of their WordPress theme’s XHTML structure. This is the reason for including wp_head(); in all WordPress themes.

To hook on to an action, create a function in your theme’s functions.php file (or in your plugin’s code) and hook it on using the add_action() function, as follows:

<?php
	add_action( 'wp_head', 'wpcandy_actionhook_example' );

	function wpcandy_actionhook_example () {

		echo '<meta name="description" content="This is the meta description for this page." />' . "\n";

	} // End wpcandy_actionhook_example()
?>

The above code adds the text “Hello WPCandy Readers!” between your theme’s <head> tags. Placing “wp_head” in the call to add_action() with “get_header” would display this text above your theme.

The way I like to explain action hooks, in a single sentence, is: “When you get to this point, do that.”

Filter Hooks

Filter hooks are used to manipulate output. An example of this would be to add a line or text (or a hyperlink, or a signature sign-off—whatever you’d like) to the end of the content of each of your blog posts. Filter hooks can also be used for truncating text, changing formatting of content, or just about any other programming manipulation requirement (for example, adding to or overriding an array of values).

Custom code is added as a filter using the add_filter() function. The following code adds a sign-off to the end of each blog post, only when viewing the full blog post screen:

<?php
	add_filter( 'the_content', 'wpcandy_filterhook_signoff' );

	function wpcandy_filterhook_signoff ( $content ) {

		if ( is_single() ) {

			$content .= '<div class="sign-off">Th-th-th-th-th That\'s all, folks!</div>' . "\n";

		} // End IF Statement

		return $content;

	} // End wpcandy_filterhook_signoff()
?>

The above code adds a new div tag to the end of the content of our blog post, only when on a single blog post screen.

A filter hook is like using the str_replace() function in PHP. You give it some data, manipulate, replace or reformat the data and return the new content out at the end.

… and now, for a few commonly asked questions… answered.

Are custom hooks available only to the theme or plugins I’ve got activated?

Custom hooks and filters that are added by a theme or plugin, only apply if that theme or plugin is active. There are many hooks, however, that are global (get_header, wp_head and wp_footer are three examples). If you’d like to switch themes regularly and maintain the functions you’ve hooked onto these, or other, global hooks or filters, I’d recommend writing them into a plugin.

Themes and plugins are able to specify custom filters and actions. We’ll get more into this in part two.

Where can I learn more about action and filter hooks?

My favourite resource is, without a doubt, the WordPress Codex. While there are many tutorials available online regarding filter and action hook applications, the best understanding comes, as they say, when heard from the horse’s mouth. The Codex provides useful examples, as well as up to date and informative explanations, which aid in gathering an overall understanding of the Plugin API (the API that handles action and filter hooks).

• Action hooks: http://codex.wordpress.org/Plugin_API#Actions
• Filter hooks: http://codex.wordpress.org/Plugin_API#Filters
• And for further reading on the topic, the remainder of the Plugin API page is also available: http://codex.wordpress.org/Plugin_API#Hooks.2C_Actions_and_Filters.

Right. Now that we’ve answered a few questions, lets show some practical examples that can be used right off the bat with any WordPress theme.

Add “time ago” time display at the end of each post.

<?php
	add_filter( 'the_content', 'wpcandy_time_ago' );

	function wpcandy_time_ago ( $content ) {

		$content .= "\n" . __( 'Posted ', 'wpcandy' ) . human_time_diff( get_the_time('U'), current_time('timestamp') ) . __( ' ago', 'wpcandy' );

		return $content;

	} // End wpcandy_time_ago()
?>

Use WordPress conditional tags to detect the user’s web browser and add a class with it’s name to the body tag.

<?php
add_filter('body_class','browser_body_class');
function browser_body_class($classes) {
	global $is_lynx, $is_gecko, $is_IE, $is_opera, $is_NS4, $is_safari, $is_chrome, $is_iphone;

	if($is_lynx) $classes[] = 'lynx';
	elseif($is_gecko) $classes[] = 'gecko';
	elseif($is_opera) $classes[] = 'opera';
	elseif($is_NS4) $classes[] = 'ns4';
	elseif($is_safari) $classes[] = 'safari';
	elseif($is_chrome) $classes[] = 'chrome';
	elseif($is_IE) $classes[] = 'ie';
	else $classes[] = 'unknown';

	if($is_iphone) $classes[] = 'iphone';
	return $classes;
}
?>

Remove the WordPress 3.1 Admin Bar.

<?php add_filter( 'show_admin_bar', '__return_false' ); ?>

What about Twenty Ten?

With the introduction of Twenty Ten as the WordPress default theme, the theme received a large amount of documentation in the theme files, with several custom hooks or pluggable functions created specifically for it. Lets take a look at how we can use these hooks to enhance Twenty Ten.

The main custom hook in the TwentyTen theme serves a relatively simple purpose: adding content to the credits area in the footer. This is done by hooking on to the new “twentyten_credits” action hook. Here’s an example:

<?php
	add_action( 'twentyten_credits', 'wpcandy_credits' );

	function wpcandy_credits () {

		$html = '';

		$html .= 'Proudly brought to you by <a href="http://wpcandy.com/">WPCandy</a>.' . "\n";

		echo $html;

	} // End wpcandy_credits()
?>

The above function adds a simple line of credit text to the footer area in the Twenty Ten theme. In part two, we’ll discuss pluggable functions, which can be used in the Twenty Ten theme in particular to enhance and customise the output above and below the post content in the theme.

Coming in part two:

Creating your own hooks & filters and a brief introduction to pluggable functions; the hook’s lil’ sister. Please share your experiences with using WordPress action and filter hooks in the comments below.