Posts Tagged: WordPress

Which template — an essential theme development function

So you’re developing a theme for a new project that you’re working on. It has lots of queries, a few different content types, a custom taxonomy or two, etc… It can often be difficult to determine what template is generating the page you’re looking at on the screen. Is this page using page.php, page-{slug}.php, single.php, taxonomy-{taxonomy}-{slug}.php ? You get the idea.

I use this function on every single site I develop, but don’t often see it being used out there in the wild. Just pop this function into your functions.php file and it will output the current template file being used to the bottom of your page:

/**
 * Print out the current template file to the footer.
 * Remove before launch. 
 *
 */

function waterstreetgm_which_template() {
	if ( is_super_admin() ) {
		global $template;
		echo '<strong>Template file:</strong>';
		print_r( $template );
	}
}
add_action( 'wp_footer', 'waterstreetgm_which_template' );

Bones and Underscores— a WordPress theme head-to-head

Update: I’ve finally finished the follow-up post. Read the update when you’re all done here!

I have a big week coming up. I’m starting two brand new projects and I’m pitting two top WordPress starter themes against each other in a battle royale:

Underscores

First up, we have Underscores from the Theme Team at Automattic. It is very clean and stripped down, and truly satisfies the ‘starter theme’ criteria. It comes with the barest of necessities, but leaves nothing out at the same time. For you old-schoolers out there, you might notice that a lot of Underscores looks very similar to Toolbox, it’s predecessor. In short: Toolbox was a good starting point for developing themes and Underscores is a great one. Let’s have some pros and cons:

Pros:

  • Underscores is familiar. This is really only important to me, but it still matters. I used Toolbox on a lot of projects, and still use my fork of it—Victoria Park—for lots of things today. I used Underscores a few times in the past few months and it really feels like an updated version of what I already like.
  • Underscores uses the get_template_part pattern for abstracting template files. I really like this way of thinking about templates.
  • Aesthetics matter and the website for the project is great.

Cons:

  • Doesn’t use LESS or SASS. This is such an easy issue to fix (rename style.css > style.less and have LiveReload watch the folder) that it hardly warrants a bullet point, but it’s an important distinction from the direction Bones has chosen to take.
  • The name. I’ve never really liked the name ‘_s‘, which is an extremely unimportant detail until you go to start a project and have to find and replace all instances of ‘_s’ with ‘my_project_name’. Again, it’s absolutely not a huge deal, but it was a bit of a pain. The pain is now pretty-well completely alleviated by the project’s website—you can now just enter the name of the project and all the finding and replacing will be cleverly done for you.
  • Not responsive. I know, I know. You shouldn’t let a project’s boilerplate dictate your media query breakpoints, etc etc…and its something you can (should?) easily add yourself, but I still wish there were a few breakpoints baked in.
  • Eric Meyer’s style reset. This one would have been so insignificant a few years ago, but really drives me crazy now. If you’ve ever inspected a single element in Chrome dev tools or Firebug, you’ll know why. Meyer’s style reset, fills your inspector window thusly every time you click on an element:

    This clutter will show up for every single element you inspect. It’s not a huge deal, and you can remove the style reset and roll your own, but I still wish it wasn’t there to begin with.
  • Too spartan out of the box. I’ve always found Toolbox and Underscores to be way too spartan from the outset:
    While I understand that this is meant to be just a starting point, I still don’t find it warm and cosy when I start a new project.

Bones

Bones is a hot new theme from Eddie Machado. It’s much more opinionated than Underscores and comes with a few more things under the hood. Before we weigh out the benefits, I need to disclaim up front that I’ve not yet used Bones for a project, so all of the opinions below are just wild speculation. But let’s do it anyway:

Pros:

  • Responsive. Bones has a responsive grid baked right in
  • Looks good from the get-go Bones isn’t spartan from the start. It has a basic layout ready for you, and overall feels a little better than Underscores does. Sure, you’re still going to undo all of these starting points (the pink headings, etc) but it still feels better to me to start with something out of the box:
  • Normalize.css. If you’ve never used Normalize.css from Nicolas Gallagher and Jonathan Neal it’s worth a look. It does the job of resetting quite well, without cluttering up your inspector window.
  • LESS/SASS from the start. Here’s where the opinionated part comes in. I love that Bones insists that you should be using a CSS pre-processor (and you should) and makes the two most common options available to you
  • Verbose documentation. Some might find this level of documentation to be overkill, but I think it’s going to be helpful to leave it in for at least the first few projects. Machado crams a lot of WordPress know-how into each and every line.

Cons

