[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      |  
-------------------------+--------------------------------------------------
Changes (by shidouhikari):

 * cc: shidouhikari (added)


Comment:

 Interesting, I liked all presented ideas!

 My contribution, is the need of framework plugins. Drupal has a bunch of
 them, like CCK and Tokens. A framework plugins doesn't have end-user code,
 it "only" has code that remains available and will be used by other
 plugins.

 I don't remember if Drupal's module dependance system checks version, but
 it lets a module sets itself as depending on another module. If the parent
 module isn't activated, the dependant one is listed, but it's activation
 link isn't provided, first the parent module must be activated. And when
 both are activated, the parent one can't be deactivated, first all its
 dependants must be. For each module, it also lists their dependants and
 dependances, so that users can see what may be blocking an action.

 I like Wordpress' dependance feature, that's used for scripts in exemple.
 Plugins are loaded in the order present in 'active_plugins' option, it's
 an array and when a plugin is activated it goes to the end of the list...
 plugins aren't loaded in alphabetical order.

 The problem for framework plugins, is that both ones MAY be activated, but
 dependant one may be after parent one in the array. If the dependant
 plugin extends a framework class, and when it's loaded that class isn't
 loaded yet, it may break. Action hooks is a good idea, but I think that
 having a core feature to control loading order, in the same way scripts
 inclusion is done, would be nice.

 The problem now is that a plugin reference another plugin is indeed
 tricky. In the active_plugins's array, they are referenced by
 plugin_folder/plugin_file.php. That's good because no other plugin can
 have the same folder/filename at the same time, but it's also bad because
 this "ID" isn't static. Plugins folders may be renamed by users, and the
 "ID" isn't set by (and thefore controlled) plugin author, so dependant
 plugins authors also can't control them.



 In the end, MHO is that filoso's suggestion is very nice, let plugins have
 more control over plugins list UI and set colors and texts saying like
 "I'm activated, but I don't work", "I'm activated, but only partial
 features are available", and also add texts that let them say their
 dependances, and on their parent plugins list themselves and dependants.
 This way we could make it all clear, and with a standard interface.


 And then, maybe build a new code to let plugins load. For exemple, when
 plugins loading loop is running, create a temp array with all plugins
 filename, and when they are loaded, before 'plugins_loaded' action is run,
 run dynamic actions based on plugins filenames (for exemple "$plugin-
 loaded").

 Yes, I know a plugin can add an action itself, but if core does it by
 default, any plugin could use the feature without relying on its parent
 cooperating with it.



 In the end, we can right now develop plugins that depend on other plugins,
 but what we're talking here is define a standard for this situation.
 Imagine 10 plugins depending on BuddyPress, each of them handling the
 depandance by themselves using different methods... It'd be a mess. If we
 want Community Plugins to prosperate, we must standardize plugins
 dependances.

 Imagine if BuddyPress is deactivated and then we have 10 orphaned plugins,
 all in the same situation, but 6 of them add text on top of page, 3 of
 these 6 add the text to ALL admin pages, 1 of them add a message on
 frontend footer, 2 other plugins change their color (using 2 different
 colors) in their row in plugins list, and 1 of them simply deactivate
 itself.

 Personally, I think dependant plugins don't need to be deactivated when
 parent one isn't available. Leave them activated waiting for parent to
 come back, just disable their features and make it clear to site admin,
 that they're activated but not running, and that's happening because a
 parent plugin isn't available.

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