[wp-trac] [WordPress Trac] #11308: Handling plugin dependencies

[WordPress Trac]

#11308: Handling plugin dependencies
-------------------------+--------------------------------------------------
 Reporter:  apeatling    |        Owner:  westi     
     Type:  enhancement  |       Status:  closed    
 Priority:  normal       |    Milestone:            
Component:  Plugins      |      Version:            
 Severity:  normal       |   Resolution:  worksforme
 Keywords:  plugins      |  
-------------------------+--------------------------------------------------

Comment(by nacin):

 Plugins should already be running nearly all of their code off hooks
 anyway.

 It *is* a plugin developer education issue, which is why changing the
 process isn't going to help. All we're doing is introducing a whole new
 dependency network. We can't get many plugin developers to use the enqueue
 script API, or even recognize that we package our own jQuery, so I fail to
 see why introducing a new API when the existing system does the job in any
 way helps with the education component.

 On plugin activation, a BuddyPress plugin can check to see if BuddyPress
 is installed. (A simple did_action will work.)

 Additionally, on plugins_loaded or init (all plugins should be waiting
 until then anyway, so I fail to see why they cannot be told to certainly
 wait until then if they need the BP API), a BuddyPress plugin can check to
 see if BuddyPress isn't installed, and noop or deactivate. Otherwise, they
 can attach all of their hooks and run their initialization code at that
 point.

 A plugin could likewise wait until init to see if other plugins are
 installed (I find did_action to be both effective and lightweight for
 this), and then progressively enhance.

 I think that covers all the bases. A flexible base framework can be
 written that BP developers can rely on and start with.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11308#comment:13>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software