It has been over nine years since the late Alex Mills opened a ticket on WordPress Trac titled Plugin Dependencies (Yet Another Plugin Dependencies Ticket). It is not the oldest of similar feature requests, but it is still open. Most predecessors were closed with the “wontfix” label, which is usually the final nail in the coffin of good and bad ideas alike.

The goal of the ticket is to create a system that allows one plugin to require one or more others to operate. Dependencies are nothing new in the programming world. Composer, the standard PHP package manager, is two weeks shy of turning 10 years old. On the JavaScript end, npm has been around for 12 years, and WordPress has heavily embraced it for core code.

However, those are developer tools. WordPress was built for users, and resolving plugin dependencies would need to happen from within the user interface.

Mills wrote in the ticket:

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.

The first implementation is by Ari Stathopoulos. It creates an “activation queue” that would only activate a plugin once users have activated the required plugins. It also allows users to cancel activation requests.

Andy Fragen’s solution creates a new “Dependencies” tab on the plugin management screen. This approach would automatically deactivate any plugin with unmet dependencies and inform the user via an admin notice.

He has also released the Plugin Dependencies Tab project separately on GitHub.

There are still some practical concerns with both. Namely, what happens when there is a conflict between supported versions? The current proposals leave it up to the plugins to not break anything on the user’s end.

That may be the least confidence-inspiring piece of all of this. However, it is likely the most practical route. Plus, WordPress does not solve version conflicts in its current Wild West system.

A dependency solution could also be an opportunity for more code modernization. Seeing more developers embracing features like interfaces (contracts) would be welcome. Coding with dependents in mind means thinking through architectural problems differently than when any given project was a standalone plugin.