Thoughts on Design Patterns in WordPress

Whenever the topic of talking about using WordPress as a foundation for web applications comes up, I always get mixed reactions. That is, I’ll hear anything from how that’s a silly idea to how a person wants to know more (as well as everything in between).

One of the more common things that I hear developers often try to do is to retrofit the MVC pattern around WordPress in order to try to make sense of how existing themes, plugins, and applications work, as well as how they can take advantage of MVC to produce their application.

Don’t do that!

WordPress doesn’t use MVC. It uses the event-driven design pattern. But for whatever reason, this doesn’t stop us from trying to wrap MVC around WordPress. When it comes to design patterns in WordPress, there are other approaches.

There are reasons for why I think this is a relatively common trend, but there are alternative ways to approach development on WordPress, as well.

Design Patterns in WordPress (And Other Software)

When I was thinking through the content of this post, I debated whether or not it was even worth discussing because I’m not sure how much the content of the post really matters. Then again, this is something that I’ve discussed at length with enough people that I think it’s at least worth sharing some thoughts on it.

I’ve written much more about WordPress, its use of design patterns, and MVC in much more detail in another post – this isn’t an attempt to cover that material again. Instead, this is more of a random set of thoughts or notes that I’ve made over the last few weeks when discussing this topics with others.

1. Meet MVC, the Golden Child of Web App Design

When I first discovered Rails, I absolutely loved MVC. I believe that it was my first encounter with this design pattern in a web application framework and it clicked really fast. That is, I felt as if MVC represented how I had conceptualized building web applications.

In a way, it just sort of worked. A place for everything (and everything in its place), if you will.

But the more work I did in software development, the more my thinking began to shift. Sure, I still like MVC and I still have a conceptual model for how a web application can be structured, but that conceptual model isn’t limited to just MVC.

There are a lot of frameworks that are out there today that employ MVC or some variation thereof (like MVVM). And I think that’s awesome. Again, the pattern is great, it fits web development like a glove, and it just makes sense as it relates to the model of having a database, middleware, and a presentation layer.

It’s not the only pattern, though.

Anyone who has written medium-to-large scale software with a team likely knows a number of different patterns, and you know that MVC is but one in a collection of many, many patterns.

To that end, there are other ways in which web applications can be built. This is not to say one pattern is better than the other – this is to say that there are some viable alternatives to what is thrown out.

2. Meet Hook, the Red-Headed Step Child of Web Apps

If you’ve read any of my previous articles – or anyone else’s articles – on the pattern employed by WordPress, then you know that it uses hooks in order to make it possible to customize the flow of control throughout the application.

Specifically, WordPress uses the event-driven design pattern. This means that it defines certain points throughout its execution where we can hook into it, grab control of the process, do what we need to do, and return control back to the core application.

These points at which we can insert our code into WordPress’ lifecycle are known as hooks and they come in the flavor of actions and filters (of which you can read more about here). In short, we have the ability to append code to existing points of execution.

Additionally, hooks can be removed so that, say, if an action has been defined, you can remove the hook from the lifecycle so that it never fires or you can replace it with a custom hook of your own.

If this is your first time time coming across something like this, it’s kind of neat isn’t it? On the other hand, if this is something that you’ve known for a while, then this entire article is likely of no interest to you.

This still raises the question of how does this stack up against other design patterns, specifically MVC?

It’S Not Either/Or

When it comes to software development, programmers are notorious for having arguments of religious proportions about the tools they use, the methodologies they employ, and the languages they like (and dislike).

Many times, discussions become far more about trying to convince other people why they are wrong or even incompetent if they opt to use a different set of tools than what you may like.

And that’s sad and immature, but it is par for the course of the industry. No, not every programmer is like this, but there are enough threads on numerous blog posts, Hacker News threads, and/or Reddit threads to back up this claim.

At some point, I’d like to believe that we, as programmers, stop seeing things as black and white and start realizing there’s a lot of gray area in programming. There are tradeoffs for nearly every decision that is made and given that design patterns are a subset of programming, the same is true about them.

So if you’re someone who is trying to reduce everything about programming and anything that’s tangentially related into this mentality of “it’s either this way or it’s that way, but one is better than the other, and we’re not using the latter!” then I’d argue that there’s a lack of maturity in your perspective as it relates to software.

An Example of Models and Presentation

So anyway, let’s say that you’re someone who’s coming to WordPress from an MVC background and you’re trying to wrap your head around certain aspects of how the application performs certain actions.

Case in point: One of the things that I’m asked is how to conceptualize templates. That is, “Are they views? Do they have access to business logic? Are they tightly coupled to the business layer?” and so on.

The best way that I’ve been able to demonstrate templates within the context of WordPress in comparison to MVC is that templates are kind of like model-view hybrids. That is to say that, yes, they are responsible for formatting the information that’s retrieved from the database, but they also have the ability to call into the application layer to retrieve more information.

Even more so, you can call directly into the database from a template. That’s terrible architecture, and I don’t suggest it, but there’s nothing that puts a stopgap between you and doing something like that.

But still, don’t do it. Please.

Other frameworks may have stronger constraints than that, but not WordPress. That can be a good thing or a bad thing. Regardless, here are two ways to think about templates:

Passive Views. If you want to treat templates like views, then that’s very, very easy. That is, you simply create the markup and insert the template tags that are responsible for calling information from the core application and nothing more. Active Views. This implies that templates do the same thing as mentioned in the previous point, but they’re also aware of various functions that existing in the application later and can call into them when needed.

As mentioned, templates can get more complicated (and more messy) if you opt to interface directly with any of the WordPress APIs directly from within the template, but it doesn’t have to be that way.

Instead, I’ve found that it’s useful to generally have applications structured like this:

That is, the database resides as the foundation of the application. WordPress sits on top of the database, then there are two segments just above that:

One part of the code is used to register various actions and filters with the event system The other part is used to create helper functions (or whatever you’d like to call them) that can be used by the hooks or the templates but that aren’t connected to any hooks in the actual lifecycle Then there’s the presentation layer that consists of the templates and the various stylesheets and scripts that control what you see on the screen.

The purpose of showing this isn’t to say this is how to do (after all, that’d undermine everything else I’ve said earlier in the article, wouldn’t it?) it, but it is one way to do it.

Always More

Obviously, this is mainly a random set of thoughts and opinions as it relates to the architecture of WordPress products. It’s not meant to be an article convincing anyone of anything regarding design patterns or architecture one way or the other.

Instead, it’s just meant to share a few of my own thoughts as it relates to general web application architecture, WordPress, and one way to conceptualize how things are structured. But they’re just thought – my own thoughts.

There are people who are doing far cooler things with WordPress right now, and who have far better approaches to things. It’s worth tracking with them, as well, to get an even better understanding of just how flexible you can be when it comes to structuring your work on top of WordPress.