The debate over plugin dependency has been around WordPress for years. I strongly believe that WordPress core needs a simple plugin dependency API for a healthier WordPress ecosystem.
Building plugin dependency into core does more than make something already possible easier. It encourages a mindset for developers to rely on existing, reliable code for use in their own plugins, rather than reinventing the wheel for every plugin they write. It also offers opportunity for end users to get more advanced, reliable solutions for their websites.
There is precedent in WordPress for such a feature enhancement. The Taxonomy schema we know today was introduced in WordPress 2.3, but it wasn’t until 2.8 that custom taxonomies became commonplace; because WordPress made it much simpler to register taxonomies by enabling default metaboxes and admin view handling upon registration. The change made it much simpler for plugin authors and even end users to register and use their own taxonomies, as well as ensured more consistent and reliable code.
Today, there are dozens of examples of functionality that is repeated over and over again in hundreds or even thousands of plugins. People have written plugins for simpler settings page registration, metabox creation, admin column management, frontend utility shortcodes, form creation, login widgets, role management, and a myriad of others. Many of these plugins are extremely useful beyond cases where they act alone.
In other words, it would be great if a plugin developer could use another developer’s quality, existing code in their plugins versus re-doing the same thing as part of their plugin, potentially not as well.
Modular development
As a web developer, one of my functions when consulting a client hardly requires code. I’m often asked to marry functionality from various plugins to bring them together to establish desired functionality for a website. This is why I’ve renamed what we offer to our clients as “modules” instead of plugins.
I consider a module a whole piece of functionality. WordPress eCommerce is a module. It typically requires more than a plugin like Easy Digital Downloads or WooCommerce alone to create a client’s desired functionality. Membership is a module. I may need a combination of several plugins to achieve the desired functionality.
While I’m glad I can offer this service, it’s particularly innefficient. As WordPress “experts” we know which plugins to use and how to use them. We can dance this dance of marrying plugins, with a mix of our own code, to achieve desired functionality. But our knowledge to do so isn’t common, and definitely isn’t widespread. Moreover, it’s currently difficult to implement at greater than a 1:1 level. Meaning, if I do it on one site, I pretty much have to repeat the same steps on the next.
But what if I could do it differently?
Packaged solutions
With dependency, I could create a packaged solution that offers advanced functionality without reinventing the wheel, and I could make these solutions scalable.
I imagine such a feature to work similarly to what Scribu’s prototype, the Plugin Dependency plugin (super meta, right?). A simple Depends: plugin1, plugin2 line in the comment block of the main plugin could act as a module umbrella. Now, developers can marry multiple plugins to create modules of full-featured functionality, on a 1:many scale.
This can also help reduce “mega plugins”, limit bloat, and promote DRY principles. Finally, one of my favorite bits, is that large plugins can reduce themselves into smaller useful pieces so people can only use the parts they want, and simultaneously others can use the entire thing if it’s their desire (Jetpack comes to mind as a perfect example). And they can do so while still allowing users to just intall “one” plugin and get all of the functionality available.
Why this is related to, but different than the extensions model
What I’m proposing is different, but still related, to the well known extensions model. Previously mentioned plugins WooCommerce and Easy Digital Downloads are fantastic examples of the extensions model.
But what I want is to go a step beyond. I love that these reduce bloat and increase functionality with extensions. But, as an example, let’s say I want to create a Wholesale functionality for eCommerce. I could then create a “Wholesale” plugin that requires WooCommerce and other previously existing extensions that help me achieve the functionality I need. And of course I’d have the code necessary to top off what I want to do.
But why wouldn’t I take advantage of already existing, stable, time tested plugins for 80% of the functionality of my new plugin?
Not limited to plugins
Of course, depency isn’t just limited to plugins. In fact, its biggest impact could be with themes. We all know about the bloat of themes that try to pack a world of functionality into themselves; in fact, I just ranted about one the other day. With dependency, themes could reliably use plugins that achieve the necessary functionality they are trying to showcase, while maintaining their own footprint as a primarily presentation layer.
With a dependency standard in place, end users can really win. If they want to change themes, it becomes no problem; because the functionality is in the plugins and not the themes. And theme providers win too, because they can still offer themes that present a solution and not just a template and coat of paint.
On the right track
Otto Wood has written a post on how to achieve dependency in plugins, and Thomas Griffin has a very full featured class to do so. But these tools are still primarily beneficial to developers who want to make their life as a client services provider easier. And in Otto’s post comments, he argues that this functionality should not be in core. I disagree.
The concept of plugin dependency will have a hard time getting real user trust, in my opinion, until such functionality is backed by WordPress core. And it certainly will be hard to make mainstream if it’s always a standalone class to be implemented each and every time by a developer.
Custom content types and custom taxonomies were possible before WordPress 2.8 and WordPress 3.0, respectively. But we all know how their enhanced support in core (and a true API for CPTs) exploded the acceptance of their use in real life.
If WordPress itself is willing to support the idea of plugin dependency, I think it can positively affect the long term quality and sustainability of plugins similar to the way custom post types and taxonomies have for establishing WordPress as a full fledged CMS.
Plugin dependency could establish a trajectory for WordPress to be a better application framework.
Composer.
I haven’t played with Composer, but it looks pretty awesome. For others that haven’t seen it: http://getcomposer.org/
You think something like this is viable or possible for WP core?
I don’t know… Composer is great if I’m both defining and enforcing the dependencies, but it’s not exactly a viable solution for plugins that would be distributed on the .org repo and/or installed through the installer.
@Brian Composer also requires PHP5.3+, which is a blocker for core. Of the ways I’ve seen setting up dependencies for PHP projects, Composer is the best. It’s essentially what everyone else uses.
@John We’re part of the way there: http://wpackagist.org/
Again, I think Composer is a phenomenal way for ME or YOU to manage dependencies; I think it’s just not a viable solution for core. In order to get any benefit out of plugin dependencies, you’d have to use the WordPress installation as the base app for Composer and then dynamically add dependencies from the composer.json files in every plugin and theme to the main config file, then assume composer exists on the system (or bundle it with WP) and then run a system call to composer update/install.
The thing is we are too used to thinking that core is the boss in the stack. Composer can be the boss instead and treat WP core as building block like any other. It’s my opinion that there is no need to wait for WP to work with Composer, since Composer is very few short steps away from working with WP… and not caring about its opinion on the matter.
Couldn’t agree more. WordPress Core needs a “package manager” like Ruby Gems, npm, NuGet, etc. For one, it would help bubble up popular and reliable plugins to the top because devs would notice the same common dependencies in packages over and over and would promote more modularity and less monolithic plugins. In Node.js examples, you see http, connect, express, etc. over and over and people use it because it works. I think this is one of the problems with the current repository of WordPress plugins – there is too much overlap. There are tons of plugins that provide the exact same functionality but differ by only a couple of features, preferences or just implementation. These common aspects should be one clean reliable module that I can “require” and have WordPress Core automatically handle activation and versioning dependency.
WPM (WordPress Package Manager)? Yes, please!