Last week, MaxGalleria announced Version 2.0 of their gallery plugin. The update featured a bit of a change in scope for the plugin. The team decided to shift it from a simple plugin to a much more complete gallery platform. Though the core functionality is remaining more or less the same, it’s far more extendable now than ever before, with over a 100 actions and filters for developers to hook into. This means that the core plugin will remain fairly slim, while facilitating a number of add-ons either in the personal or commercial space. MaxGalleria likened the philosophy to that of WooCommerce and Gravity Forms.
Plugins as a Platform
The announcement from MaxGalleria got me thinking about what the future of plugins might end up looking like. After all, WordPress itself is shifting from a blogging platform/CMS to a full application foundation. Eventually, WordPress would like to get to a point where its core functionality can be used to set up the basics, like user authentication, routing, and data schemas. Then, developers can build on top of ad infinitum to create a modern web application. If that’s the case then more niche platforms will need to be developed on top of it. That’s where plugins come in, what the MaxGalleria team called “Platforms on top of Platforms.”
The basic idea is simple. WordPress itself should be getting leaner, not more robust in terms of its core. Its true strength, though, lies in how easy it is to use the WordPress API to do basically anything. But WordPress hooks can’t do everything. If a specialized need comes along, then another platform might have to be molded on top of WordPress to allow for more specialized hooks and finer tuned extendability.
It’s All about Patterns
If you’re a programmer, chances are you’ve heard of DRY programming. But if you haven’t, the concept is pretty simple. DRY stands for Don’t Repeat Yourself, and it’s the foundation of many programming techniques. When a programming pattern is created over and over again by individual developers, chances are it can be modularized and built into a small component that can be fit into any project. For instance, the world would go crazy if developers had to custom code a user authentication system every time they started a new web app. So WordPress makes things easier by offering this out of the box.
But let’s say a developer wants to add a shopping cart to their application. This is a use case that’s fairly common, but not quite common enough to make it into core. Should every developer that wants to incorporate a shopping cart have to code it up from scratch? Of course not. That’s where a plugin comes in. In the past, plugins needed only to provide the functionality itself, and maybe a shortcode or visual editing component. But the demands of WordPressers have increased quite a bit. We need to be able to easily bolt on a shopping cart, but then extend it if necessary. And in order to do that, we need a proper development API.
And that, I believe, will soon become the role of plugins. To identify the reusable bits of code in a standard WordPress install, spin them out into tiny modules, and build an API on top of it so that it can be extended even further. That way if I want my shopping cart to include recommended items or more secure authentication, I just have to use a few actions or filters to get it up and running. This is similar to how Ruby gems or Node modules work. And if WordPress is going to be a platform that competes with other web application platforms, it will need this important bit of modularity.
Appealing to Developers
Ultimately, the future of WordPress will be determined in large part by developers. They will choose what to use the platform to build, and their products will set a precedent for what WordPress can be. And the best way to appeal to developers is with a simple to use API. That’s a lesson that Facebook learned from very quickly. By opening up their API, they became a de-facto user authentication all over the web.
The WordPress API is, in my very humble opinion, extremely easy to work with and build on top of. If a plugin wants to truly be ubiquitous, this is where they will put their efforts. They will build a platform that is familiar to WordPress developers, that uses the same conventions and syntax, but that provides an area of functionality, a pattern, not previously unlocked. Because if two plugins are competing for the same space, the better API wins. More developers will gravitate towards it, will recommend it their peers, will build add-ons for it, and so on.
Not Every Plugin, but Most
There are some plugins that wouldn’t necessarily benefit from the platform model. We don’t need an extensive API for a visual editing plugin. But that doesn’t mean that simple plugins can’t benefit from it. A plugin platform doesn’t need to have hundreds of hooks and dozens of add-ons. It can be as simple as core functionality plus a few isolated actions for more fine-grained use cases. This is similar to how a plugin like SearchWP works.
The good news is that WordPress is open by default. If you build a small module, with an even smaller API, the community will help it grow. There are hundreds of plugins that hit the web every week. But if we start thinking smarter about our plugins, and building small platforms from them, we can add something far more essential to the ecosystem—extendability.
What do you think is the future of plugins? Let us know in the comments.
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.