We’ll be using a function that was added in 2.7 that doesn’t get used as much as it should: the post_class function. It adds a CSS class to each category, tag etc. we’re interested in the category bit. First thing to do is to create all the different categories you want — that’ll probably be all the standard Tumblr categories: movie, picture, article, quote and link. You’ll then need to add to within your loop the post_class functionality:

<div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>

This now gives each post a class of category-name (ie category-link). This means we can then start styling! For my blog I just added a different icon to each post type (not strictly true—read on!), bit you could go further and do something radical like… change the background colour! Here’s the CSS I used:

.category-link {
	background:  url(/media/icons/link.png) no-repeat;
}
.category-quote {
	background:  url(/media/icons/quote.png) no-repeat;
}

.category-article {
	background:  url(/media/icons/article.png) no-repeat;

}
.category-movie {
	background:  url(/media/icons/video.png) no-repeat;
}
.category-photo{
	background:  url(/media/icons/image.png) no-repeat;
}

That meant each category had a different icon. Of course, I then used a sprite to combine them into a single image. I used the SpriteMe bookmarklet to generate the image and CSS I needed, giving me:

.category-link .icon {
	background-image: url(/media/icons/icon-sprite.png);
	background-position: -10px -142.5px;
}
.category-quote .icon {
	background-image: url(/media/icons/icon-sprite.png);
	background-position: -10px -4.5px;
}

.category-article .icon {
	background-image: url(/media/icons/icon-sprite.png);
background-position: -10px -211.5px;
}

.category-movie .icon {
	background-image: url(/media/icons/icon-sprite.png);
	background-position: -10px -211.5px;
}
.category-photo  .icon {
	background-image: url(/media/icons/icon-sprite.png);
	background-position: -10px -73.5px;
}

That by itself won’t display the icon – you need to add in the icon class:

<div class="icon"><a href="/">Article</a></div>

And hide the text we’ve just added:

.icon {
	width: 60px;
	height: 60px;
	text-indent: 200px;
	overflow: hidden;
}

That’s actually all you need to do to create “Tumblr style” different icons for each category. Quite simple.

Further development

It’s all very well having a different icon, but does that constitute a Tumblog? Not sure it does. Let’s say for the quote post type you want to change the blockquote styling—for normal posts you’ve got:

blockquote {
	font: italic 30px Georgia;
	border-left:10px solid #743399;
	}

Bit you want something that stands out more. Easy. Use post_class again so you’ll need to target the class category-quote:

.category-quote blockquote{
	font: 30px Georgia;
	text-indent:50px;
        background:#eee;
	border:none;
}

QuickPressing

The whole point of Tumblogs are they’re quick and easy to post to. WordPress’ QuickPress Dashboard widget comes to mind. Trouble is for our nice little icons to work, we’ll need to be able to set the category. Luckily, the WordPress support forum has the answer.

Install the following code as a plugin:

<?php
/*
Plugin Name: QuickPress Category
Plugin URI: http://www.t31os.co.cc/
Description: Adds category selection to the QuickPress widget shown in the WordPress dashboard
Author: t31os
Version: 1.0
Author URI: http://www.t31os.co.cc/
*/

class quickpress_category {

	public function quickpress_category() {
		add_action( 'wp_dashboard_setup' , array( $this , 'dashboard_updater' ) );
		add_action( 'admin_init', array( $this , 'register_option' ) );
	}

	public function register_option() {
		// Register the setting - with basic validation, only need be 0/1 or true/false , keep it simple
		register_setting( 'enable-dropdown', 'quickpress_category' , array( $this , 'option_validation') );
		// Register the setting field
		add_settings_field( 'quickpress_category', 'Quickpress category', array( $this , 'add_category_option' ), 'writing', 'default' );
	}
	public function option_validation( $input ) {
		if( !$input )
			return 0;
		if( $input == 1 )
			return 1;
		else
			return 0;
	}
	// Output the checkbox for toggling the category dropdown
	public function add_category_option() {
		$checked =
			( get_option('quickpress_category') && get_option('quickpress_category') == 1 ) ? 'checked="checked" ' : '';
		?>
			<div class="input-text-wrap">
				<label class="selectit">
					<input type="checkbox" name="quickpress_category" <?php echo $checked; ?>value="1" />
					Enable quickpress category selection.
				</label>
			</div>
		<?php
		settings_fields('enable-dropdown');
		return;
	}

