Experienced users and developers will use the word “template” casually in and around WordPress to mean slightly different things in slightly different contexts. There are four general things that people will be referring to when they say the word, all substantially different. They may be saying “template” when they mean:

1. A raw-HTML file or set or files (usually for sale)
2. A WordPress theme
3. A file in the WordPress template hierarchy
4. A Handlebars, Twig, PHP, etc template file

Each of these usages is good to know of, and to understand in a bit more detail. So let’s get to explaining them.

As a Raw HTML File

For people like me who simply can’t make any design look good, HTML templates are a salvation.

For people like me who simply can’t make any design look good, HTML templates are a salvation. Whatever I’m using to run the site — raw HTML documents I edit, WordPress, or some other CMS or web framework — I can take the (usually sold for money, but sometimes free) template and have something that probably looks about 10x better than I could do.

If you’re working in WordPress, this generally isn’t in play as much because of the next definition. But for people who’ve been around longer, or who aren’t familiar with WordPress, this may well be what they mean by the word “template.”

As another name for a “WordPress Theme”

Folks might not be aware of the WordPress-specific vocabulary of “a WordPress theme.”

As a WordPress developer, designer, or client-services professional this is the usage you’ll hear most coming from non-technical or non-WordPress people: a theme. As we mentioned above, these folks might not be aware of the WordPress-specific vocabulary of “a theme.” But they know that there exists a visuals-focused layer in the system and they call it a “template.” Most frequently people want to save time or money by getting an off-the-shelf “template.” And because the WordPress theme marketplace is enormous, you’ll pick from that with or for them.

The WordPress theme ecosystem, and the fact that people can get a CMS-powered site running with a “template” they bought for much less than $200 is one of the reasons for its enduring popularity. Whatever your disposition to common WordPress themes sold in the market, you’ve got to acknowledge that.

As the files in a theme’s template hierarchy

We’d say that a WordPress theme consists of an array of templates like single.php, archive.php, page.php, etc.

The next big place in a WordPress context that the term “template” may be used is in the context of the “template hierarchy.” If you’re not familiar with it, do make a point of learning it — it’s a foundational part of being skilled at WordPress development, and we published an approachable primer a few weeks ago. The ten-second version is that WordPress themes have a bunch of files, and the template hierarchy is the way the CMS decides which to use to show off a particular bundle of content it fetches based on a URL that a visitor has hit on your site.

The template hierarchy always falls back to your index.php template, but it can also hit a wide variety of others. In this use we’d say that a WordPress theme consists of an array of templates like single.php, archive.php, page.php, etc which are used by WordPress in the template hierarchy. You might or might not include in that classification the files pulled by the get_footer(), get_header(), and get_sidebar() functions: footer.php, header.php, sidebar.php respectively.

In this way of thinking of the term, there are only a few things in your theme that aren’t “templates”: your stylesheet, your JavaScript files, and your PHP function-files. In general: style.css and functions.php, though you can have more from any category.

As a pure template, in either PHP, Twig, etc

“Template” means “a file with a constrained syntax which is processed to make HTML.”

The final use of the word “template” is to mean “a file with a constrained syntax which is processed to make HTML.” This sometimes feels like the least common usage of “template” in the WordPress world, and that’s part of my motivation to write this piece.

What’s really nice about WordPress is that its use of PHP and “template tags” are easy, loose, and forgivingly flexible. That is also a terrible thing about WordPress. If, as a developer, you’re disciplined about what you allow inside of your template hierarchy files so they comply with this meaning, your code stays cleaner and much easier to read and understand. Inside the WordPress ecosystem, though, this discipline is not uniformly present.

I know I’ve written more than ten lines of complex programming logic — a little bit of database querying and foreaching — in template hierarchy files more than a few times to make a little detail work the way I want. And because WordPress template hierarchy members are simple PHP files, that was painless to do. But it was a bad idea for long-term maintenance and sanity.

A Short Argument for Pure Templates

One of the nice things about template languages like Twig, Handlebars, or ERB are that they force projects that use them to be disciplined and clear about a basic dichotomy between behavior and appearance.

PHP as a templating language has merit (it’s where the language started…), but used without discipline it can easily lead to random logic of high-complexity executing in unexpected places, slowing down a site and making all it does very hard to comprehend and reason about.

It can also lead to the opposite symptom: where non-template code randomly creates HTML. When that happens, less-technical people are knee-capped in their quest to quickly go change some markup to make their beautifying of the site easier or possible. Programming functions that generate HTML can be a big bottleneck in collaboration between the front-end team and back-end team of a site. Because of all the unnecessary complexity to alter markup, changes are wanted by people unsure where the markup is coming form, and it can easily lead to visual stagnation. I know that from experience.

One of the nice things about template languages like Twig, Handlebars, or ERB are that they force projects that use them to be disciplined and clear about a basic dichotomy:

• In template files: behavior determined elsewhere is rendered into a browser-viewable format so that people can interact with it. Because the syntax of these languages is limited, the file is generally simple enough that someone uncomfortable with back-end programming is comfortable making simple changes. It’ll show variable values and use them in simple conditionals, but it won’t do any more.
• In non-template files: no HTML can or will be created, only logic about what the system needs to accomplish and readying data to pass to the template files can happen.

This distinction is useful because while these concepts necessarily overlap it’s quite different to think about the creation of new code processes and thinking about the final HTML you want a page to contain. This overlap can make it initially feel like you’re introducing complicating indirection, but history shows that most people think it’s a worthy boundary that I’m always gratified to find a WordPress project is honoring.

Finally, how and when you should use a non-PHP template language in WordPress is a matter for a different time and place. The short answer if this idea intrigues you, though, is to check out Timber. The executive summary is that Timber is a way you can easily use the Twig templating language in your WordPress project. Those constraints can be helpful to make sure you continue to use our last definition of the term “templates.”

What We Learned About Templates

Hopefully we’ve shed some light on the four most-likely-to-be-encountered uses of the word “template” that you’ll come across in WordPress development. I hope, if you already knew all those, you found the discussion of disciplined templating of some merit. It can truly change your (programming) life. Happy hacking!

Image credit: Greg Rakozy