[wp-hackers] Plugin dependency checking
wp-hackers at striderweb.com
Fri Jun 12 12:55:43 GMT 2009
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
> should have a button that, when pressed, simply computes the list of
> 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.
>> register_master_plugin( __FILE__, 'myplugin' );
> If we use either of these methods, there will be no way to retrieve
> 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.
> 2) If a user tries to activate a Dependent plugin and the master is
>> 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
P.S. -- no rush to respond for my sake -- I won't see any of this for
the rest of the day.
More information about the wp-hackers