	public function dashboard_updater() {
		// Global the variable so it's available inside the function (that's how you access variables outside a functions scope)
		global $wp_meta_boxes;

		// Determine where the widget is and update the callback name if the option is enabled
		switch( true ) {

			case ( !get_option( 'quickpress_category' ) || get_option( 'quickpress_category' ) == false ) :
				return;

			case ( isset( $wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press'] ) ) :
				$wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press']['callback'] = array( &$this , 'quickpress_widget' );
				return;

			case ( isset( $wp_meta_boxes['dashboard']['normal']['core']['dashboard_quick_press'] ) ):
				$wp_meta_boxes['dashboard']['normal']['core']['dashboard_quick_press']['callback'] = array( &$this , 'quickpress_widget' );
				return;
		}
		return;
	}
	// Most of this is just code from the original widget
	public function quickpress_widget() {
		// Call $current_user, so there's no reliance on $GLOBAL, per original widget
		global $current_user;

		$drafts = false;
		if(
			'post' === strtolower( $_SERVER['REQUEST_METHOD'] ) && isset( $_POST['action'] ) &&
			0 === strpos( $_POST['action'], 'post-quickpress' ) && (int) $_POST['post_ID'] ) {

			$view = get_permalink( $_POST['post_ID'] );
			$edit = esc_url( get_edit_post_link( $_POST['post_ID'] ) );

			if ( 'post-quickpress-publish' == $_POST['action'] ) {
				if ( current_user_can('publish_posts') )
					printf( '<div class="message"><p>' . __( 'Post Published. <a href="%s">View post</a> | <a href="%s">Edit post</a>' ) . '</p></div>', esc_url( $view ), $edit );
				else
					printf( '<div class="message"><p>' . __( 'Post submitted. <a href="%s">Preview post</a> | <a href="%s">Edit post</a>' ) . '</p></div>', esc_url( add_query_arg( 'preview', 1, $view ) ), $edit );
			}
			else {
				printf( '<div class="message"><p>' . __( 'Draft Saved. <a href="%s">Preview post</a> | <a href="%s">Edit post</a>' ) . '</p></div>', esc_url( add_query_arg( 'preview', 1, $view ) ), $edit );

				$drafts_query = new WP_Query( array(
					'post_type' => 'post',
					'post_status' => 'draft',
					'author' => $current_user->data->ID,
					'posts_per_page' => 1,
					'orderby' => 'modified',
					'order' => 'DESC'
				) );

				if ( $drafts_query->posts )
					$drafts =& $drafts_query->posts;
			}
			printf('<p class="textright">' . __('You can also try %s, easy blogging from anywhere on the Web.') . '</p>', '<a href="tools.php">' . __('Press This') . '</a>' );
			$_REQUEST = array(); // hack for get_default_post_to_edit()
		}
		$post = get_default_post_to_edit();

		// Args for dropdown
		$args = array(
			'order' => 'ASC',
			'hierarchical' => 1,
			'echo' => 0,
			'name' => 'post_category[]',
			'hide_empty' => 0
		);
		// Create dropdown
		$categories = wp_dropdown_categories( array_merge( $args , array( 'selected' => get_option('default_category') ) ) );
		// Replace the ID
		$categories = str_replace( "id='post_category[]'" , "id='post_category'" , $categories );

		?>

		<form name="post" action="<?php echo esc_url( admin_url( 'post.php' ) ); ?>" method="post" id="quick-press">
			<h4 id="quick-post-title"><label for="title">Title</label></h4>
			<div class="input-text-wrap">
				<input type="text" name="post_title" id="title" tabindex="1" autocomplete="off" value="<?php echo esc_attr( $post->post_title ); ?>" />
			</div>
			<h4 id="quick-post-category"><label for="title">Category</label></h4>
			<div><?php echo $categories;?></div>
			<div class="clear"><br /></div>
		<?php

		if ( current_user_can( 'upload_files' ) ) { ?>
			<div id="media-buttons" class="hide-if-no-js"><?php do_action( 'media_buttons' );?></div>
		<?php
		}
		?>
			<h4 id="content-label"><label for="content">Content</label></h4>
			<div class="textarea-wrap">
				<textarea name="content" id="content" class="mceEditor" rows="3" cols="15" tabindex="2"><?php echo  $post->post_content; ?></textarea>
			</div>
			<script type="text/javascript">edCanvas = document.getElementById('content');edInsertContent = null;</script>
			<h4><label for="tags-input">Tags</label></h4>
			<div class="input-text-wrap">
				<input type="text" name="tags_input" id="tags-input" tabindex="3" value="<?php echo get_tags_to_edit( $post->ID ); ?>" />
			</div>
			<p class="submit">
				<input type="hidden" name="action" id="quickpost-action" value="post-quickpress-save" />
				<input type="hidden" name="quickpress_post_ID" value="<?php echo  (int) $post->ID; ?>" />
				<?php wp_nonce_field('add-post'); ?>
				<input type="submit" name="save" id="save-post" class="button" tabindex="4" value="<?php  esc_attr_e('Save Draft'); ?>" />
				<input type="reset" value="<?php esc_attr_e( 'Reset' ); ?>" class="button" />
		<?php
		if ( current_user_can('publish_posts') ) {
			echo '<input type="submit" name="publish" id="publish" accesskey="p" tabindex="5" class="button-primary" value="' . esc_attr('Publish') . '" />';
		}
		else {
			echo '<input type="submit" name="publish" id="publish" accesskey="p" tabindex="5" class="button-primary" value="' . esc_attr('Submit for Review') .'" />';
		}
		?>
			<br class="clear" />
			</p>
		</form>
		<?php
		if ( $drafts )
			wp_dashboard_recent_drafts( $drafts );
		return;
	}
}
$quickpress_category = new quickpress_category();

// Removes the option from the options table on deactivation
register_deactivation_hook( __FILE__, 'remove_options' );
function remove_options() {
	delete_option( 'quickpress_category' );
}
?>

Then under Settings, Writing, tick the new box that asks if you want to enable categories for QuickPress. Click it, save and you’re done.

Wrapping up

It’s actually easier than it looks. The post_class function opens the door for awesome customisation so go ahead and tumble away!

Today it’s Ian Stewart who has very recently joined Automattic as “Theme Wrangler”.

Maybe. Probably not. All powerful Themes with pretty Child Themes are
a solution to a lot of Theme development problems (specifically, rapid
site development in a particular mode) but they can’t solve every
problem.

My wild guess is that this year we’ll see simplicity become a feature
in WordPress themes with the disappearance of ridiculously massive
options pages altogether. We’ll see the best WordPress Themes become
simpler and more focused.

“We’ll see simplicity become a feature in WordPress themes”

My easy, for sure guess? Integration with the super-cool new menu
management introduced in WordPress 3.0.

But they already are! This is happening right now every time a cool
free Theme is released. No one has to literally join forces when they
free up the code behind their WordPress themes. And everyone that uses
WordPress really does benefit. It’s completely awesome.

I think most users look less for flashy designs and more for Themes
they can make their own. Themes they can see themselves in. It’s the
Themes that “disappear” that truly stand out.

Without a question, the new menu management. It solves a whole mess of
WordPress site development problems for Themers looking to create
robust, sustainable designs. There are also a few new Theme functions
coming that will make the rapid creation of solid Themes that much
easier. Oh, and the integration of WPMU. And the 2010 Default Theme,
of course! Lots of stuff, really.

Today Cory Miller from iThemes joins in the conversation.

No, I think it’s a blend of single “typical” themes and all-powerful ones that do cool things and of course everything in between for different niches and functionality needs. WordPress is too diverse and expansive and the needs too great and varied to think there will be one theme or framework that can do everything. Thinking otherwise is arrogance, in my opinion.

The biggest one on our roadmap right now is a Style Manager where people can make quick and easy changes to their theme design that personalizes it for their unique brand. Talking with other theme devs and knowing our own community, customization requests are by far the biggest request we get.

The needs [of WordPress are] too great and varied to think there will be one theme or framework that can do everything

Generally though I would say … anything that makes it easier on the end user, which is almost endless. The menu issue was critical and on our roadmap as well but I’m thankful it’s being solved by, I might add, a premium theme developer in WooThemes. (Score one for commercial enterprises assisting the community!)

I could only see that if WordPress.org hosted an actual commercial theme store, but even then we’re way past that point now with established communities and independent sites, directions and priorities. The primary reason I don’t think it’ll ever happen is a combination of ego and control. We all believe we have the best product and all want all the control — if we’re being honest, that’s why we became entrepreneurs. But I will say … competition is great for theme innovation and for the community. The other theme devs force us to be and do better for our customer communities, and vice versa.

The other theme devs force us to be and do better for our customer communities, and vice versa.

Design (beautiful, attractive design sells a theme), functionality (does it help you do something better or easier), followed by support. People come for the first two and stay for the third … good support is a non-negotiable.

The WordPress MU merge (I think it’s called MS) and custom menu navigation. I’m also interested to see how the image editing/resizing features work.

I think that for each Theme company independently this will more or less be the case. What won’t happen, is one theme, such as the new 2010 default theme being used by everyone in framework form. Child Themes are still fairly unheard of, which is a shame because they are so powerful. I do think that the continued success of Frameworks is the mass adoption of Child Themes.

Custom Post Types. This will allow sites to be built in so many new ways, and IMO give finer control over display and organisation.

I think that actually the inverse would happen. If everyone joined forces, a) nothing would ever get done; design and development by committee is tedious, time consuming, and most importantly conflict-causing. B) the theme market would stagnate. Nothing new would ever come about because there would be no commercial or Capitalistic drive for themes to develop more.

