brentjett / wp-core-add-on-plugins-proposal

Proposal for a way to express add-on and parent child relationships among plugins in WP

WP-Core-Add-On-Plugins-Proposal

Proposal for a way to express add-on and parent child relationships among plugins in WP

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 at all. 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, and appropriate handling takes place upon it's activation. I think plugins could potentially take the same form.

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.

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.