[wp-trac] [WordPress Trac] #22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
WordPress Trac
noreply at wordpress.org
Tue Oct 30 16:30:46 UTC 2012
#22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
-----------------------------+-------------------------
Reporter: Viper007Bond | Type: enhancement
Status: new | Priority: normal
Milestone: Awaiting Review | Component: Plugins
Version: 3.4.2 | Severity: normal
Keywords: dev-feedback |
-----------------------------+-------------------------
''Previously: #10190 #11308 #13296 and I'm sure many more''
It's been a few years since we looked at plugin dependencies and this
still seems to be a feature people really, really want, especially for
shared functionality that isn't a plugin in itself. For example a PHP
library that isn't popular enough to be in core but is popular enough to
be bundled in multiple plugins.
A bunch of us sat down and talked about this at this year's WordPress
Community Summit and there was a lot of enthusiasm for this type of
functionality.
We didn't know about the existing tickets at the time but the general
summary of what we came up with was this:
* Plugins list WP.org slugs of their dependencies in their `readme.txt`,
or perhaps better their plugin's header.
* When you go to install a plugin via the plugin directory UI in the admin
area, the WP.org API returns a list of dependencies along with the data
about the plugin being installed. WP would say like "these following
dependencies will also be installed". This means it's seamless to the user
-- they install a plugin and the other plugin(s) that are needed get
installed too.
* No versioning support. It's too complicated and what if one plugin wants
an older version of a dependency than another plugin does? If your plugin
is listing another as a dependency, then it's your job to make sure it
stays compatible with the latest version of the dependency. On the flip
side, hopefully plugins that get listed as dependencies are made to be
forwards and backwards compatible.
* Probably not allowing the disabling of plugins that are dependencies
while their dependents are active. This seems better than disabling the
dependents when the dependency is disabled ("why did Foo get disabled? I
only disabled Bar!").
* On plugin re-activation or on activation of a plugin uploaded via FTP,
make sure it's dependencies are already installed. If not, offer to
install them. If installed but disabled, just enable them for the user.
So while the previous tickets were closed as `wontfix` in the past, I
think this is worth taking another look at. A lot of planning and thought
will be required though to get this right.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/22316>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list