Redefining the template hierarchy in Hybrid 0.7

One of the things I’ve always liked and disliked equally in WordPress is its templating system. I love how easy it is to just create templates for all sorts of things. I dislike the hierarchy.

Don’t get me wrong — the hierarchy works for most sites.

But, when it comes to highly-customized sites with loads of content and many pages and archives that need different functionality, things can get a bit messy and unorganized.

The new template hierarchy

In Hybrid version 0.7, there’ll be a slightly different logic behind the templating system. I neither wanted to go completely overboard nor confuse people too much, so much of it is based off the old template hierarchy.

This isn’t quite the future I have in mind for a complete reworking of the WordPress template hierarchy, but I believe it’s a step in the right direction. And, that step is about adding structure. There are some things that need to change internally in WordPress for me to have the system I really want.

Template hierarchy in Hybrid 0.7
Template hierarchy in Hybrid 0.7

You can also take a look at the default WordPress template hierarchy and compare the two.

What’s different?

A good bit of it retains the default WordPress hierarchy, but a few things have been reworked. Here’s some of the major changes:

  • All taxonomies (including tags and categories) use the same template naming system.
  • Got rid of single.php for singular posts in preparation of custom post types, so all singular views will be in line with one another.
  • Singular posts will now recognize custom post templates.
  • All attachment templates begin with attachment, so they’ll be recognizable as attachment templates.
  • Author templates begin with user as opposed to author since all registered users are given an “archive” page on the site whether they’ve written posts or not.
  • Date and time archives are broken down into the specific date/time rather than just using the date.php template.

Why the change?

For those of you that run a regular blog, you could probably get away with only having an index.php template. But, in my experience working on some larger-scale projects (and I’m sure others will agree), there’s often a need for a lot of customization when specific types of pages are shown.

Rather than having to recode the same functions over and over for those projects, Hybrid will make that job easier by breaking down the templating system based on context. So, if you ever need a new template for a specific page of the site, all you have to do is build it rather than jumping through hoops just to use it.

There’s still some work to be done to have a better organizational structure, but I’ll save those ideas for another day.

What do you think?

This is something I’ve been discussing on and off for a while in the Ideas forum, but I wanted to open this up to a larger audience here on the blog.

Do you like this new hierarchy compared to the old one? What would you like to see changed?


  1. Paul

    After a quick look at the template hierachy above, I have a feeling that it should become wordpress standard soon.

    The template hierachy that wordpress currently uses is very difficult to fit in most of the custom project, it’s like we have to dig in and mess with conditional loop everytime.

    So I hope hybrid’s system will simplify the process here.

  2. I definitely agree that the default templating system could use some reworking. For the most part it hasn’t changed since the beginning (when the vision for WordPress only including blogging). Now that WP has expanded as much as it has the structure of the system as well as the naming conventions should reflect that of a much more flexible CMS.

    For now, I can’t think of any more ways to improve upon your design.

  3. Robert

    This is definitely a step in a good direction. I’m working on projects that will require exactly this sort of templating capability as there will be different post types and archive requirements.

    I don’t see the category in your diagram so I’ll assume there is no change to that approach.

    I reckon that taxonomies will play an important role so any enhancements around the way we can display them and especially filter data using taxonomies will be very useful.

    1. Categories and tags will use the taxonomy hierarchy like all other taxonomies. One of my gripes with the current system is that it uses category.php and tag.php when all other taxonomies use taxonomy-$tax_name.php.

  4. Don’t quite understand it all yet (category and taxonomy interchangeability), but being able to use post and page templates this way will help me. I have at least two post types in my project other than traditional posts. Great work.

    1. Categories are just another taxonomy, so they’ll use the same system as all other taxonomies.

  5. Ed Nailor

    Just getting started with Hybrid, and from what I have seen I am blown away. My question, just getting started, is will this make any major changes to a current setup when you upgrade to 0.7 upon final release? I don’t want to go through learning how to customize my new hybrid theme (plan to use hybrid-news) just to have to relearn things again.

    1. This won’t make any major changes. The only thing you might be doing now is creating custom cat-$id.php or tag-$slug.php templates. If this is the case, you’d merely need to make a copy of the template with the new naming system. For the most part, everything else is new or doesn’t really apply to child theme developers as much as it would be to folks that are eager to use the upcoming framework in their own themes.

  6. Justin,

    I am learning CSS, WordPress and ThemeHybrid, while I am building a somewhat complex e-commerce site. This sounds like just what I need.

    I also have same question as Ed – don’t want to have to learn and build this twice.

    Thanks for the great system you’ve developed.


    1. Ditto on what I just wrote to Ed. This shouldn’t cause many problems.

  7. Thanks Justin – glad to know it won’t be a problem. But I’m confused about this statement:
    “everything else is new or doesn’t really apply to child theme developers as much as it would be to folks that are eager to use the upcoming framework in their own themes.”
    Please pardon my novice ignorance, but I thought Hybrid was already basically a framework that you are, in a sense, just formalizing with Hybrid .7, right? Or am I misunderstanding (wouldn’t surprise me) your post on “What’s in store for Hybrid 0.7?”

    The reason for this sort of question is to determine the best way to use what you have provided. My desire (and current work, actually) is to build sites based on your excellent Hybrid foundation that are a unique presentation specifically for my businesses and clients. I would like to understand if I should be using Hybrid alone or with Skeleton to create child themes, or use the framework. I have looked at other frameworks, and believe your approach to be the most solid and well-considered – the safest and most stable one to use.

    Thanks for your help!


    1. There’s the “Hybrid framework” and the “Hybrid theme.” I’ll have a post that explains the differences soon. The framework isn’t available for public consumption yet, but I’m hoping to release it at some point in the near future.

      For the most part, we’re only worried about the theme here. The core framework is being developed for developers like myself to make parent themes like Hybrid.

  8. The page/post/attachment-template.php ones confuse me – they seem to override the more specific ones we could use for a post (with the slug, ID, etc.) but I’m not sure why?

    Other than that, it looks fantastically adaptable!


    1. Basically, it’s just an override hierarchy. Sometimes, we need the ability to make a certain post function differently than other posts. That’s where more specific templates come into play. Most people will never need this functionality, but I’ve been involved in several larger projects that need many custom templates for posts.

      1. In reply to Justin Tadlock

        I understood the overrode heirachy, it’s the part where it looks like attachment-template.php would override attachment-slug.php or attachment-id.php (ditto for post/page) that confused me. I’d think the slug/ID ones should be the most specific and therefore override any less specific ones like the tag/category/general templates for attachments/posts/pages.

        Graphically, I don’t understand the three to the extreme left of the is_page(), is_single(), and is_attachment() lines.


      2. In reply to Justin Tadlock

        The term “template” in those instances mean custom. For example, you can create a custom page-authors.php template and use it for any page. So, when a user specifically chooses to use a custom template from the admin, they mean it. This is how it’s currently done in WordPress for pages. I’m just adding that functionality to posts and attachments as well.

        The hierarchy actually looks more like this:


      3. In reply to Justin Tadlock

        Ahhhh, that makes sense. I was somehow interpreting “page-template.php” literally instead of in the sense it was intended. Makes sense now, and WONDERFUL sense.


  9. By the way Justin, Why don’t you like nested comments? By default none of your themes support nested comments. Hope you can add that feature next time without adding any additional code by end-user.

    1. All of the themes here already support nested comments by default.

      1. In reply to Justin Tadlock

        oops, I forgot to activate it in the wordpress options…. Your themes are really great and nice and your forums are really awesome. Thank you for giving this awesome Hybrid theme for free. Thank you Justin.

Comments are closed.