When I first started thinking about templating in WordPress, I thought about regarding two aspects:

  1. content specifically for members,
  2. content that could break down into a single post.

But the more I thought about it, the more I realized that it could (and arguably should) be explained over the course of a few posts.

So I’m going be breaking down the current state of WordPress templating and then practical ways we can take organize, say, our plugins so that we’re using standard PHP.

After that, in a future series, I’ll look at what it means to use other templating engines (both PHP and JavaScript in the work we do).

For starts, though, I want to take a look how we often see templates written within the context of both WordPress themes and plugins.

WordPress Templates for Beginners

Depending on your experience with WordPress and other PHP-based systems, your definition of templating be different than someone else’s.

So to try to create a common definition that I’ll be using throughout this series of posts will be used from the WordPress Codex:

Templates are the files which control how your WordPress site will be displayed on the Web.

The page goes on to talk about how it works in conjunction with the database and other assets, and I recommend reading about it if you’re not familiar with it.

However, the definition above works well for how I plan to move forward thinking about it.

1. How It Is (Right Now)

When it comes to thinking about WordPress templates, I think it helps to consider a single template that with code that looks something like this:

The point of the code above is that you see is that it mixes PHP and HTML.

Furthermore, it’s important to note that each of these files is styled using CSS and may have additional behavior controlled via JavaScript. To that end, you may conceptualize it like this:

WordPress Templates for Beginners: How It Is

This represents a single template mixing both HTML and PHP into a single template. And that template is then styled with CSS and controlled with JavaScript.

All of these work in conjunction together to provide what it is that the user sees.

2. Does Developer Organization Beget Performance?

But the way that this works is kind of messy, and although it may look good for the user, it raises some questions:

  • Is it as performant as it could be?
  • How easy is it for a developer to maintain?
  • What’s the build process?
  • how are the assets maintained and organized?

Sure, most of what you’re reading above is very developer-centric, but I find that when a code is organized in such a way that it’s easy for developers to work with it can often be easy even faster for the user.

What does that mean, though?

  • Do we introduce Sass?
  • Do we minify JavaScript?
  • How do we combine these assets and import them?
  • What about the custom PHP queries that happen within the context of each template?

And though the first things are important and worth it (and I may cover in a series after this), separating logic from within a template even without a templating engine can help make the code more developer-centric.

Does it make things faster for the user? Not necessarily. But it does help us take the first step in doing just that.

Let’s Get Re-Organized

In the next post in this series, I’ll break down content we’re used to seeing in WordPress templates through an example and start re-organizing it so that it’s better organized in such a way the techniques can be used in different projects.

This means moving things into their functions (or even within their classes and thus their functions) and how we can call them from within the context of our templates.

Ultimately, this will lead to code that’s easier to read, better separation of concerns, and move us toward ways of changing how data is injected into a template.