The WordPress community has always benefited from sharing code and learning from others. By seeing one dev create a theme with a certain feature, others are inclined to better it, use it, tweak it etc. This all brings about better themes for us all.

Design is always a huge selling point, but good viral and social marketing/advertising goes a long way too. Getting people to know about your product, and getting them to believe that it is what they want (;-)) is crucial. Often, just because a theme has X amount of kick ass features, that doesn’t mean the theme is going to stand out from the crowd, since that crowd is, as you say, always growing bigger.

I’m loving the new default theme that will be released with 3.0. I’ve been playing with it a lot lately, and I like what I see. I think we’re going to see a lot of new bloggers just sticking with that theme when they first install WordPress.

I think so, yes. To me, this is the way WordPress themes have been moving for the last couple of years. There’s simply no way to accomplish the things that theme frameworks + child themes can accomplish with a traditional theme.

I think everyone will explore the idea of a central framework. Some won’t have the stomach for it … it’s not an easy thing to take on. I think many people are looking to StudioPress and Genesis to see what happens there with the Child Theme Marketplace. If it does well (and it has so far), then I think you’ll see more people explore the concept in their own companies.

“I think everyone will explore the idea of a central framework.”

Also, I think more and more you will see themes integrating with core WordPress features rather than building out their own. This may also be the year that many theme developers really start to contribute back to WordPress core, with WooThemes taking the lead on that front with the integration of their Navigation system into WordPress 3.0.

