The official Github repository is now https://github.com/x-team/wp-plugin-dependencies.
In previous versions of the plugin, to define a depedency to BuddyPress, you’d have to write:
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:
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.
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:
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.