It’s been a few years since we looked at plugin dependencies, and this still seems to be a feature people really, really want, especially for shared functionality that isn’t a plugin in itself. For example, a PHP library that isn’t popular enough to be in core but is popular enough to be bundled in multiple plugins.That statement is perhaps even more relevant today. In the past decade, many plugins have grown their own ecosystems of add-on plugins. The responsibility of making sure dependencies are installed has often fallen on the shoulders of end-users. Developers have come up with in-house solutions to ease that burden, and the TGM Plugin Activation script has become the de facto standard. Relying on dependencies is almost a given in any plugin project, at least playing a part in the average build tools setup. It is probably safe to say that more WordPress plugin developers are comfortable coding in an environment that requires third-party code today than they would have been in WordPress’s formative years. For a platform that has been working hard to modernize itself, resolving plugin dependencies is like traveling in a rocket ship to the Wild West. The idea is not without precedent in the WordPress world. While it is a less complex case, WordPress automatically downloads and installs the parent when installing a child theme from the directory. Many arguments for a plugin dependency system fall under the add-on scenario. The most obvious use case is WooCommerce and the dozens upon dozens of extensions written for it. However, the other scenario that can reach deeper into how developers build on top of WordPress is the inclusion of frameworks and libraries. Right now, plugin authors must bundle third-party code within their projects and make sure it does not get loaded if already bundled within an entirely separate plugin. Code reuse is one of the cornerstones of programming. Currently, there is no standard for bundling code libraries or scripts. And, the WordPress plugin directory disallows new frameworks and similar libraries. For transparency, I have at least a dozen projects that fit under this category, packages sitting around that others could use. So, I at least have some skin in the game, and I am sure many others are in the same boat. There are two pull requests on the WordPress GitHub repository for a plugin dependency system. There is also a Google Docs file that outlines both proposals in detail. Each asks developers to define dependencies via a plugin header. The following is an example that would require WooCommerce and Gutenberg: <?php /** * Plugin Name: Sample * Requires Plugins: woocommerce, gutenberg */ Both of the approaches are similar. From the user viewpoint, they would:
- Show an admin notice that there are dependencies to install.
- Disallow deletion or deactivation of plugins without deleting or deactivating their required plugins.
- Output a message in the plugin card on the manage plugins screen.