No, and I don’t really think there would be any benefit from all the theme developers joining forces. Perhaps on little projects here and there, but not as a whole.

Creativity and competition are soulmates.

I’m not crazy about this, but designs do sell themes. I wish that more people would focus on the important stuff, but at the end of the day, pretty colors make people drool.

Aside from that, support sells the theme. If a customer is confident that they have a force of helpful individuals to help them get their theme running correctly, it takes the much of the risk out of the purchase.

“At the end of the day, pretty colors make people drool”

Finally, I think a theme developer (or development company) has to prove themselves. There’s no such thing as an overnight success in this business. It takes months (maybe years) to prove that you’re here for the long haul, and that you’ll deliver on your promises. Earning trust for your brand is a slow process, but it’s necessary for the success of your business.

Menu management is something I can’t wait to play with. It’s long overdue, but I’ve been watching the progress in WordPress trunk and I can safely say that the implementation is going very well. It’s going to be one of the 3.0 killer features, for sure.

Today it’s Adii. He doesn’t really need any introduction as I expect most of you know about the astounding success he’s had at WooThemes of late.

“I believe that the friendly competition is good for everyone as it keeps theme developers on their toes.”

If there were any prizes for predicting this correctly, I’d win… It will definitely be the new Custom Navigation system that WooThemes has contributed to the WP 3.0 core. As soon as this is ready, every commercial theme developer worth their salt will integrate support for this.

I don’t agree with the joining of forces, because I believe that the friendly competition is good for everyone as it keeps theme developers on their toes. This competition breeds innovation and forces everyone to re-think what they’re doing at the moment and how they can better that in future. The knock-on effect of this is (for example), that if WooThemes releases something great, other theme developers copy that and implement in their own unique way too (so everyone in the community benefits).

At WooThemes, we’ve been inspired on many occasions with what others were doing and implemented similar feature sets in our themes

We don’t necessarily have to be first to market with every new feature, as that is impossible. But by implementing it and improving our themes, our users too benefits from innovation by another developer. Hope that thinking makes sense…

That’s an open question, isn’t it? To a large extent, you can see what every theme developer’s niches are by looking at their themes and I think everyone has an unique angle towards satisfying specific needs for their own users. Hence why you’d get users who own themes from WooThemes, StudioPress, ThemeForest and then a copy of Thesis to top things off.

I think all of these themes (and the respective developers) solve different problems in different ways and the variety in choice (to potential users) is extremely valuable. So whilst they may decide on a WooTheme for one project, they might go with StudioPress or Thesis for the next, as they may be better suited to a specific project.

The custom navigation, but that’s because I’m biased… Beyond that, we’re hoping that custom post types are more defined and elaborate in 3.0, as that will be game-changing for WP themes in the longer run (turning the platform into much more of a fully-fledged CMS).

It all started when Jad sent me a Google Chat message asking if I’d help him with converting an HTML design to WordPress. I then ended up doing the whole theme. I still don’t know how that happened. Over the next couple of weeks, Jad then revisited the theme, doing it again himself — the best way of learning!

The first thing to do was to take the HTML and put it into header, index, sidebar and footer files. Here’s a badly made screenshot of which bits went where:

Nothing here is too taxing for WordPress to handle, but a couple of things pose a problem.

The header

As the design was only going to be used on DesignInformer, there was no need to make the navigation dynamic. The same applied to the logo, RSS and Twitter buttons, so nothing really to do here!

The index

I’m using the index and not the home file here as we’re creating something that can be used as a fallback. A closer look at the post area reveals it’s quite complex. WordPress brain in gear, these were what I thought I’d do (another poorly made graphic!):

Looking at the CSS though, we hit a problem. Quite a few problems actually. First is that the excerpt is a paragraph with a class. the_excerpt outputs plain <p>s. An ingenious solution is at hand though: the_excerpt_rss doesn’t have any wrapping <p>s so we can apply our own styling:

<p class="excerpt"><?php the_excerpt_rss(); ?></p>

The next problem is the ‘Continue Reading’ section. That too has a class so we can’t just use the read more that comes with the_excerpt. Instead, we can use <?php the_permalink(); ?> and wrap the continue reading <p class> around that:

<p class="read-more"><a href="<?php the_permalink(); ?>">Continue Reading</a></p>

I then found out that Jad wanted backwards comparability with his old posts which were using custom fields, not the post_thumbnail function. The solution was to use Justin Tadlock’s get_the_image plugin, albeit customised a bit.

The sidebar

