[wp-hackers] Plugin dependency checking

[Stephen Rider]

On Jun 11, 2009, at 9:49 PM, Mike Schinkel wrote:

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

Heh.  Duly noted. :)

Download and auto-install is trivial.  Determining what needs to be  
downloaded/installed may not be. (More later RE version checking....)

On Jun 12, 2009, at 2:28 AM, scribu wrote:

>> Thus if a sub-plugin is dependent on more than one other plugins,  
>> it may
>> choose ONE other plugin to be its Master.
>
> I don't think choosing ONE master plugin is useful. Instead, each  
> plugin
> should have a button that, when pressed, simply computes the list of  
> other
> plugins that depend on the plugin at hand. That button may be the
> "Deactivate" link or a new one.

I'm referring specifically to sub-plugins.  (Again, "regular"  
dependent plugins don't look any different that regular plugins in  
Admin -- not indented, not under another plugin.  Only sub-plugins go  
specifically underneath another particular plugin.)  I think you're  
looking at it from the code perspective -- I'm looking from the user  
interface.  The same plugin appearing in more than one place will  
confuse the heck out of users.

A Spam Karma sub-plugin might also depend on some framework plugin,  
but logically goes under Spam Karma, not under the framework plugin.   
It doesn't need to go both places.  Thus, the Master of a sub-plugin  
is simply the plugin that it appears underneath in the Plugin admin.

Okay... one difference for dependents: taking a tip from Drupal, we  
should add a small line below the Description that says "Requires:  
Plugin X, Plugin Y".

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

True, but not all plugins have one.  Also, I'm trying to keep the code  
straightforward, and using Extend slug complicates things.  With  
plugin_basename we directly identify the plugin file.  Ditto a master  
plugin registering itself with __FILE__ (even better actually).   
Extend slug is unique, but doesn't give me a definition of what the  
plugin file itself is -- even in the best of situations the system  
will have to go look something up in a reference list of some sort.

Also... I explicitly do not want to make non-Extend plugins second- 
class citizens any more than they already are. (grmblemumble)

(I'm basically thinking in terms of how adding Admin pages works --  
authors can use either the basename or a slug that they pick.  I think  
it's a good system, and it's already familiar to plugin authors.)

Of course, if a plugin registers itself, it can use its Extend slug as  
the keyword. ;-)

> 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' );
>
> If we use either of these methods, there will be no way to retrieve  
> the
> normal plugin name that you mention here:

It can with registration, we just need to rework the function a bit  
(second parameter or whatever).

As for plugin_basename....  We could do a one-time retrieval of its  
name using get_plugin_data.  Perhaps (I was trying to avoid this,  
but...) storing a list of active Master plugins in the DB.

Actually, we already have an array of all activated plugins.  Modify  
it to also store the plugin name? (?)  I need to think on this one.   
Hmmmm....

> 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?
>
> Error messages should be standard.

Yeah, you're right.  Still, if we solve the above, we solve this too. :)


Overall, I think the hardest part of all this (by far) will be  
tracking versions, since we basically need to make that comparison on  
*every single run*.  I'm pretty sure we don't want to run  
get_plugin_data() for every plugin on every run of WordPress, but I'm  
not sure how else to do it....  This is definitely a puzzle.  The fact  
that plugins can change without firing activate/deactivate hooks (or  
"upgrade" hooks, or whatever) complicates this in a way that WordPress  
has never had to even *think* about unless you're on the Manage  
Plugins page.

Stephen

P.S. -- no rush to respond for my sake -- I won't see any of this for  
the rest of the day.

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