[wp-trac] [WordPress Trac] #40460: Add-On Grouping for Plugin List Screen
WordPress Trac
noreply at wordpress.org
Sat Apr 15 16:25:19 UTC 2017
#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
More information about the wp-trac
mailing list