Group Plugins from the same package, count only once for update

[WraithKenny]

Some plugins (Otto's Simple Twitter Connect and Alex King's Twitter Tools for example) contain multiple plugin files, which can be individually enabled. This is great, but the update notices should reflect 1 update instead of 10 (for Otto's), and it'd be nice to have the UI treat them as a group (a jQuery solution wouldn't be terrible).

Not sure if this is an enhancement or a feature request. Or if the component is UI or Plugins.

Looking for feed-back.

[westi]

How does this work with the upgrader?
Do the plugins do something special to ensure that the correct upgrade source is used?

[WraithKenny]

The sub-plugins (for lack of a better name) are all within the same folder (and therefor the same zip) so upgrades (as well as uninstalls) effect the entire collection.

From Otto's plugin, the sub-plugins do check for the version of the base plugin (as common functionality is required from the base), and registers activation hooks for each.

If the base-plugin is deactivated, the sub-plugins are also deactivate by this. (But I'm not sure that's important in relation to this ticket.)

Other then that, the collection of plugins install and uninstall as a sinlge plugin, but activate and deactivate as separate plugins. This is done simply by putting plugin header information in each sub-plugin as far as I see.

[westi]

I would have thought the plugin itself could do the work of ensuring that only one update check is made - when it is enabled of course.

This feels like an edge case for core.

[Otto42]

The next version of my two plugins that do this will *not* be multi-plugin plugins like they are now. This is basically confusing to users because of the strange way core handles it, and so I'm changing the way they work to only show one plugin in the system.

However, I think there's a use case for allowing plugin authors to have plugins building on each other. So I'll go ahead and float a couple of ideas for future thinking:

• Plugin dependencies. One plugin requires another to be activated first. This can be done now with activation hooks and some clever code to make the just activated plugin deactivate itself, but it would be nicer if it was built in.

• Plugin grouping. Allow authors to define a plugin-group of some sort, which will let them all be shown as one thing, possibly allowing them to be all activated/deactivated together, or allowing them to show up as one expandable/collapsible unit.

Just an idea. Long term.

[WraithKenny]

#11308 was closed 9 months ago: No to Plugin Dependences in core; plugin devs should handle their own API.

Plugin grouping on the other hand sounds like an appropriate enhancement/feature for UI in the admin. Unlike dependencies, it'd only need a flag not an API, and a jQuery UI widget.

[scribu]

Re plugin deps: ​http://wordpress.org/extend/plugins/plugin-dependencies/

Sub-plugins should either be handled properly in core or disabled: only the first file with a plugin header is displayed.

[Ipstenu]

Just to note, what Otto's plugin does with multiple plugins in the plugin, is something we don't let you do with new plugins anymore, because it's too damn confusing. Make an options page please :)

But 'grouping' would be nice. This perhaps could relate to the search API. Look for exact name, and then plugin group, so if I make a sub-plugin of WooCommerce, I could flag it that way?

[Otto42]

Note: "did". I discontinued those plugins and removed then from the directory many years ago. Multi-plugin plugins was a bad idea.

[paaljoachim]

Some plugins can have lots of addons. Having a way to group these together would be helpful.

[dd32]

After 6 years I'm marking this as wontfix. Having multiple plugins within one plugin is a bad idea and leads to more problems than it's worth, taking that into account in future UI's isn't something I believe we should do.