Something every WordPress developer has wished for, sometime during the development of one of their plugins, is plugin dependencies. Dependencies in the sense of other plugins that provide extra or base functionality for the to be installed plugin. This is something every Linux but also Drupal developer has some experience with.
The main advantage would be that developers could set up shared library ( plugin ) for their plugins to facilitate all the recurring functions. The end user would just be requested to install the dependencies to make everything work smoothly.
Not just for developers
But it’s not just for the developers, it also has some major advantages for the end users.
For instance, my most popular plugin brings support for iDeal transactions to WP e-Commerce. Every week I get about 10 support requests and one of them is from someone who hasn’t installed WP e-Commerce and thinks it’s a stand-alone plugin. I know this mainly sound like it’s a hassle to me but it’s also the end user who feels burdened for contacting me, and that is something I want to avoid.
Not every user will read the FAQ of your plugins but if dependencies are made visible in a clear way, maybe even with some explanation by the developer, we can guide the end user to a better experience and teach them something along the way.
In real life
Another example would be the plugins by Joost de Valk. In most of his plugins you’ll find a file called yst_plugin_tools.php. In this file Joost collects some base functions which are shared by most of his plugins. If he was able to collect these functions in a separate plugin and mark it as a dependency for, for instance, WordPress SEO, it would not only save him and the end user a few bytes per plugin it would also make his plugins easier to maintain for him. If Joost were to find a better ‘best practice’ for one of the mentioned base functions than he could easily replace this in all his plugins if he just updated the dependency plugin.
However it’s not just for developers. Corporations like iDeal or PayPal could set up plugins allowing for base functionality of their services. In this case a developer would just need to set up a bridge between his own plugin and theirs to implement the mentioned payment gateways. This would make it easier for the developers, hopefully leading to a wider adoption for such services resulting in more choices for the end user.
Caveats
But the dependency system also has it’s flaws. What can a user do when plugin x requires version >=1.0 of plugin y and plugin z requires version <1.0 of plugin y? This is a recipe for disaster, or at least some annoyance.
And there’s also the risk of too many developers relying on one dependency for which support and further development has been cancelled. Or the possibility of the developer of the dependency removing compatibility for a certain function. This will also hurt the end user’s experience.
Both scenarios should be anticipated by the WordPress community.
Moving on
Developer Silviu-Cristian Burcă already developed a nice plugin which sets up a dependency system. Sadly you can’t use this for your own plugins unless this plugin is installed and therein lays the tragedy of it. And the plugin doesn’t support versioning for dependencies yet which is a must-have to make this work.
I personally expect a dependency system to show up in the WordPress core sometime between version 3.3 and 4. The demand for such a system is increasing (#10190, #11308, #12612) but what is most important is to start discussing it. We need to highlight all the aspects to get a clear picture of what is needed to facilitate it.
The WordPress community can learn a lot of the mistakes which the Drupal community already made. Drupal didn’t support dependency versioning until version 7 and the community had a hard time excepting the system. I know for sure that our community can do this exactly right the first time as long as we stick our heads together.