I recently had a conversation with someone about why I tend to favor working on WordPress plugins over working with themes, and the short answer is that I enjoy working more on application-type functionality rather than working on a design layer, and, as such, I believe plugins are applications for WordPress.
I’ve talked a little bit about this in previous articles:
In short, I tend to strictly view themes as the presentation of data whereas I see plugins as something that should transcend themes and offer functionality to WordPress regardless of what the current blog looks like. This isn’t a revolutionary Idea. Most experienced WordPress developers and designers feel this way, but I figured I’d offer my two cents on the subject.
In a way, plugins are like apps for WordPress.
Themes are Presentation, Plugins are Applications
First off, to say that I enjoy working on plugins more than themes is not to say that I don’t enjoy working on themes.
Case in point, right?
But in all fairness, to hear me say this and to examine some of my previous projects – or projects that I started a few years ago and continue to maintain – would look as if I don’t practice what I preach, but the truth is experience is the best teacher.
To that end, I’m far more attracted to working with my team on lightweight, functional, good looking themes than I am on creating themes that provide some sort of hybrid between functionality and presentation.
And this is something we’re working on refining, but I digress.
At my core, I’m not a designer. I love seeing the work that other designers do and I love what the modern web supports, but I know where my strengths lie so I try to play to them.
Ever since school, I’ve focused primarily on building software, working as a software engineer , and then trying my best to carry that particular passion into self-employment and into startup life.
In the context of WordPress, this means that I gravitate more towards plugins.
Plugins Are Full Stack
By that, I mean that in classical software development terms, plugins can be written as full stack applications.
That is to say that:
- There’s a data layer that’s responsible for communicating with the database and managing data requested from and sent to it
- There’s an application layer that is responsible for managing data that runs between the data layer and the application layer that provides business logic, error handling, and all of that fun stuff
- There’s a presentation layer that’s responsible for making sure anything that’s presented to the browser looks good.
Naturally, not all plugins do this or need to this, but they are capable of it.
Themes Are Presentation
Conversely, themes are presentation layer – or at least they should be.
Admittedly, there are projects that I’ve worked on where I’ve baked a lot of application-esque functionality into a theme simply because it was possible, and for anyone who has read this blog long enough knows that I’m not a fan of “just because you can, doesn’t mean you should.”
So I’ve learned and am working to move away from that model.
Instead, themes should be seen from the perspective that any functionality that needs to communicate directly with WordPress APIs should be done so within `functions.php` (and perhaps tertiary files located in an `inc` directory, but that’s outside the scope of what I’m trying to say).
The End Result
The article was mainly inspired by a lot of the conversation that I’ve seen recently about “theme bloat,” guidelines provided by both Automattic and Envato, and frankly my own thoughts and goals to have more maintainable codebases around WordPress-based projects an applications.
The challenge is, of course, the open nature of WordPress and how there’s no real way to enforce this across the board.
But that’s not really our problem is it? Instead, we can control how our work is organized and try to help others, but that’s about where the line stops.