Badly made graphic number one is actually quite heavily cropped so you don’t see the ‘Popular Posts’ section of the sidebar. For this, we followed my own advice to get most commented posts the right way:

<ul>
<?php $popular = new WP_Query('orderby=comment_count&posts_per_page=5'); ?>
	<?php while ($popular->have_posts()) : $popular->the_post(); ?>	

	<li><a href="<?php the_permalink() ?>" rel="bookmark" title="<?php the_title_attribute(); ?>"><?php the_title(); ?> (<?php comments_number('0','1','%'); ?>)</a></li>

<?php endwhile; ?>
</ul>

The rest of the sidebar is filled with ads and a latest tweets section which I left Jad to do via a plugin.

The footer

I largely left the footer as is — the Categories section was better left hardcoded as we didn’t want all of the categories, the friends list can be easily edited manually and the bottom of the footer is static too. That leaves the recommended reading section. A custom query is in order. We want two posts from the category with an ID of 164, so use the following code:

<ul>
<?php $reading = new WP_Query('cat=164&posts_per_page=2'); ?>

	<?php while ($reading ->have_posts()) : $reading ->the_post(); ?>	

	<a href="<?php the_permalink() ?>" rel="bookmark" title="<?php the_title_attribute(); ?>"><?php the_title(); ?> (<?php comments_number('0','1','%'); ?>)</a>

<?php the_content(); ?>

<?php endwhile; ?>
</ul>

We can use the_content as the whole post is being displayed – they’re only short!

Lessons learnt

The major lesson learnt here is that knowing your template tags can get you out of a lot of holes! Not knowing the_excerpt_rss could be used to get our p class could have meant you’d added in an extra div in an attempt to sort it out when you needn’t have done! Hopefully this case study will have helped you see in a real example how converting HTML to WordPress is easy!

WordPress theme development is actually very hard. In this post we’ll look at the different aspects of WordPress theme development, starting with the fundamentals and then moving swiftly onto the basics, template tags and the more advanced files.

Contents

• Part 1: Introduction; the fundamentals of WordPress theme development
• Part 2: The index.php and style.css files: the most important parts of any theme.
• Part 3: The header.php, sidebar.php and footer.php files.
• Part 4: The single.php file: the file that handles posts.
• Part 5: The archive.php, home.php and functions.php files.

Downloads

Part 2 onwards all have an accompanying download – they’re listed here:

• Part 2
• Part 3
• Part 4
• Part 5

Part 1

THE FUNDAMENTALS

A WordPress theme is made up of a number of different files, and they all contain a seperate section of the page; the header will contain the title and navigation, then the index will contain the main content area (or on a post, the single file does the job). The sidebar, obviously contains the sidebar and the footer contains the footer and closes off the HTML. This all sounds very straightforward, but the important bit is how you can just have a single file, change it once and you will change your whole site. Change your footer and that change will be reflected sitewise, not just on a single page.

Expanding on this, a post page is made up of four files (usually): the header.php file for the header, the single.php file for the post content, the sidebar.php file for the sidebar and the footer.php file for the footer. You can have the same header.php, sidebar.php and footer.php files for the whole site, and so when you make a change, this change comes immediately sitewide.

THE ADMIN STUFF

Getting started with WordPress theming can be a daunting prospect, and before we start, I’ll say this now; I’m going to assume a good solid understanding of both CSS and HTML. Good places to gain this knowledge are CSS-Tricks and Nettuts+.

A couple of things to sort out first – you’ll need to get yourself a code editor. If you’re using Windows, the free Notepad++ is an excellent tool to have and if you’re on a Mac then I’m sure there are plenty of great free editors, but the one that everyone raves about is called Coda(and it’s not free). If you’re serious about design then Coda will be worth it in the long term. The only other quick thing we need to do is install WordPress locally. You can find how to do that here.

Part 2

Creating a basic theme

First off, the style.css. This is our stylesheet. This isn’t a design series, so I’m not going to dwell on it too much, but there are some important parts of a stylesheet which WordPress needs that tell it some info about the theme. The theme we’ll be creating this week is called Champion. It’s based on the Default WordPress theme for ease of use. Download the theme and unzip it. Open up the style.css file and you’ll see something like this:

/*
Theme Name: Champion Theme URI: http://wpshout.com
Description: description
Author: Alex Denning
Author URI: http://wpshout.com
Version: 1.0
*/

And that’s all you need to make a stylesheet WordPress-ified. After you’ve got that in a stylesheet, you can style as you would normally.

The index

WordPress has lots of different template files. They’re all used to generate different types of post, page, archive etc. A previous post explains all, but to give you an idea

For posts, first, WordPress will look for the single.php file, but if it isn’t found then it will use the index.php to display the post.

For author archives, first WordPress will look for the author.php file, then the archive.php file and if it can’t find that it’ll use the index.php file to display the author archive. It’s the same with all types of post, page or archive; they all revert to the index.php. This is why it is the most important file of them all.