This is the part where the comparision goes off the rails a bit. Given that this is really a setup post and not a followup, and that I’ve not actually used Bones yet, I can only list a few cons that come to mind when poking through the project’s files and folders

  • Modernizr. I don’t use modernizer. At the moment, it feels like this will add unneeded overhead for me. I have no idea. I might use Modernizr for every project henceforth, but for now it feels like it might get in the way
  • No get_template_part. Bones doesn’t use the get_template_part pattern, instead loading a lot of functionality into index.php. This doesn’t mean that I can’t do things the way I like, but is still not ideal for me.
  • Bones is opinionated. I’m not actually sure yet if this is a pro or a con. Opinionated code is great for beginners and people who have the same ingrained opinions. It will be interesting to see if my Machado and I do things the same way. It will be very interesting to see if I come around to his way of thinking if we don’t!

So there we have it. Underscores and Bones in a tête-à-tête. Results to follow!

Tighter and leaner WordPress templates with get_template_part()

Update: This article is a little dated now. As of a few months ago, I’ve stopped using Victoria Park and now use a fork of Underscores from Automattic. I’d recommend starting there. That said, everything else in the article still applies!

I use Victoria Park, a very slightly modified fork of Automattic’s Toolbox, for all of my projects. But every now and then when starting something new, I’ll go shopping around for a theme that’s custom-built for the task at hand. If I’m making a portfolio site, or a knowledge base, for example, I’ll often look to see if there’s a ready-made solution out there, rather than starting from scratch.

A lot of the themes I find out there seem like they’re ready to just drop into place, but so far, at least for me, they’ve always been fool’s gold.

Using something other than your tried-and-tested base theme is a bit like cooking in someone else’s kitchen. Sure, things will get cooked, and the meal will most likely turn out just fine, but it won’t be the same. You won’t find the same frying pans you’re used to, the stove will be different, the cutting board too small, the knives not sharp, etc. Cooking in someone else’s kitchen just won’t feel natural to you, and neither will using someone else’s WordPress theme.

Pots, pans and knifes, all your own

I’ve directed lots of people to Toolbox and its successor _s. I’m still using Toolbox at the moment, but plan to take _s for a spin on my next project. The two are very similar and _s looks on the surface to add nice, minimal enhancements to an already good theme.

Even if you don’t fully adopt these themes as your own starting point, I will recommend (encourage? implore?) that you follow Automattic’s lead in these few important ways:

1. No more loop.php

For too long, loop.php was a melting-pot for a huge pile of logic and conditionals that made modifying it a chore. Ten lines of code that say, “if the user is logged in, and not in the admin area, and not looking at a blog post, and not didn’t have a sandwich for lunch, then show them this content”, make things hard to read and modify. There’s a better way to naturally abstract that logic away. WordPress already knows about and expects files like single.php, page.php, front-page.php, etc, so references to them don’t need to be coded into a loop.php file. There’s no need for conditionals like is_single(), or is_front(), for example, because these already have their own template files. Any code you put in front-page.php or single.php will be picked up automatically, no need for conditionals.

2. Start with a good index.php file.

index.php is usually your first port of call. This is where you want your loop. Like so:

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

	<?php
		get_template_part( 'content', get_post_format() );
	?>

<?php endwhile; ?>

Looks simple enough, but there’s a small bit of magic in there. For a good description of this magic, please see item 3, below.

3. get_template_part()—the heart of your theme.

Though not a huge, or terribly powerful function, get_template_part() has become a core part of all of my themes. get_template_part() is more than a function, it’s a way of thinking about structuring your themes. Instead of including the markup for your blog posts, asides, or galleries directly inside index.php (or formerly loop.php), leading to huge, unreadable files, you include their contents in a separate file: content-{post-type}.php. An example will clear things up.

Imagine trying to have different markup in a standard blog post and an aside, where you remove the title, tags, and category:

To achieve this, an old loop file might look like this (I’ll write this in English instead of PHP, for understandability):

while ( have_posts() ) : the_post();

if post-type = 'aside'
	<article>
		.....content...
	</article>
	<footer> The date, the tags, etc </footer>

if post-type = 'blog post'
	<article>
		<h2>Post title</h2>
		.....content...
	</article>
	<footer> The date, the tags, etc </footer>

if post-type = 'gallery'
	<article>
		<h2>Post title</h2>
		.....content.....
		.....the gallery.....
	</article>
	<footer> The date, the tags, etc </footer>

While your shiny, new index file will be much simplified. Containing just this tiny loop:

while ( have_posts() ) : the_post();

get_template_part( 'content', get_post_format() );

Using this example, WordPress will still loop through all of your posts, but it will examine each one to see what post format it has (aside, image, article, gallery, link, etc). Each time, it will go looking for a corresponding content file:

content.php
content-aside.php
content-article.php
content-gallery.php
content-image.php

Now, all of your template code is neatly abstracted into individual files. You know, for example, that you don’t want to have titles on aside posts, so to get rid of them, just delete the post title from content-aside.php.

