[wp-hackers] Plugin dependency checking

[Stephen Rider]

NOTE:

You can read all of this for the discussion, or you may just choose to  
jump to the bottom, where the rug gets yanked out from under....


On Jun 13, 2009, at 1:56 AM, Mike Schinkel wrote:

> "Stephen Rider" <wp-hackers at striderweb.com> wrote:
>>> While I like your sub-plugin model, will it confuse users if two (2)
>>> different plugins use the same sub-plugin?  I know you are thinking
>>> of plugins specifically made for another plugin but someone could
>>> easily choose to implement the same interface so they could have
>>> ready-made add-ins for their own plugin.
>>
>> Could you give me an example, because seriously I can't think of any.
>> Again note the distinction between dependent plugins and sub-plugins.
>
> Sure I can give an example and one I think is highly likely.
>
> Let's say the fine folks who are offering WP e-Commerce decided to  
> create payment processor sub-plugins; one for PayPal, one for Google  
> Checkout, etc. etc.  I in my opportunistic wisdom decide to create  
> my own ecommerce solution targeted at video cartoon characters with  
> blogs on WordPress which I choose to call "WP Super Mario  
> Cart" (oblivious to the obvious trademark lawsuits that will be  
> hurled at me.) But rather than worry about implementing all those  
> tedious payment processing modules I just implement the same  
> interface that WP e-Commerce chose to implement. Presto bango, I now  
> have a bunch of dependent sub-plugins that will work for my new  
> shopping cart.

So... we have "WP e-Commerce" and "Paypal Module" sub-plugin for WP e- 
Commerce.  Paypal Module plugin has some code in it that says "this is  
a sub-plugin of WP e-Commerce".  *By Definition* that means it is  
dependent on WP e-Commerce.  (Sub plugins are just a special kind of  
dependent plugin.)  That means that unless WP e-Commerce is present  
and activated, Paypal Module *doesn't even load*.  You would have to  
hack it to say "This is a sub-plugin of Mario Cart".

This is all very similar to frameworks.  Something I've been working  
on, on the side, is a WP plugin framework called Strider Core.  When I  
get it done, all of my plugins are going to be built on top of it.  In  
this situation I would not use the sub-plugin formula but simple  
dependencies -- Strider Core would be a plain-old plugin and the  
others would have the Header that says "this plugin depends on Strider  
Core".

Here's another thought.  If someone deletes a plugin that has subs,  
all of its sub-plugins should logically be deleted along with it,  
because *by definition* the sub plugins are nothing without their  
Master plugin.  IF I get rid of "Spam Karma", I really don't need the  
"Spam Karma Anubis" plugin sticking around.  In fact I don't need any  
of the TEN sub-plugins that ship with Spam Karma.

What you're asking for in your example is the ability to switch from  
Push to Pull -- you want a plugin to be able to say, "Plugin Z is a  
sub-plugin of Me".

The **simplest** solution to your example is that PayPal module  
shouldn't have ANY dependencies.  It's just some functions and an  
add_action, which doesn't do anything unless some other plugin calls  
the corresponding do_action.  You're not asking for real dependency,  
you just want the visual appearance of a sub-plugin.

Might be doable, but it's a different thing.  Here's the real UI  
problem with that though:

Okay, Paypal Module appears on the Plugins list underneath both WP e- 
Commerce and Mario Cart.  I go to the one under WP e-Commerce and  
deactivate it.  Ooops!  I just deactivated it for Mario Cart too!  In  
WordPress, a plugin is either activated or it's not (at runtime the  
file is either include()ed or it isn't.)  What you need is code within  
the two Cart plugins that say "use sub-plugin X or don't", which is --  
and should be -- beyond the scope of WP's plugin management.


<snip>
> If you already knew all this about interfaces, forgive me. Some  
> people on wp-hackers have a deep computer science background and  
> others first learned to program in order to modify WordPress and  
> since I don't know who knows what I figured I'd inject a bit of this  
> background.

Heh.  I learned programming by typing games into my Apple ][+.  Still,  
more of the latter than the former.  :)

> Validation would be HUGELY beneficial. If could allow us to disable  
> non-conforming plugins during an upgrade and even make it possible  
> to determine if there will be problems prior to an upgrade.  
> WP_Interface() would go a long way towards making larger companies  
> and agencies more comfortable with using WordPress because over time  
> it would increase the robustness of the WordPress platform.

Are you talking about what Firefox does where add-on authors have to  
continually update their add-ons just to bump the version of Firefox  
that their stuff is compatible with?

> Wrapping up by coming back to your concept of "dependent plugins"  
> vs. "sub-plugins" I really don't think we should make any such  
> distinction.

They are basically the same thing.

Dependent means that if Henchman Plugin is dependent on Boss  
Plugin(s), Henchman doesn't even load (in PHP, isn't included) unless  
Boss is loaded.

A Sub-Plugin is exactly the same, except for the added UI that it  
appears underneath a specified Boss in Manage Plugins, and if that  
specific Boss is deleted, so are all Subs.

> As for the admin UI I do agree that it would be nice to have a way  
> to display those that are generally only there to be supportive of  
> another plugin in a tree view up that plugin, but that should be  
> determined by WordPress inspecting the two plugins not by anything  
> defining a plugin as a "master" and another as a "slave." IMO, anyway.


...

*sigh*  10,000 words later, I think you've talked me out of the whole  
idea.  I'm seeing problems with the whole plan.

Plugins can already make themselves dependent on another by checking  
for the existence of the needed functions from the "master".  Or they  
can just offer up functionality via add_action that is called or not  
by some other plugin.

The only REAL important part of all this is that the dependency  
relationship allows for proper loading order.

So... rather than Master/Slave, or even "dependent", what we need is  
something in WP Core that allows for some plugins to say "offers X"  
and others to say "uses X"; and if the two match up then we get the  
"sub plugin" UI changes.  (And forget the bit about deleting sub- 
plugins!)  This is really a complete change from previous discussion,  
but probably the best.

Stephen

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