[wp-trac] [WordPress Trac] #22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)

WordPress Trac noreply at wordpress.org
Sat Nov 10 22:02:15 UTC 2012


#22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
--------------------------+------------------------------
 Reporter:  Viper007Bond  |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:  3.4.2
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------------------
Changes (by mbijon):

 * cc: mike@… (added)


Comment:

 The workflow for TMG Plugin Activation is one I think could work for a
 broad pool of WordPress users. It has pre-install notices and makes all
 installed plugins visible to users, no hidden libs or invisible
 activations.

 As for the plugin-proliferation that any dependency manager might expose,
 we already have that and worse. Having many named and shared plugins/libs
 seems better than having just a few plugins where each has it's own copy
 of jQueryUI + different lightboxes + overlapping OAuth libs. The
 overlapping code means even more total code is loaded and there's a
 greater risk of errors. Even a basic dependency manager would help resolve
 that.

 I don't like the idea of "Provides: metabox" though. Not because of
 circular dependencies, but because until the WP.org repository resolves
 issues regarding social/pull coding and ownership transitions we'll be
 better served to have as little overlap as possible between plugins. If
 there is overlap we would need to provide a way to filter/set which of
 many provided libs is used by each of many different plugins.

 What might be making this more complex for WordPress is that plugins are
 so often standalone data, logic and view bundles. That's a bit by
 necessity of just getting things working, but as a community we also don't
 recognize good, base plugins enough. An example is the Twitter plugin
 comment: if people want to compete with 20 other Twitter plugins on
 features or UX that's *great*. The more of that we have the better for
 finding what works. ...but if each competing plugin writes their own
 and/or bundles OAuth code, that's the problem I think we need to solve
 here. There should be a whole set of OAuth plugins, and a whole other set
 of Twitter/Facebook/sharing plugins that don't have their own OAuth code.

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


More information about the wp-trac mailing list