[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