[wp-hackers] Plugin dependency checking
mikeschinkel at newclarity.net
Fri Jun 12 02:49:03 GMT 2009
> 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.
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
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
> 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.
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers