Problem

This feature project began as part of Outcome 4 of Updating the Updaters.

Any pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that requires another plugin (i.e., a dependency) is on its own to make sure admins install the dependency. After all, the plugin will not work without it. But with more than 55,000 plugins in the repository, that means there are potentially 55,000 plugins capable of resolving the dependency.

It would be a lot simpler for users and admins, and plugin developers, if there were a consistent way to handle dependencies in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Among other things, that approach would entail a clear method of determining when a plugin needs a dependency and what that dependency is.

Improving the plugin experience.

There’s a whole categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of plugins that are designed from the ground up to add new abilities to other plugins. Think of shipping and other add-ons for commerce plugins, and one-click checkout for event plugins that sell tickets.

The situation there is a lot like the relationship between parent and child themes. Without their relationships to the bigger plugin, those dependent plugins can do very little. As noted above, every plugin developer is on their own to code a solution to resolve the issue. And, as noted above, the single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins. 

What’s more, this is not a new problem. Across the WordPress ecosystem, people have been looking at it for at least nine years—starting with #22316.

The original scope listed in #22136 was the following.

• Plugins list WP.org slugs of their dependencies in their readme.txt, or perhaps better their plugin’s headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes..
• When you go to install a plugin via the plugin directory UIUI User interface in the adminadmin (and super admin) area, the WP.org APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. returns a list of dependencies along with the data about the plugin being installed. WP would say like “these following dependencies will also be installed”. This means it’s seamless to the user — they install a plugin and the other plugin(s) that are needed get installed too.
• No versioning support. It’s too complicated and what if one plugin wants an older version of a dependency than another plugin does? If your plugin is listing another as a dependency, then it’s your job to make sure it stays compatible with the latest version of the dependency. On the flip side, hopefully plugins that get listed as dependencies are made to be forwards and backwards compatible.
• Probably not allowing the disabling of plugins that are dependencies while their dependents are active. This seems better than disabling the dependents when the dependency is disabled (“why did Foo get disabled? I only disabled Bar!”).
• On plugin re-activation or on activation of a plugin uploaded via FTPFTP FTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients., make sure it’s dependencies are already installed. If not, offer to install them. If installed but disabled, just enable them for the user.

The last bullet point implies automatic installation and/or activation, after previous discussions, it was thought this should be discouraged in the name of preventing a very jarring user experience.

Fundamentally there should be a simple, clear method for identifying and installing plugin dependencies. Any plugin that requires a dependency should degrade gracefully if that dependency is not present. This is the responsibility of the plugin developer.

Design/Discovery

There are hundreds of comments, ideas, and decisions that have been discussed on #22316 and on some of the PRs below. I will attempt to summarize.

• This is not an attempt to create a plugin package manager.
• This is not an attempt to integrate Composer into WordPress or use Composer.
• The agreed upon interface is via a plugin header, Requires Plugins, containing a comma-separated list of plugin slugs.
• The most agreed upon UI for notifying users of a missing dependency requirement is via an admin notice.
• There is no attempt at version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories.. The current plugin version in the dot org repository will be used.
• There is no automatic installation or activation of the dependent plugin.
• If the dependency requirements are not met, the requiring plugin cannot be activated.
• Dependencies outside of the dot org repository are not supported. Out of scope at this time.
• This is only for plugin dependencies that are required not recommended.
• Plugin dependencies for themes is out of scope at this time.

Current Suggested Solutions

There are currently two approaches to handling plugin dependencies.

Similarities

• Both use a plugin header, Requires Plugins, that contains the plugin dependencies within a comma-separated list of dot org plugin slugs.
• Both show the user an admin notice if there are plugin dependencies should be installed.
• Users must actively install and activate the dependencies.
• Users will find they cannot delete or deactivate installed and activated plugin dependencies without deleting or deactivating the plugin that requires the dependency.
• Relevant messaging in the dependency plugin row of the plugins page. (Formatting differs between approaches)
• Neither approach makes any attempt at dependency version control. Most recent version of dependency from dot org is used.

Differences

The differences in the two approaches are subtle, but they do exist.

Current PRs

Approach 1

https://github.com/WordPress/wordpress-develop/pull/1547

• Shows an admin notice for each plugin dependency to both inform the user of the dependency and lets the user install/activate with a click.
• Plugins with unmet dependencies do not get activated; they go into an activation queue. Once dependencies are met the plugin is activated. 
• Users can cancel activation requests for plugins with dependencies. Messaging added as an additional element to the plugin row.

Screenshots from PR

I hope the screenshots are representative of the PR. If not, it is entirely my fault (@afragen)

Approach 2

https://github.com/WordPress/wordpress-develop/pull/1724

• A single admin notice alerts the user to unmet dependencies in any plugin. If multiple plugins have dependency problems, the notice compiles all the notices in one place. This notice persists until all dependencies have been installed. 
• Adds dependencies using a new view/tab/filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. on the plugins-install.php page.
• On the plugin card, shows which plugins require which dependencies.
• Once a particular dependency is installed, shows a list of plugins that require it at the end of the plugin’s description in the plugin row.
• Adds relevant messaging to the plugin’s description.
• Automatically deactivates any plugin that has unmet dependencies and informs the user in an admin notice. 
• Lets the user deactivate or delete a dependency if the requiring plugin is not active.
• Install the Plugin Dependencies Tab plugin as a possible feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins..

Some of the screenshots below may be slightly outdated.

Screenshots from PR

Further Discussion

Pertinent discussions about the best way to implement this are still needed. It doesn’t have to be one of the above approaches, but they are certainly starting points.

Thanks to @peterwilsoncc, @aristath, @audrasjb, @karmatosed, @costdev for assistance along the way. Thanks @marybaum, @bph for editing assistance.

Special thanks to @francina for the initial nudge.

#core, #feature-plugins, #feature-projects