In a significant development for the WordPress community, the plugin dependencies feature is finally coming to WordPress. This is something the community has been discussing and debating for more than a decade.
A Brief History
It was in 2012 that Alex Mills opened a ticket in Trac (#22316) on Plugin Dependencies on the heels of the 2012 WordPress Community Summit. In fact Alex Mills was not even the first person to open a ticket on Plugin Dependencies. ShaneF had opened a ticket (#10190) for Plugin Dependency Class API while Andy Peatling opened one (#11308) for handling plugin dependencies. Both were opened in 2009 and closed quickly (wontfix).
The next stage of discussions on plugin dependencies proposed two approaches to handling plugin dependencies. Later Plugin Dependencies plugin was released into the Repository and Andy Fragen issued a Call for testing the plugin.
The ticket gained traction in 2022 when Matt Mullenweg commented: “It’s complicated, but a major unlock.” The ticket was then set for WordPress 6.3 milestone and later to 6.4 and finally to 6.5.
Thus the ticket remained open for 11 long years until it was finally closed as “fixed” on February 06, 2024. The bittersweet moment came after the passing of both Alex Mills and Alex King.
Plugin Dependencies
Plugin Dependencies introduce a new “Requires Plugins” plugin header so that plugin developers can list the slugs of dependent plugins. Dependencies are other plugins that a specific plugin needs to function properly. Until now, users often had to research to identify and install these dependencies.
Users are informed upfront about a plugin’s requirements and provided with links to the WordPress.org Plugins Repository that they can click to install and activate the dependencies first.
Plugins whose requirements are not met (i.e., its dependencies are missing) cannot be installed or activated, and they will be deactivated automatically if their requirements become unmet and plugins that others rely on dependencies cannot be deactivated or deleted until their dependent plugins are deactivated or deleted. This ensures that incompatible plugins don’t cause conflicts.
validate_plugin_requirements() used internally by activate_plugin() has been modified to also check for plugin dependencies that are not installed or are inactive. This also means that any other calls to validate_plugin_requirements() will now get failures on plugin dependencies.
Another PR was opened to discuss removing invalid plugins from plugin_data option and was merged. Invalid plugins are not loaded by WordPress Core, such as those that have been renamed or deleted. However, the invalid’s plugin data remains in the plugin_data option and must be cleaned up by removing those plugins from the plugin_data option.
The inclusion of plugin dependencies in the WordPress core is a significant step forward. It streamlines the plugin ecosystem, reduces compatibility issues, and empowers users to make informed decisions about their site’s functionality.