When it comes to working with WordPress themes and plugins, there’s a general rule of thumb that most experienced designers and developers follow:

Themes are for presentation, plugins are for functionality.

Sure, there’s a little bit of blurring of lines, but this is the goal for which we strive when working through our code. And yes, there’s a lot that can be said (and has been said) about themes that include a ton of features, options, bundled plugins, and so on, but that’s not where this is going.

Instead, I’ve been thinking about how this relates to general theme development, niche theme development, and using WordPress as a platform for application development.

Presentation and Functionality, Again

I’d like to think the majority of developers agree that we need to be separating our presentation and our functionality as much as possible. Part of this is so that we have a logical separation of concerns, another bit is that it makes it easier to port data between installations.

By that, I mean that we’re able to take a given blog or WordPress-based site and change the theme without losing data or information at the presentation-level.

Similarly, plugins should not influence a theme in such a way that installing them completely breaks or disrupts an administrators or a viewer’s experience.

Niché Themes and Their Plugins

At the same time, there’s a lot of people who talk about niché themes and who talk about using WordPress for application development (I’ve talked about it several times on this particular site). As far as these types of projects relate to the separating-presentation-from-functionality is concerned, I think there may be a bit of a gray area as it relates to what should be a theme and what should be a plugin.

That is, if you’re building a solution for someone that’s going to be powering a website – not necessarily a blog – or that’s going to demonstrate some type of application-like functionality, then “theme lock-in” isn’t something that’s of real concern. Though, at the core, the project may be built as a theme, it will not be treated or used as such. It’s nothing more than a term to describe how the presentation was put together.

I didn't lock myself into my theme...

I didn’t lock myself into my theme…

Furthermore and technically speaking, the functionality should be developed as a plugin, but does it need to be exposed via the Plugins menu? That is, for the purposes of architecture it absolutely makes sense to build functionality into self-contained modules, but if they are theme-specific and are a necessary component of the larger solution, does it make sense to expose an option to deactivate it?

Personally, I don’t think so. We’re talking about very, very specific themes with very specific functionality that’s required to get something working. At this point, the terms theme and plugin are used to describe how the code is put together within the context of a WordPress-project. If this was in another language, then it would be described another way.

Theme-Specific Plugins Are Okay

Ultimately, the point that I’m trying to make is this: Though I’ll generally defend the philosophy that themes should be for presentation and plugins should be for functionality, there are times where I think it makes sense to build functionality as theme-specific plugins and build themes as the presentation layer of an application.

And in those cases, it’s not about preventing theme lock-in, but providing a complete solution that’s well architected and still plays nicely with the WordPress APIs.


Join the conversation! 10 Comments

  1. I’m sympathetic to where you’re going with this. For me, it comes down to knowing what you’re doing and why before going down the theme-specific plugin path, and then being transparent with the end users of the project about how it’s being built. There’s a huge difference between building a niche site or self-contained app built on a WordPress engine and just selling a one-stop “Theme that handles everything for you… until it doesn’t” solution.

    What you’re driving at, a presentation solution for a specifically defined set of functionality, where you know in advance that if you need different functionality you’re going to more or less build something else instead.

    This is different from what I so often encounter where someone has bought (or whose “web developer” sold them a website based on) a 1-stop theme from and now wants to “go with another theme” and expects that “Since it’s all WordPress everything should just work” when the new theme gets installed. In the cases you’re outlining, it’s not so much a WordPress website in the traditional sense, as it is a “web-based solution running a WordPress engine.”

    Thanks as always for a thoughtful post.

  2. Hi Tom. I’m new to this blog. I want to be a freelancer in WordPress myself, but don’t know where to start. People keep saying “just build a project”, but I think like math, you need to understand the symbols and basic theorems first before you can learn by practicing alone. So what do you think are good resources to get my feet wet before diving into building WordPress sites ?( I’m such newbie that until 3 hours ago, I still think WordPress is front-end development).

    Thanks Tom. I will follow all your blogs. This just might change my life.

    • Love this question, but it’s also something that hasn’t have a short and sweet answer. To be a successful WordPress developer, you need to know:

      • HTML
      • JavaScript and jQuery
      • PHP
      • The WordPress APIs
      • An understanding MySQL databases
      • How to find information in the WordPress Codex
      • …and more

      There are a number of great sources that are available out there such as Tuts+’ and some others and this post alone.

      It’s something that can [obviously] be done but it’s going to take a long time to master it :).

      Good luck!

      • Dear Tom,

        Thanks for your answer. This’ a very comprehensive list of resources that I can cozy up during the weekend and work my way through. I’m excited for this. Love the WordPress community, especially inspiring individuals like you.

        Thanks again. Wish you the best.

  3. For me, it’s about pushing, pushing, and pushing certain standards like separation of presentation and functionality. Once you can build stuff using the “correct” methods, it becomes easier to know when it’s OK to veer off course. There’s not a single rule, guideline, or standard that I wouldn’t break if it made sense for a particular project. It’s all about having the requisite foundation to make a well-informed decision.

  4. Interesting thoughts, Tom, and 100% with you on the need for separation. It reminds me a bit of the themes that drive their presentation through shortcodes, Divi by Elegant Themes being a prime example.

    Don’t get me wrong – I love what they’re doing and how they’re trying to make blog/site building easy for the guys (like me) that don’t know code too well. The issue is, if I decide to change themes then I’m left with a whole bunch of shortcodes all over pages (and sometimes posts), which can look an unholy mess.

    It’d be nice if the front-end stuff like this could be deleted with little recourse, much like the back-end stuff of plugins and their remnants when deleting.

    • Definitely! There is some neat work going on with site builders and page builders in the WordPress economy right now, but it comes with the tradeoff of being locked in with certain functionality, how (and what) data is kept in the database, and so on.

      I think having those types of things that result in negative recourse, as you mentioned, is rough. And I think we’ve yet to find a good solution to that.

      • Yep, and it seems some of the devs realize the limitations they’re putting on users – I’ve heard Elegant Themes are releasing a plug-in that cleans up the code if you do decide to switch off any of their themes, be interesting to see how effective that is.

Leave a Reply