So let’s get started. Open up the theme files again and open the index.php file. We don’t need any other files because as I’ve just pointed out, all types of page revert back to the index.php file so to prove the point, in this part it is the only file we’re going to use. As the week goes on we’ll be adding more files back in, don’t worry! Open up the index.php file and look for line 49, which starts with:

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

<?php while (have_posts()) : the_post(); ?>

This is the WordPress Loop, and the most important part of any WordPress theme. This part is exciting; we’re using the most important template file and the most important part of any template file!

THE LOOP EXPLAINED

So what is this Loop? It’s the thing that goes and fetches posts. With the loop started, look at the next couple of lines, ignoring the opening <div>s. They read:

<h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2>

<?php the_content(); ?>

These are your very first template tags. Template tags are pieces of PHP (which always start and end <?php and ?>)  which tell WordPress for the current post, get this piece of information. For example, the first template tag used here, the_permalink, tells WordPress for the current post, get the post permalink. Used inside an anchor and you’ve got yourself a link to current post. The next template tag, the_title, as you might have guessed, outputs the title of the post. Add that all together, inside an H2 tag and you’ve got yourself a title which when clicks goes to the post’s post page.

The final template tag above is the_content. This is tells WordPress for the current post, go and find the contents of it and display it.

The next part of the file reads (again, ignoring the divs):

<?php endwhile; ?>

