[wp-trac] [WordPress Trac] #22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
WordPress Trac
noreply at wordpress.org
Fri Sep 10 02:26:48 UTC 2021
#22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
------------------------------------+---------------------
Reporter: Viper007Bond | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 5.9
Component: Plugins | Version: 3.4.2
Severity: normal | Resolution:
Keywords: dev-feedback has-patch | Focuses:
------------------------------------+---------------------
Comment (by afragen):
**Plugin Dependency Thoughts**
**Activation**
We should not be concerned whether a plugin is active or not if it doesn't
have dependencies installed and active. It is the plugin developers
responsibility to ensure their code gracefully degrades and does not fatal
if active without its dependencies.
**Version of dependencies**
We should install the most recent release version of all plugin
dependencies and allow them to be updated.
**A JSON file is not Composer**
A JSON config file, or a coded array that resides within the plugin, is
more efficient and allows for future expansion if needed.
While a header that contains the slug of dependencies has the value of
simplicity it has greater drawbacks. Header parsing is required and there
will likely be an increased support burden associated when unsophisticated
devs use incorrect data in their header.
Plugin dependency inclusion should be easy, but it's not foolproof and it
should require an understanding by developers.
Headers also don't allow for ''recommended'' vs ''required'' dependencies,
unless there are 2 different headers.
Using a JSON file or coded array is more performant as it also requires a
small bit of code to run the dependency installer. This avoids the looping
over every plugin and parsing headers, only then to run code on the
results.
Additionally, having the developer run a small piece of initiation code
allows this solution to work for themes without additional code.
**Recommended vs Required**
I think it's a non-starter to automatically install and activate a plugin
without user interaction. However, messaging and function can be a bit
different.
Required dependencies should have an indication in the plugin row that
they are dependencies and what plugin they are dependencies for.
My personal thought is that once **required** plugins are installed or
activated, they cannot be deactivated or deleted until the plugin that
requires the dependency is deactivated. This avoid the issue of a user not
remembering why a specific plugin is present and active, assuming they
don't notice the other indicators. This can be easily removed from the
example.
**Hidden problem**
Some sort of time dismissible notice is required and not yet available in
core.
**Solutions**
I've been developing both a plugin dependency installer and helped with
development of a time dismissible admin notice for a while.
https://github.com/afragen/wp-dependency-installer
https://github.com/w3guy/persist-admin-notices-dismissal
I have created an opinionated first pass for a feature plugin in
https://github.com/afragen/plugin-dependency-feature
It uses a modified version of the `wp-dependency-installer`. It will need
to have many other features removed to be acceptable to core.
Feel free to change the JSON file to add your own required and recommended
dependencies. Refer to the [https://github.com/afragen/wp-dependency-
installer/wiki wp-dependency-installer wiki] for information on setup etc.
**Non dot org dependencies**
I realize that plugins are not allowed to install plugins from outside of
dot org, but we should at least ask whether this is acceptable to be in
core. Those features exist in the `wp-dependency-installer` code but can
easily be removed.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/22316#comment:170>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list