WordPress plugin design is not something that we often read about explicitly, is it? Instead, we often talk about functionality, performance, and things like that (not that they are unimportant, but they are just one part of the conversation).
When it comes to WordPress plugins, the functionality one offers may range from very small to incredibly large. And this is how it is with almost any type of product, isn’t it?
“Plugins extend and expand the functionality of WordPress. 46,537 plugins with 1,392,817,734 total downloads are at your fingertips.”
Sometimes, I think we have a tendency to want to say “focused, and lean” with smaller plugins as if a larger plugin can be described as such simply because of its nature.
But that’s not true.
There are very small, well-built plugins that offer one or two features. And there are large plugins that are also well-built that offer a plethora of features. On the flip side, either type may also be unfocused, cobbled together, and may be anything but what we’d like it to be.
When you look at the landscape of all that’s offered regarding WordPress plugins, it raises a few questions (at least from a developer’s perspective).
I’m going to cover them all in this post, too! Or not.
But seriously, one of the things I’ve been thinking about is this:
At what point do you begin organizing your code, so it includes namespaces, autoloading, dependency management, and other such features that take it beyond a collection of classes or functions?
This implies a lot about a given hosting environment and a developer’s level of familiarity with PHP and experience with other tools, but that’s secondary to the question (and I’ll cover all of that momentarily).
