Design Patterns for WordPress Websites

It’s important to have more than one field of interest, especially on a professional level. You never know when the concepts of one discipline will be useful in another. While software programming and web design aren’t exactly opposites, I’ve always felt that web design could benefit more from some heavier programming concepts. What we need are more design patterns for our web work.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. (Wikipedia)

Lately, we’ve been trying to take a step back and look at our process for developing WordPress sites. We’ve been building them more and more frequently, and when you realize that something has become your core competency, I believe it’s time to embrace it and attempt to achieve some kind of mastery.

If you were writing a piece of software, you’d probably start by thinking in terms of design patterns. These reusable mental models are very helpful in software development, and maybe they can help me with my websites. And if you’re talking about design patterns, the first one that would come to mind, arguably the most common and useful, is MVC, or “Model, View, Controller.”

So what, exactly, is MVC?

Model–view–controller (MVC) is a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates “domain logic” (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns). (Wikipedia)

What does MVC look like?

So how might we apply this to our WordPress website?

  1. Our Model will be the data, stored in MySQL and on the file system, it is the content. The larger the project, the more likely this should be tackled first. You have to have a good content strategy going in, after all, and you should end with a good backup strategy.
  2. Our View will be the front-end theme. Nothing about our View should interact directly with your data, and in fact if something does not require your data, it should exist entirely in the view. Think of it as purely presentation.
  3. Our Controller is the WordPress software itself, and plugins that are necessary to connect things up, like caching and possibly SEO or sitemap features.

Now that we have a mental model of what “buckets” to place these different things in, how might it help our design work?

First, it means that a whole lotta WordPress sites overuse plugins. If you are not building your own theme, well, that’s different. But I do this for a living, and I insist on doing the best work possible, and that means writing my themes so that they work the way I think they should. If I want a “Twitter” button at the bottom of every blog post, I’m certainly not going to use a plugin. It has nothing to do with the Model and it has nothing to do with the Controller, so it should live in the View, which means it should be written as part of the view.

This has the effect of greatly optimizing your themes. I believe that you should set up performance caching for your website only once you are really going to need it. If you’re going to be listed on a popular website, you should defintiely set up caching. If you’re getting tons and tons of traffic, by all means. But for most of the websites we build, there’s simply no reason. It adds complexity to things that shouldn’t be complex.

It helps with evaluating plugins. When I’m looking at one, I think hard about how much it should affect a running WordPress site. Should it be allowed to mess with my data? If it’s something that’s just showing something from another site – a bit of JavaScript showing a Twitter feed for example – it belongs in the theme. But if it’s adding a whole lot of interface to the administration interface to let you add SEO information, that’s probably good to have as a separate plugin, as it’s really a level above your data, and you’ll probably use it with the data of many other websites.

You may or may not agree with the blueprint I’ve described here, but that’s not important. What is important is to take time to think about your process, learn from other disciplines, and improve.