[wp-trac] [WordPress Trac] #22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)

WordPress Trac noreply at wordpress.org
Fri May 12 21:28:29 UTC 2023


#22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
-------------------------------------------------+-------------------------
 Reporter:  Viper007Bond                         |       Owner:  afragen
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.3
Component:  Upgrade/Install                      |     Version:  3.4.2
 Severity:  normal                               |  Resolution:
 Keywords:  dev-feedback has-patch needs-        |     Focuses:
  design-feedback needs-dev-note has-unit-tests  |
  2nd-opinion changes-requested                  |
-------------------------------------------------+-------------------------
Changes (by azaozz):

 * keywords:
     dev-feedback has-patch needs-design-feedback needs-dev-note has-unit-
     tests 2nd-opinion
     =>
     dev-feedback has-patch needs-design-feedback needs-dev-note has-unit-
     tests 2nd-opinion changes-requested


Comment:

 Testing the UI/UX and workflow of the current
 [https://wordpress.org/plugins/wp-plugin-dependencies/ Plugin
 Dependencies] feature plugin, thinking couple of parts of the workflow
 should be changed and few parts need improvements.

 1. Installing a plugin that requires a dependency. The installation is
 allowed despite that the requirements for the plugin are not met.
   - The first thing the user sees after installing and trying to activate
 is an error: "The [plugin_name] plugin(s) have been deactivated. There are
 uninstalled or inactive dependencies...". That's not a good workflow.
   - This feels a bit like a "clickbait": "Yea, go ahead, install this
 plugin!". But after the plugin is installed: "Nonono, you cannot use
 (activate) this plugin. You **have to** install that other plugin first!".
 This is bad UX. Dependencies will have to be installed before a dependent
 plugin is allowed to be installed. (I know that's a bit harder to do from
 coding point of view, but the current workflow is really not acceptable
 imho.)
   - The current workflow depends on a warning message in order to work.
 The next step after installing a plugin with unmet requirements is to show
 a WP Warning message at the top of `wp-admin/plugins.php` screen (the
 Plugins list table) in order to redirect the user to another screen where
 the missing dependency is shown. Depending on an error condition (a WP
 Warning message) in order for the workflow to work is not logical imho.
 That's not good UX too. This also seems redundant as the dependency can be
 installed from the dependent plugin's row in the list table.
   - After a plugin with unmet requirements (missing dependencies) is
 installed, the row in the plugin list table has no indication about the
 unmet requirements. The only indication that something is wrong there is
 the greyed-out "Cannot Activate" which seems pretty confusing (i.e. the
 user has a feeling they did something wrong).

 2. As I mentioned in my earlier comment the separate "Dependencies" screen
 tab that is under the Add New screen doesn't seem to make sense.
   - It is not needed as dependencies can be installed from the listing the
 dependent plugin in the plugin's list table.
   - It doesn't make sense to have such screen as it is out of context. It
 seems better to enhance the listing of the dependent plugin in the
 plugin's list table where dependencies will be in context. That would go a
 long way in making the whole functionality easier to grasp for many users.
   - Instead of a new tab on the Add New screen, it seems more useful to
 have two "filtered views" in the Plugins list table. One for plugins that
 require a dependency, another for plugins that are used as a dependency.

 My recommendations are s follow:
 1. Change the workflow so plugins that have unmet requirements cannot be
 installed.
   - I looked around for anything that resembles this "Dependencies" UI/UX
 but couldn't find a good example. The closest one is when trying to
 install an app that requires some operating system part/library. In these
 cases the installation in not allowed until the requirements are met. That
 makes the most sense.
   - For plugins with dependencies: list the requirements on the plugin
 "tile" and in the "Install" modal (on the Add New screen). Not mentioning
 that a plugin requires other plugins in order to work is a pretty bad
 omission imho.
   - Use the plugin's tile and install modal not only to show but also to
 install missing dependencies.
 2. Other enhancements:
   - Enhance the plugin's row in the list table to clearly show error
 conditions if a dependency is erased outside of WP or missing for some
 reason.
   - Remove the Add New/Dependencies tab/screen. It will not be needed when
 the workflow is fixed to require dependencies before a plugin can be
 installed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/22316#comment:288>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list