This is the third concept in a series of blog posts about WordPress concepts for Joomla developers. In this post, I will be talking about the WordPress template hierarchy. As we discussed in the post about themes, WordPress themes only require an index.php file and a style.css file. The index.php file is actually the default page template in a WordPress theme. The theme may also include any number of other page templates that have a file name that follows a specific naming convention supported by WordPress. These templates make up the WordPress template hierarchy.
Joomla Template Overrides
Back in the dark ages of Joomla 1.0, the concept of template overrides didn't exist in Joomla. This meant that you were stuck with whatever output components and modules gave you, and the only way you could control how the page rendered was with CSS. Joomla 1.5 introduced the MVC framework and the concept of template overrides. With template overrides, you could finally have (almost) complete control over the HTML output coming from Joomla and its extensions. Gone were the days of being stuck with the default output.
The WordPress template hierarchy is WordPress's version of Joomla's template overrides. It gives the theme developer complete control over the HTML output of different types of content. The big difference between the template hierarchy and Joomla template overrides lies in the differences between the content data models of each system.
Content Data Models
In Joomla, the core functionality of any given page centers around the component. The core content component is just one of many components, and its data model is just one of many data models used to store and manage content in Joomla. For example, an event management component would likely have its own tables in the database with its own data architecture for storing and managing event data. The component typically wouldn't store its data in the #__content table, but would have its own table for storing events. As such, the events component has its own set of views and layouts for rendering events in the browser.
WordPress, on the other hand, has a more unified content model. Everything centers around the #__posts table (Note, WordPress doesn't use #_ to represent the table prefix. I'm just using it here for consistency with Joomla's prefix indicator.). So, a third party events plugin in WordPress typically would not have its own table for storing core event data, but rather would register an "event" content type to be stored in the posts table along with meta data about each event in the core #__postmeta table, which is a key/value store for saving any type of relavent data you may need. I'll cover content types in another post, so I won't dive too much deeper into that concept here. Because all of the different types of content are generally stored in the same set of tables, all of the content types can usually be rendered with the same templates.
WordPress templates
The default template in any theme is the index.php file. It can be used to render any type of content in WordPress, assuming the content types are defined properly with a plugin that follows standard practices. It's used to display a list or archive of posts like a blog, a single article or page, the home page, a 404 error page, and even a search results page. Because all of these things follow consistent pattern, this one file can be used to render them all.
As you can imagine, having a single template to render this many different types of content doesn't leave room for much flexibility. That's where the template hierarchy comes in. For example, if you want to display an archive of content items, there are a number of options available to you. The next level in the hierarchy for archive pages is a file named archive.php. This will be used to render archive pages instead of index.php if it exists.
You can go a few levels deeper depending on the type of archive you want to display. For example, if you want to display an archive from a taxonomy (category, tag, etc.), you could do that with a file named taxonomy.php, which overrides archive.php for any type of taxonomy. For a specific taxonomy type (like "category", for example), you could use a file named taxonomy-category.php, which overrides taxonomy.php for that specific type of taxonomy. For a specific category (let's call it "sports"), you could use a file named taxonomy-category-sports.php, which would override taxonomy-category.php.
Rather than go through all of the different levels in the template hierarchy, I'll just give you this link, which is an invaluable resource for anyone trying to wrap their heads around WordPress themes and the template hierarchy: https://wphierarchy.com/.
Conclusion and What's Next?
Once you understand the WordPress template hierarchy, you are 90% of the way to becoming a WordPress theme developer. As a Joomla developer who is used to having template overrides in the template's /html folder, I found it really frustrating trying to figure out custom overrides for different types of output. Once I figured out the template hierarchy, I really started to understand how WordPress themes are structured, and it made me a much better WordPress theme developer.
So far, we've talked about themes, sidebars and widgets, and the WordPress template hierarchy. Next, we'll talk about WordPress functions and Joomla's MVC structure, which is another huge step towards understanding WordPress development. Thanks for reading!
If you are looking for a skilled Joomla developer or WordPress developer for your next project, drop me a line and let's talk.
