[wp-hackers] Plugin dependency checking

[Mike Schinkel]

> First... for the moment, FORGET about auto download/install of 
> master plugins.  One Thing At A Time or we won't get it committed.

Just for clarity, that's almost trivial by leveraging code already in the core. I'm doing that in a plugin that I keep planning to find time to document so I can upload to Extend; it's not a complex plugin.  Yes you could do in steps but it's really not much more scope. FWIW.

Your logic for all the rest seems good to me, and I'll demur to others for answers to your 4 questions. 

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins



----- Original Message -----
From: "Stephen Rider" <wp-hackers at striderweb.com>
To: wp-hackers at lists.automattic.com
Sent: Thursday, June 11, 2009 10:37:53 PM GMT -05:00 US/Canada Eastern
Subject: Re: [wp-hackers] Plugin dependency checking

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  
Master.

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  
mentioned)

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  
"activated".)

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

-- 
Stephen Rider
http://striderweb.com/

_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers