[wp-hackers] Plugin dependency checking

Stephen Rider wp-hackers at striderweb.com
Fri Jun 12 02:37:53 GMT 2009

Hi --

Okay, back up a moment.

First... for the moment, FORGET about auto download/install of master  
plugins.  One Thing At A Time or we won't get it committed.  Let's  
figure out dependencies and sub-plugins, and get that rolling.  Then  
later we can improve it with further automation, etc.

Second -- I'd like to reiterate the idea I said previously.  Two ways  
to set a "master" plugin:

1) via good old plugin_basename.  "myplugin/myplugin.php" is well  
established in WP, and **by definition** unique.

2) A plugin can register itself as "pluggable" via a function. In the  
process it establishes its own "master" tag for use by dependents.  E.g.

	register_master_plugin( __FILE__, 'myplugin' );

Again, very common in WordPress -- plugins frequently pick a "keyword"  
to represent themselves, whether it's an option name or a registered  
JS dependency.  Theoretically there could be duplication, but that  
hasn't been a problem with the other places such keys are used, so  
probably won't be here.

> I think a better way to display dependency information is to have a  
> prompt
> that tells you which plugin depends on which. This prompt would only  
> show up
> when a user tries to activate or deactivate one or more plugins.  
> This way,
> we don't get three types of plugins.

There aren't really three, just two.  Regular and Dependent.  **Any**  
plugin can be a "Master" plugin -- all it takes is the existence of  
some other plugin that requires it.  I could create a plugin right now  
that depends on a function from Akismet, for example.  Thus, "Master"  
isn't really a special type-- it's just a relative term when speaking  
of Dependent plugins.

Under the "Dependent" banner, there are two subtypes: "dependent" and  
"sub" plugins.  The only *real* difference here is how they appear in  
the Manage Plugins screen.  Dependent plugins look just like any other  
plugin.  Sub-plugins appear indented underneath their Master plugin  
(with Ajax reveal/hide control).  Thus if a sub-plugin is dependent on  
more than one other plugins, it may choose ONE other plugin to be its  

The reason the sub-plugins are important is that some Master plugins  
may have a large number of sub-plugins.  For example, Spam Karma,  
right now out of the box comes with TEN Spam Karma plugins. For  
purposes of upgrades and such, it would be best if these could each be  
actual WordPress plugins, but we *don't* want to add ten rows in the  
Manage Plugins screen!  Thus the desired ability to specify them as  
Sub-Plugins that can be hidden away in their own little nook under  
Spam Karma itself.

[FYI -- I'm involved with the development of SK, and this very topic  
has been discussed there.  That's why I keep using it as an  
example ;-) ]

Food for thought/ Questions to answser:

1) We must check required versions of Master plugins (previously  

2) If a user tries to activate a Dependent plugin and the master is  
missing or inactive, we need some way to tell the user "You also need  
Plugin X".  That is, the plugin name -- not just the "id tag"  
discussed earlier.  Maybe sub plugins can define their own custom  
error message for this?

3) If Master plugin is deactivated or goes missing, sub should be  
deactivated as well.  (Not too difficult actually to code it so that  
if Master is missing or inactive, Sub just doesn't load -- even if  

4) We somehow need to continuously keep track of versions.  What  
happens if one or the other is upgraded?  How about DOWNgraded?  Also,  
we can NOT depend on auto-install routines, nor activate/deactivate  
hooks.  Plugins are often upgraded via FTP, and are often up/ 
downgraded without being deactivated.


Stephen Rider

More information about the wp-hackers mailing list