[wp-trac] [WordPress Trac] #40460: Add-On Grouping for Plugin List Screen

[WordPress Trac]

#40460: Add-On Grouping for Plugin List Screen
--------------------------------+-----------------------------
 Reporter:  brentjett@…         |      Owner:
     Type:  feature request     |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Plugins             |    Version:
 Severity:  normal              |   Keywords:
  Focuses:  ui, administration  |
--------------------------------+-----------------------------
 I'd like to see if anyone has thoughts on (or has previously discussed)
 reworking the plugins API & plugins list screen to group "child" or "add-
 on" plugins under their required parent plugin. There are obviously some
 API implications that go along with this. It seems pretty common now for a
 well-rounded base plugin, premium or free, to develop a handful of add-ons
 that require the base functionality of the main plugin and provide no
 meaningful value on their own. These "child" plugins can be from the same
 developer as the parent, or from a 3rd party community that wants to
 extend the usefulness of the parent plugin.

 Because WordPress plugins have no concept of relationships between one
 another, several less-than-ideal scenarios can occur. Firstly, an add-on
 plugin can be activated while the parent plugin is not active or even
 present. Without it being expressed in the title or description, there's
 nothing to necessarily tell a user that another plugin is required for the
 one they're installing to function. In the best case scenario, the add-on
 plugin developer has put safe guards to check for the parent plugin into
 their code, and will write a message out to the user upon activation to
 tell them why there's an issue. In the worst case scenario, the developer
 simply assumed that they parent plugin would exist, did no checks for the
 availability of the base code, and WordPress encounters a fatal error.

 Now dependency management is a broad and weighty topic and I do not
 believe that a full-blown dependency system is what I am proposing here.
 We do already have a pattern for how to express a basic requirement in the
 existing parent + child theming system. A child theme expresses that it
 requires the parent theme with the template attribute and appropriate
 handling takes place upon it's activation. I think plugins could
 potentially take the same form.

 [[Image(https://raw.githubusercontent.com/brentjett/WP-Core-Add-On-
 Plugins-Proposal/master/plugin-declaration-with-template.png)]]

 A plugin declares that it requires it's base plugin to function with a
 "Template" (or Parent, Required, etc...), and the system handles including
 it at the proper time, or not at all depending on the base plugin's
 existence. The UI benefits from this by grouping these add-on plugins with
 their associated parent plugin so there is a visual understanding of that
 relationship. This serves to organize the plugin list in a friendlier way,
 regardless of what a plugin my be named.

 [[Image(https://raw.githubusercontent.com/brentjett/WP-Core-Add-On-
 Plugins-Proposal/master/plugin-screen-addon-groups.jpg)]]

 There's plenty of complexity to work out both in the UI and API design for
 this to be a nice addition to the platform. The plugin list should end up
 more clear and easy to read, not more cluttered and disjointed in the end.
 I'd love to hear thoughts! Thanks for taking the time.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40460>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform