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.

Terminology

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.