In previous versions of the plugin, to define a depedency to BuddyPress, you’d have to write:
Depends: buddypress/bp-loader.php
As a user pointed out, using the plugin path like that is not a good idea.
It turns out that there’s a much more stable piece of information that can be used to identify plugins with: their name. D’oh!
So now you can just write this instead:
Depends: BuddyPress
Besides being a lot more user-friendly, since plugin names rarely change, it’s more reliable as well. Win!
Of course, for super-formal specs, the Provides: header still works.
The main feature added in this version is the “Provides:” header. This allows virtual packages to be defined:
/*
Plugin Name: Lib X
Provides: lib-x
*/
Now, dependant plugins can specify ‘lib-x’ as a dependency:
/*
Plugin Name: Cool Plugin
Depends: lib-x
*/
The first advantage is that dependencies are no longer tied to plugin file paths.
More importantly, you can now have dependency alternatives: there can be more than one plugin that provides the same functionality:
/*
Plugin Name: Lib Alt
Provides: lib-x
*/
When you activate Lib Alt, Lib X will automatically be deactivated.
The idea of dependencies for WordPress plugins has been floating around for some time: #10190, #11308, #12612.
Although plugins can degrade gracefully by using actions and filters, there are some things they can’t do, due to the simple fact that they need to be activated first. Such as:
Activation prevention
Cascade deactivation
My hope is that this meta-plugin will be rolled into Core at some point. Until then, we can learn more rapidly what works and what doesn’t.
Go to the wp.org page to see how easy it is to define a dependency.