Templates in WordPress is a topic that seems to come up for discussion every now and again. There are plugins aiming to make it possible, too. And though I’m intrigued by the idea, I’ve yet to go all in on it.

Timber for Templates in WordPress

That’s a topic of discussion for another post, though.

Over the last few years of writing plugins for others, one of the things I’ve found to be one of the easiest things to do is to separate our views into partials.

Templates in WordPress Administration

I know: This is borrowing terminology from generic design patterns as well as theme development. I’m not sure of what other terms to use (and it doesn’t really matter as it’s more about the concepts).

But hear me out.


I define views as the markup that renders administration pages in WordPress. These may be thought of as templates, as screens, like pages, or something else.

I know that WordPress calls them “pages”, but that overloads the term with something in the administration area and something that users create.

If you were to take a view and separate it into individual files, then each file would represent a partial. Then, include each partial in the main view file through PHP include statements.

Ultimately, my directory structure for the administration area of a plugin would include an admin directory with a single file used to represent the main screen and then a partials subdirectory that contains a file for each section.

Improving Maintenance

There’s something to be said for having all markup in a single file, but settings pages often include:

  • multiple sections,
  • nonce values for security,
  • function calls to the WordPress API,
  • function calls relative to the plugin.

And when you’re dealing with something like this, things can become hard to maintain over time especially when you’re looking to trace a particular function call, bug, feature, or piece of functionality.

Secondly, if you mix a lot of your PHP with your HTML – something I’m not fond of doing – then your views will be teetering on spaghetti code. It will be visually noisy if nothing else. Keeping files like this as focused and lean as possible goes a long way in maintaining the code after release.

Keeping files like this as focused and lean as possible goes a long way in maintaining the code after it ships. And though I’m a fan of keeping functions in PHP files and making calls to them from within the views, at least separating sections will help to maintain a relatively clear conceptual model of how the functionality works.

To Each Their Own?

When talking about program design, architecture, and organization, it’s easy to share opinions and thoughts on the topic and then conclude with “but this is what works for me and to each his or her own.”

And sometimes that’s true. I know I’ve done that on previous articles.

But when it comes to organizing a plugin, making sure it’s maintainable and that the architecture resembles how the plugin functions is essential. In this instance, this particular organization is one in which I’d be hard-pressed to change as it’s driven by experience of writing, inheriting, and maintaining plugins.


Join the conversation! 4 Comments

  1. I’ve been experimenting with something like this. I try to create PHP template files that are just for HTML generation. There are no functions. Just HTML and some display logic (like in Twig).

    I mean we forget that PHP is also a templating language. There’s no reason you can’t just use it as such. And that’s even just for generating HTML in strings. You can use output buffers to generate HTML from a template and store it in a string.

  2. I appreciate this and your other recent related posts, Tom. I’ve been working on developing a patterns library for my employer as a way for us to quickly pull in and use various partials (I call them modules, because they’re self-contained blocks of data, presentation, and interactions), and I have yet to feel completely satisfied with how things are structured.

    Like Carl, I have a set of files that each represent a single block, with markup and method calls to the module class that output the module’s data. The data model lives in a plugin that registers a set of actions (generally, one for each module), and the classes themselves both extend an abstract class that allows you to assign requirements for the module to render, and they also use PHP traits so modules can share some of the commonalities between them (for example, getting or rendering a heading). I use the created actions to output the markup, which helps prevent the possibility of inadvertently displaying or logging PHP errors should the plugin get deactivated for some reason.

    Lastly, my plugin contains a directory with all of my partials, and these can be overridden directly in the theme, so if a theme developer needs to write custom markup but still wants to access the data model during the rendering process, they can.

    It’s not a perfect approach, but it’s something that’s seeming to come together nicely, and it’s making development in future client projects go a little more smoothly. I’m hoping to have this refined enough to put up a repo on Github at some point so others can take a look and provide feedback. I’ll give you a heads up when I do.

  3. Hey Tom,

    I use the concept of Views a lot in my code. I built a reusable library to deal with this (https://github.com/brightnucleus/view), and I will now slowly convert all my other packages to use that library (like the shortcodes package).

    I basically can now point that library to folders containing views, and tell it to render whatever view. The library than deals with different formats, and you can easily add additional engines to support Twig, Blade, whatever.

    I have found myself not only using views for HTML, but for whatever “markup” or “rendering” I need, where the logic has already been dealt with. So, a View can represent a HTML page, a form field, a set of render settings (in JSON) to pass to a JS script, a CLI tool help page, a tooltip text, … Just general “stuff that needs output”. Whenever I have one of these elements, I need to think much about how to deal with it, I just pass it through my View library.

  4. Yes, I’ve gone a step farther with this to write an abstract class to bootstrap my plugins, and then autoload the classes for the plugin and define specific classes for public and admin. Then load the UIs based on admin menu pages or shortcodes.

    It works really well, and I only inject one var name into the WP scope.

Leave a Reply