By Tom

WordPress Themes

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.

Theme-Specific Plugins

I 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, but 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.

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.

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.

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.

WordPress and Theme-Specific Plugins was written by Tom. Check out additional articles on the full blog at Tom McFarlin.

Read more here:: WordPress and Theme-Specific Plugins