Blog

Streamlining Your Template Structures When Building Themes

November 12, 2018

Cameron Jones

Speaking Engagements, WordPress

Last week I was honoured to speak at the WordPress Brisbane meetup about rethinking our approach to the template hierarchy when building themes. I pitched this presentation for WordCamp Brisbane but unfortunately it didn’t get accepted. As I’d already prepared much of the talk, it made sense to make use of all the preparation I’d already done.

In this talk I presented:

An overview of the theme template hierarchy.
An in-depth look into WordPress actions, filters and template parts.
How to apply this information to building themes that will lead to writing DRYer and more flexible code.

Despite being too technical for a few of the attendees, it seemed to be fairly well received.

Slides

The slides are available to download on SlideShare and Speaker Deck.

Gallery

Photo by Stephen Cronin
Photo by Ricky Blacker

I’d really like to thank everyone who came along, it was quite a technical talk but the feedback I got was really positive even from the less technically minded attendees.

Did you find this post useful?

Cameron Jones

Cameron Jones is a professional Web Developer and DevOps Engineer specialising in all things WordPress, and is the author of the popular Mongoose Page Plugin. When he's not working on a new website or WordPress plugin, he can be found on the sports field or in the mosh pit at a metal concert.

Comments

Mike Schinkel says:

November 12, 2018 at 9:31 pm

Funny, flipping through your slides I was thinking “Looks like you are just recreating a combination of Sage and Genesis.” Then I get to your resources slides and what do I see listed? Genesis and Sage as examples of your approaches “in the wild.” 🙂

That said, after 10+ years working with WordPress I have decided I don’t really like either approach, and I have come to believe the lack of DRY-ness in WordPress themes is actually not a problem. I have learned over too much programming time that not all copied code is equally problematic.

Very common boilerplate code, and especically code where the interfaces to use the code (almost?) never change tends to not actually cause any maintainability problems when repeated.

Contrast that lack of pain with the difficulty that emerges if you need something slightly different than your shared theme render function does not currently support and now you have a much bigger problem, because your theme render function is coupled with all other code that currently uses it, and a change to it might require retesting lots and lots of sites.

That ends up IMO being why WordPress is so much easier to theme than Drupal, or at least v7 of Drupal and earlier as I have never used v8. In older Drupal you got lots of functionality for free, and you ended spending more than 90% of your budgeted time to get the 10% of non-standard functionality you client wants working. The Sage/Genesis approach is much like Drupal <=v7 in that respect.

It is also why it is easier to get a front-end HTML+CSS developer to create that part of the site, and a WordPress+PHP develop to thanks their HTML+CSS and turn it into a theme. If you are a one-person shop, and always will be, this is less of a concern. But if you every will need to work on a team of people who don't have strong WordPress skills, you should be aware of this.

The final thing I don't like about this specific approach as you described it I think it results in organizing theme code in a suboptimal manner. With your hooks you have to find a place to in your directory structure to place your hooks and I suspect that if you have not considered this you could end of with hook functions either in a huge functions.php file, or littered about without much of any structure.

I would propose if you are going to create a template render function that it should also load files functions (and/or class) files based on template you are loading. So that could include these and probably several others (the purpose of these would be to define template tags and/or hooks that are specified by your URL, and to load them as earlier as possible in WordPress bootstrapping process):

– listing-functions.php
– single-functions.php
– post-type-{post_type}-functions.php
– post-type-{post_type}-single-functions.php
– post-type-{post_type}-listing-functions.php

Doing it like the above would make it easier for a developer to understand why to put PHP code that supports a theme, and even more importantly would help other developers know where to look for it.

To be fair, I am not really against building reusable functionality that makes it easier for noob to get started and/or a pro to write (and test) a lot less code on future projects — we actually build all our client projects that way — but I think it is a trade off that those who are making the choice should be aware they are making and ideally cognizant of the pros and cons of each before the commit to one way or the other.

That said, I have to give you kudos for recognizing the patterns and being able to build something reusable like this, especially the use of hooks. I’d say that puts you in at least the top 90% of WordPress developers! 🙂

FWIW.

Reply

Leave a Reply Cancel reply