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.

WordPress Themes

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.

Category:
Articles
Tags:

Join the conversation! 10 Comments

  1. Surprised there is no mention of mu-plugins as an option. To me “Must Use” plugins is a great way to build out solutions on a website specific application layer. This allows the themes and plugins to operate with the necessary degree of separation while you freely develop any site specific functionality/presentation(if necessary) modules.

    • Oh, I’m all for MU plugins but that particular topic seemed to be one that could span the content of its own post so I opted not to actually include it here in this post for that very reason.

      Regardless, it’s still a valid (and good) point :).

  2. For client projects a decided to embed the theme into the plugin. Something that IMHO solves the problem in a beautiful way for a lot of cases. So, beside going with a theme and plugin, go with a plugin only and embed the theme into it. It’s a good solution ’cause you can later customize the presentation with a child-theme :)

    https://codex.wordpress.org/Function_Reference/register_theme_directory

  3. I think the lines are going to get even more blurred as the API rolls out — but we’ll all benefit greatly from it.

    I know TRT is buckling down on content creation functions of themes on the .org repo. There are a lot of top themes (in terms of download count) providing users with slider functionality, services content blocks, and even contact forms — right in the customizer.

    Great for end users because there’s no speedbump to get that functionality up and running when they want something out of the box. However, it does come crashing down as they start to approach customizing the look & feel OR make more sane decisions on tracking form submissions etc.

    And I think that’s where a lot of this argument should boil down to. Does this function relate to completing the visual representation of the theme. Or better yet, does function exist FOR the design. You know, things like being able to shapeshift your content layout and display.

    I think a lot of the decisions the community makes regarding this topic is good for “doing it the WordPress way” (https://tommcfarlin.com/the-wordpress-way/) but often forgets the UX for real humans.

    Like you, I don’t think there will ever be a clearly defined yes/no though I feel we’re going to see a lot of this fog of war lift in the year to come.

    I think there are clear outliers like the above example that we can all agree on, but

    • I think the lines are going to get even more blurred as the API rolls out — but we’ll all benefit greatly from it.

      Agreed and I’m excited to see what all comes of this!

      I know TRT is buckling down on content creation functions of themes on the .org repo. There are a lot of top themes (in terms of download count) providing users with slider functionality, services content blocks, and even contact forms — right in the customizer.

      Yeah – I kinda dig they are buckling down on it, too.

      And I think that’s where a lot of this argument should boil down to. Does this function relate to completing the visual representation of the theme. Or better yet, does function exist FOR the design. You know, things like being able to shapeshift your content layout and display.

      Bingo. Something many of us have been preaching for sometime. I hope this ifnally turns the tides on a lot of what we’ve seen in certain parts of the economy.

  4. This really helped me finally get this.

    Much appreicated Tom

  5. A little late on the bandwagon here but what about the notion of extending popular themes functionality in which the authors have neglected to embrace? This is both questioning the idea of theme-specific plugins and the ethics of building upon someone else’s work for profit (which also poses the challenges of keeping up with their changes of course too).

    For example, I built a front-end customizer for a very popular theme that is sold in a WordPress marketplace. I had advocated to the theme authors to include this functionality but ended up building it myself to improve my workflow. Which it did.

    I quickly realized the benefit and wanted to share it with the world but I had extensive time involved in writing the plugin spanning over a month in my spare time. I considered the idea of selling the plugin for a small price as its a very good selling theme, but not sure about how this is viewed in the developer community. I wrote to the theme authors asking for their thoughts realizing I did not want to start any kind of tension and also knowing they had full control of stamping me out by eventually providing this functionality in-theme if they chose to do so.

    The theme requires zero dependency from the plugin and any changes made while using the plugin. The plugin only provides ease of administration of the features already there, so disabling it would never cause any problems.

    I’m curious how other devs view this. Should I:

    1) Keep it all to myself, time invested does improve my workflow

    2) Give it away for free, again, time invested still improves my workflow

    3) Sell a great product that would be very affordable and support my continued efforts in enhancement?

    • First off, this is a cool story. I think tis’ neat to see how you ended up building something to extend your workflow in the context of another theme.

      But on to your points:

      I’m curious how other devs view this.

      I think this is getting into the realm of the GPL and this always sparks intense debates. I’d prefer not to get too much into it but I’ll share my perspective on it as best as I can (and hope that I tread lightly enough ;).

      1) Keep it all to myself, time invested does improve my workflow

      I think this is something that you can do regardless of if you opt to sell it, give it away, etc. You know?

      if it improves your workflow, why not keep using it? I see it disconnected from what you’re looking to do.

      2) Give it away for free, again, time invested still improves my workflow

      Technically this is something that you’re already doing since that’s one of the freedoms granted via the GPL:

      The freedom to redistribute copies so you can help your neighbor (freedom 2).

      So I’d say if you’re going to be selling it, then you’re going to be selling whatever you have built up behind it (that is the support system, the customer base – not that you’re selling people, of course not! – but that you’re ensuring those customers will be supported).

      3) Sell a great product that would be very affordable and support my continued efforts in enhancement?

      I like this idea the most, to be honest.

      Why not turn it into a small business? Sell the plugin, offer support for it, and use the funds to turn around and invest more into the plugin.

      My two cents. Perhaps others have their own ideas, as well :).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.