<php next_posts_link('' Older Entries') ?>

<?php previous_posts_link('Newer Entries &raquo;') ?>

<?php else : ?>

<h2>Not Found</h2>

<p>Sorry, but you are looking for something that isn't here.</p>

<?php endif; ?>

The first part, endwhile tells WordPress when you’ve finished displaying all the posts, display this:. What is displayed are links to older and newer entries using the template tags next_posts_link and previous_posts_link.

The next part, else tells WordPress if you can’t find any posts, display this:. You’ll see that if no posts are found then a ‘Not Found’ displays. Finally, endif finishes the loop.

So there we have it; the most important part of any WordPress theme; the loop. What we’ve also done is get introduced to template tags. There are quite a few to get yourself familiar with, and you can find them listed on the codex.

With the deciphering done, load up the theme to your WordPress install and activate it. You’ll see that despite only having a stylesheet and a single index.php file, the theme loads fine. Click on a post and you’ll see that gets displayed too. Pages, post archives, category archives and any page you like work fine too. Going back to what I said earlier – all template file hierarchies fall back on the index.php file – this proves it.

This also arises the question – “if I can do all this with a single file, why have more template files?” The answer is customisation. A change to the index.php file will be reflected throughout the entire site, so if you just want to change post pages then you wouldn’t be (easily, see à) able to do this, which is why we have different template files (the pedantic might point out you could get round this with if statements, which is true, but it wouldn’t be particularly practical at the end of the day).

Part 3

SEPARATING the files

Download the latest copy of our theme and open up the index.php file. First thing that you should notice is that the header has been replaced with a piece of PHP -

<?php get_header(); ?>.

This is another of WordPress’ template tags, and it’s telling WordPress go into the theme files, find the header.php file and display the contents here. As your theme becomes more and more complicated, this allows you to create a single header and use it throughout your theme. At this point, you’re probably opening up the header.php file. Good idea! Upon opening it, you’ll see it’s the same thing we had starting off our index.php file. All that has changed is now it has a whole file to itself.

DECIPERING THE HEADER

Before we move on, a couple of important header points. You’ll notice that the header doesn’t display things like your content type, it uses template tags (I did say there were lots!) such as:

<?php bloginfo('html_type'); ?>

When this loads, what is displayed is your HTML type – have a look at the source code yourself – text/html gets shown. Template tags such as this one are used throughout the header to get the stylesheet url, title, pingback url etc etc. The reason for this is because every WordPress installation is different and so by using dynamic template tags, you can cater for all of these different installations at once.

THE SIDEBAR

Look back in the index file and you’ll see that the sidebar has gone too, and its place <?php get_sidebar(); ?>. Like the header, this tells WordPress go into the theme files, find the sidebar.php file and display the contents here. There’s not much to decipher here; a couple of new template tags and only one completely new thing: widgets, which we’ll discuss further in the last part as it requires the functions.php file.

THE FOOTER

The final part of this part’s instalment is going to look at the footer. Like the header and sidebar, it has been removed from the index.php file and now resides in the footer.php file. Again, it is referenced with the <?php get_footer(); ?> function. Nothing much new here; again some more new template tags, but other than that it’s much the same as the index.php file’s footer we had before.

Part 4

DEVELOPING THE SINGLE.PHP (POST PAGE) FILE

Upon opening the single.php file, it should look pretty familiar; the first line is <?php get_header(); ?> which, as we learnt in the previous part, tells WordPress find the header.php file and display the contents here. Skip a line and you’ll see:

<?php if (have_posts()) : while (have_posts()) : the_post(); ?>

That too should look familiar; it’s the loop! Scroll down further and you’ll see a couple of template tags -

<?php the_title(); ?>

and

<?php the_content(); ?>

. After that, scroll down to line 35 and you’ll meet a new template tag:

<?php comments_template(); ?>

Just like get_header, get_sidebar and get_footer, this tells WordPress go and find the comments.php file and display the contents here.  You can probably guess where this is going – get the comments.php file open.

GETTING TO GRIPS WITH WORDPRESS’ COMMENTS

Open it up and… eek! It’s complicated. The comments file is notorious for being the thing that must be done but no-one really likes doing. But that isn’t going to stop us, is it? No. Let’s get going. The first part of the code just checks to see if the comments file has been loaded directly, and if it has an error message gets displayed. Next, it checks to see if the current post is password protected, and if it is then the user is asked to enter a password to see the page. Leave this bit of code alone; it’s important it is kept and, well, what has it ever done to you?

Next is the bit we’re interested in: the comments loop. It starts by checking if comments are open:

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

And if they are then some text is displayed, showing the number of comments a post has. Skip a couple of lines to line 28 where an ordered list is opened and inside that ordered list is <?php wp_list_comments(); ?>. This is another of WordPress’ template tags, and it spits out all of a post’s comments. There are other ways of displaying comments (that offer more customisation), but that is a post for another day; as I said, it’s quite a complicated subject.

Gloss over the next part (which is pretty self explanatory) to line 49. Here starts the form that you see on most blogs – this is the part where you fill out your name, email, website and comment. There isn’t really much need to customise this or change it in any way, so we won’t. Instead, we’ll go back to the single.php file and finish up with that.

FINISHING OFF WITH THE SINGLE POSTS

Open up the single.php file again and scroll down to line 37, just after where we left off. Here is something that again should look fairly familiar; it’s the loop finishing off and saying if no posts are found then display this:. The

<?php endif(); ?>

closes off the loop and then we get to the familiar looking get_sidebar and get_footer, which we learnt about in the previous installment of the series.

CREATING A POST PAGE

This tutorial has focused heavily on posts, without a mention of pages. The good news is that pages run identically to posts and so to create a post page, all you have to do is save another copy of your single.php file as page.php. And you’re done. I did say it was simple!

Part 5

Creating an awesome archive

According to the WordPress file hierarchy (which we discussed earlier), all archives – date, category, author and tag each have their own template file, but they also all fall back on a single file – the archive.php file. The idea here is that if you’re clever, you can save yourself creating a couple of additional files.

Upon opening the file, you’ll be greeted with the familiar get_header and the loop. Then, on line 14 starts a whole load of PHP if statements – if this is a category archive, display this, if this is a tag archive, display this etc etc. After that, on line 37 the loop swings into action and we have the familiar template tags we learnt in part two. Finally, on line 56 the standard “no posts were found” gets replaced with another if statement, changing it to “no posts were found under this category/tag etc etc”. After that, the familiar get_sidebar and get_footer and the archive page ends.

It’s pretty similar to the index.php page, all that is happening is that there are a couple of ifstatements to change the titles according to the archive.

CREATING AN (EQUALLY AWESOME) HOMEPAGE

Something you might have noticed is that so far we haven’t created a specific homepage. Whilst there is a homepage, that’s just the contents of the index.php file. At this point, it’d be appropriate to introduce a new template file: the home.php file. It’s highest in the hierarchy for the homepage, so WordPress first looks for the home.php file and if that doesn’t exist then it uses the index.php, which is why so far we’ve so far been creating a homepage with just the index.php.

Why can’t I just use the index?

Good question. You can’t because the index file is at the bottom of all template hierarchies – if you don’t have a specific template file for a certain type of page then WordPress displays the page using the index.php file. For that reason it is best to leave the index file as it is and create an additional page, home.php for generating a homepage. It’s also one of those useful little tricks that are good to know as it allows you to stop using WordPress as a blogging platform and start using it as a CMS.

In our example, we’re not going to do anything with our home.php file, other than make it and copy and paste the contents of the index.php file into it, but as someone who is getting started with WordPress theme development, it is something that you should know exists and you’ve always got the option of customising the homepage further yourself.

THE FUNCTIONS.PHP FILE

This is probably the most powerful template file there is. Effectively, it lets you run plugins from within your theme. It’s not a page that gets displayed, it’s a file that lets you run functions that you can display in other files. Common uses include:

• Widgets! Whilst you put where you want widgets to display in the theme files, but they’re powered from the functions.php file.
• Theme options. Theme options pages are too created from the functions.php file. WPShout has a whole tutorial written on the topic here.
• Language – the functions.php file lets you set up the option for multi-lingual theming.

As the functions file is just so complex, I’ll just cover some basics. The code below will create a widget area ‘Widget area 1’ with an opening div before (which closes after) and the widget title gets an H3 tag:

<?php if ( function_exists('register_sidebar') )

register_sidebar(array(

'name' => ' Widget area 1',

'before_widget' => '<div>',

'after_widget' => '</div>',

'before_title' => '<h3>',

'after_title' => '</h3>',

)); ?>

To insert the widget in your sidebar you’ll need to add the following to your sidebar.php file (or wherever you want to widgetise):

<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar('Widget area 1') ) : ?>

