WordPress Theme Development From Scratch – get_template_part()
I’ve written multiple times about the absolute slimmest theme possible, and the minimum theme requirements for the WordPress.org theme repo so I won’t go into the detail of what’s in the those kind of themes again. Instead in this post I will be showing you a way of using the get_template_part() function and how you can use it to display different content types in different layouts and styles using a single loop.
If you want to get right into some demo files I don’t blame you, that’s how I learn best too. The custom loop I’ve got in this post is from the WordPress default theme, Twenty Twelve. Take a look at the code contained within that theme to see how this works in practice. There’s also some content-{post format}.php files defined for you to get inspiration on what information could get highlighted with each post type.
What is get_template_part()?
The get_template_part() function does exactly what you imagine. It includes part of a template within another template. For instance within index.php you could place the following code, borrowed directly from the TwentyTwelve theme.
<?php /* Start the Loop */ ?>
<?php while ( have_posts() ) : the_post(); ?>
<?php get_template_part( ‘content’, get_post_format() ); ?>
<?php endwhile; ?>
The above code actually pulls selectively chosen content for different post formats so we can easily display only what we want for each post format and focus on what’s important to that content type.
It pulls selective content because it makes use of the get_post_format() function to figure out what type of post is being processed by the loop. Combining that with get_template_part() makes for a very powerful default loop.
What the Code Does
Normally within the loop we have code that pulls out a post and it’s metadata to display it in a page. In this version of the loop all of that code is moved into another file, one called content.php. But that’s just the default page, WordPress has some post formats that you can selectively show or remove what you want.
The post formats available to you are listed on WordPress.org as:
- aside – Typically styled without a title. Similar to a Facebook note update.
- gallery – A gallery of images. Post will likely contain a gallery shortcode and will have image attachments.
- link – A link to another site. Themes may wish to use the first <a href=””> tag in the post content as the external link for that post. An alternative approach could be if the post consists only of a URL, then that will be the URL and the title (post_title) will be the name attached to the anchor for it.
- image – A single image. The first <img /> tag in the post could be considered the image. Alternatively, if the post consists only of a URL, that will be the image URL and the title of the post (post_title) will be the title attribute for the image.
- quote – A quotation. Probably will contain a blockquote holding the quote content. Alternatively, the quote may be just the content, with the source/author being the title.
- status – A short status update, similar to a Twitter status update.
- video – A single video. The first <video /> tag or object/embed in the post content could be considered the video. Alternatively, if the post consists only of a URL, that will be the video URL. May also contain the video as an attachment to the post, if video support is enabled on the blog (like via a plugin).
- audio – An audio file. Could be used for Podcasting.
- chat – A chat transcript.
Custom loops depending on post format
Lets take a couple from that list and explain what the above loop actually does. I’ll use status and video posts as examples of how this works.
As the loop is going through your posts let’s say it comes across a post with the post format of ‘status‘. It’s probably a short piece of text and requires no title. So we could make a file called content-status.php and build our loop differently within it to display the content but not the title (and possibly in it’s own little box to make it stand out from the other posts). Sort of the kind of status you would find on social networks.
The next post it comes across is marked as a ‘video‘ post so WordPress will look for content-video.php and use the loop contained within that to build that post. It probably has a post title and some text to describe the video but you’ll want the focus to be on the video rather than the text. So you build the code around how you want to display the video, rather than having to style it directly in the post editor.
Lets say that the next post has the post format ‘audio‘. WordPress will look for the file content-audio.php but we haven’t actually created a custom file for that post format so content-audio.php doesn’t actually exist. What happens then? Well WordPress will fallback to the content.php file which we will have created (because we always build a fallback 🙂 ).
In Conclusion
The get_template_part() function combined with get_post_format() makes for a pretty robust way to display different content types in a way that focuses on what’s important to that content. I’ll be making use of this code within my Theme-Dev framework because it makes for very simple, plugable child themes and that’s sort of what you want with a framework 😉
Next time we look at get_template_part() it will be within the framework. You’ll get to see some practical examples and the demo files that go along with them. The current progress of the Theme-Dev framework can be followed on GitHub.
Good article.
Using get_template_part() like this is a lot cleaner then multiple ifelse statements and a bunch of repeated html in your index.php. The only issue with this method is the potential overhead of all the includes if you are listing more then a couple dozen or so posts on a page.
Very well spotted, Jeff 🙂
The php execution time overhead isn’t generally something you have to worry about with ‘standard’ pages (single loop per page, 10 posts max) but in the case of multiple loops with multiple posts – say for instance a magazine layout – that overhead becomes a very real issue with shared or underpowered (thinking specifically about slow disk access) hosting providers. In those situations conditional statements with their own loop output would be recommended… but you already know that don’t you? 😉
Cache pre-loading can come to the rescue when you make use of lots of templating within theme files but it’s hardly the best solution. Best solution is to minimize includes: but then you use redundant code and increase average file size and you lose the powerful templating functionality…
It’s a conundrum haha