The obvious next question you might have is, what if I don’t have a template file for each post type I have? The beauty of this method, is that you don’t need one. If you want asides to look just like blog posts, then don’t have a content-aside.php file. WordPress will simply look for it, not find it, and serve the plain content.php instead. The only file you need is content.php—you’ll only need the others if/when you want that post type to look different.

This all probably sounds a bit like we’re splitting hairs. What’s the difference between having one really long file and having a bunch of really small files? It might not make much difference to you at all, but it makes a big difference to me. As I keep adding more and more post types, including more and more custom post types (outside the standard ones: aside, gallery, links, etc), using this get_template_part() pattern becomes really useful. Instead of scrolling through potentially hundreds of lines of template code, you now just need determine the post type and find its corresponding content-{post-type}.php file.

To sum up

Have a look at _s to see how this is done, or have a look at Victoria Park to see how I do it. My rule of thumb is, whenever I’m doing something like adding/removing a post tile, or post tags/categories, or the date, or otherwise changing a post’s markup in any way, I make sure I’m doing it in a content-{post-format}.php file instead of in index.php or loop.php. Note, of course, that this works just as well for custom post types as for the different post formats. Just put your custom post type content in: content-{my-custom-post-type}.php

This is an excellent habit to get into and will lead to much more readable, maintainable and sharable themes.

A beginners guide to caching in WordPress

Running WordPress? On shared hosting? Does the word caching make you nervous? Well worry no more. Here’s your beginner’s guide to caching in WordPress in just three easy steps:

  1. Install Quick Cache. Since succeeded by Comet Cache.
  2. Enable Quick[Comet] Cache
  3. Keep refreshing different pages, marvelling at how fast your site is now

And that’s it folks. I’ve installed Quick Cache on most of my sites in the past month or so and it does make a substantial difference to page load times. Enjoy!

Why I switched to WordPress

One of the 500 reasons why I switched to WordPress from Drupal lies below. If you’re reading this as a non-coder, please simply understand that this markup is absolutely heinous, overcomplicated and completely unnecessary.

<!-- main row: width = grid_width -->
<div id="main-wrapper" class="main-wrapper full-width">
<div id="main" class="main row grid16-16">
 <div id="main-inner" class="main-inner inner clearfix">

 <!-- main group: width = grid_width - sidebar_first_width -->
 <div id="main-group" class="main-group row nested grid16-16">
 <div id="main-group-inner" class="main-group-inner inner">

   <div id="main-content" class="main-content row nested">
   <div id="main-content-inner" class="main-content-inner inner">
   <!-- content group: width = grid_width - (sidebar_first_width + sidebar_last_width) -->
   <div id="content-group" class="content-group row nested grid16-11">
   <div id="content-group-inner" class="content-group-inner inner">

     <div id="content-region" class="content-region row nested">
     <div id="content-region-inner" class="content-region-inner inner">
     <a name="main-content-area" id="main-content-area"></a>
     <div id="content-inner" class="content-inner block">
       <div id="content-inner-inner" class="content-inner-inner inner">

       <h1 class="title">Front Page</h1>

       <div id="content-content" class="content-content">

For the sake of context, and humour, the same markup in WordPress could easily look like this:

	<div id="main">
	 <div id="content"> 

       <h1 class="title">Front Page</h1>

ht to @ncbeets for reminding me of exactly how happy I am with WordPress.

(re)Launched: Matthew Byrne

After a few weeks of planning, photographing and coding, Matthew and I launched his new site this week.

Built with WordPress, the wonderfully extendable HTML5 theme, Toolbox from Automattic, and featuring  Backstretch, a jQuery plugin from Scott Robbin, to make the backgrounds flex and stretch across the screen.

The site has already been picked up by Design Fridge and The Best Designs. Lets just hope some of the flood of new visitors are music fans!

A Primer for WordPress’ query_posts()

I’ve probably looked up code examples for query_posts() more than anything else in the whole Codex. I need to commit a basic example for myself, and in the hope that it will benefit others trying to do this basic, basic thing.

Here goes:

<?php
     $args = array(
                   'cat' => '44',
                   'post_type' => 'post',
                   'posts_per_page' => 15,
                   'paged' => ( get_query_var('paged') ? get_query_var('paged') : 1),
                   );

    query_posts($args);
	
	while (have_posts()) : the_post();
		get_template_part( 'content'); 
	
	endwhile;
	?>

This basic query will go find the last 15 posts in category 11. Just as easy as that. There’s a bunch of other filters you can append to the query or add to the query array: cat=11&year=2009&tag=design to bring back all articles tagged with design in category 11 that were written in the days of yore (2009).

Paste this code into your template files (with surrounding PHP tags) for a quick way to show your posts on a page, on a footer or sidebar, or wherever else you want.