<p>This area is widgetised! To make use of this area, put some widgets in the 'Widget area 1' section.</p>

<?php endif; ?>

This is just the start though; take a read of thisto find out how to build your own theme options page.

Concluding the series

I hope this series has given you a good start with developing WordPress themes, and make sure you subscribe by RSS to hone your skills further. As I hope I’ve proved in this post, it needn’t be hard to become aware of what all the bits of code on your theme do, and you never know, perhaps in a year or two I could be reading your blog about advanced uses of WordPress!

What’s in a name

Before we get to the reviewing bit, I’m sure many of you have pondered in the past why Packt put version numbers with the titles of their books; it immediately dates the book in a world where new versions are released all of the time. I have an answer to that question:

The title is decided by the Acquisition Editors, and primarily the version numbers are mentioned so that the readers can immediately get a vague idea about the book and the technology it caters to.

I’m not convinced that’s a good excuse and it surely means people think the information is dated, even though it’s likely it isn’t.

WordPress 2.7 Cookbook

This is the book that inspired the hugely successful WPRecipes. It’s not sold too well either, and you can kinda see why; why would you buy a book when you can get it on one site? Good question. The best answer I can offer is that the book is very well structured; you can start learning about themes and then gradually move on to customisation, using plugins, optimisation, functionality and then some general improvements.

Hey, it’s me!

The book is well illustrated with lots of screenshots but is fundamentally flawed because it’s a book primarily filled with code snippets that would be a pain to type out unless you bought the electronic version, in which case you might as well just visit WPRecipes. That’s not to say I didn’t find it useful though – I was able to pick a topic and then find the odd bit of information that I didn’t know and I’d find useful.

I’d recommend this to: someone just getting started with WordPress and people with a basic – medium knowledge. Ok then, anyone who isn’t confident building advanced themes.

WordPress 2.8 theme design

This one is directly up against Rockstar WordPress and to an extent Digging into WordPress too. In a nutshell, I’d go for the other two over this. It tries to do an awful lot too much which leaves it doing it badly. Really important things like the loop aren’t discussed in much detail at all (just over a page and 3/4 of that is code).

That’s all I’ve really got to say about this. In a book about theme design, I don’t want to learn halfway through how to add a YouTube video to a post.

I’d better say a bit more though. To its credit, the book does include some up-to-date features – post_class and some CSS3 for example, but then again, Digging into WordPress is being updated all the time (with an update due out soon, I hear).

I’d recommend this to: someone wanting to get started with WordPress and WordPress theme development but wants a printed book that’s not too expensive. That’s a niche market. Go for Digging into WordPress instead.

Conclusion

My nice friends at Packt probably won’t be my friends after that, so if you wanted to win one, sorry. I can recommend the WordPress Cookbook as it’s well laid out and thought through. Just don’t go near the other one. If you want a book about WordPress theme design, go for Rockstar Theme Design. If you want a book about WordPress development and design, go for Digging into WordPress.

When building ShiftNews, one thing we were always vary wary of was the effect on load time stuff would have. That meant sprites, not making too many database calls, that kind of thing. And then Alex C split the CSS file in two (just about in two anyway) and put half of it in single.css and the rest in style.css. The single.css file only gets loaded on posts and pages. In a moment the loading time of the homepage’s stylesheet was (just about) halved. Pretty neat. Good news is you can do it too!

Choosing what you need

Choosing which bits you need is probably the hardest bit (and it’s not too hard either!). Obviously you’ll need to keep the barebones layout in the style.css, but things like comment styling, post styles (perhaps you’ve got a custom post layout grid), list styling, blockquotes and the like can go into a new file.

What if…

Next stage is to include the two stylesheets. Open up your header and add the following (or something like):

<link href="<?php bloginfo('stylesheet_url'); ?>" rel="stylesheet" type="text/css" />

<?php if ( is_singular() || is_404() || is_search() || is_archive() ) { ?>

<link href="<?php bloginfo('template_url'); ?>/css/single.css" rel="stylesheet" type="text/css" />

<? } else {} ?>

That’s stylesheets done. We can now move onto plugins.

Loading plugins conditionally

Whilst we can’t (easily) load the whole plugin conditionally, it is possible to stop plugins loading additional stylesheets and the like when you don’t want them. For example, Yoast wrote up how to stop lightbox or thickbox loading when he didn’t want them in this post. For others largely the same principal applies as stylesheets – if this kind of page then do this, otherwise, do this:

Do this regardless.

<?php if ( is_singular() || is_404() || is_search() || is_archive() ) { ?>

But if it's any of the types of pages listed above then do this.

<? } else {} ?>

By doing this you can very quickly get rid of all the stuff you don’t need.

Loading the lot together

That’s all very well, you say, but you’re just creating additional stylesheets for yourself. Not so if you combine them all with the excellent Minify. That way you just have one file, regardless; on certain pages you’d just add the extra stylesheets to the Minified file.

I hope this has enlightened you to the possibilities of reducing the amount of stuff you need to load with each page. Now go and implement!