Design: Showing dependency on plugin screen

[peterwilsoncc]

Each of the earlier pull requests included notifications on the plugin screen relating to dependencies/being a dependent in the plugin's table.

Design considerations:

• placement of notice
• level of notice (does it need to be yellow warning or lower level styling)
• how does the notice interact with the plugin update notice

Samples from the PRs

[afragen]

As for interacting with update notices

In regards to notices showing that there are dependencies to install, there are clearly 2 schools of thought. Though I think the standard core way is to inform via an admin notice.

1. an admin notice for every dependency a plugin may require. 10 dependencies means 10 admin notices
2. one admin notice pointing to a view on the plugin-install page.

I think it clearly makes sense to put information in the plugin row if the plugin is a dependency and which plugins require it. The question then becomes, do include similar information for the requiring plugin.

In the case of having all the dependencies listed in a Dependencies tab it clearly makes sense to display which plugin(s) may require a particular dependency.

Also in terms of scale, consider what happens when there are 10 WooCommerce extensions installed and each is showing WooCommerce as a dependency. We can quickly get into "admin notice hell" and quickly clutter the plugin row. Scale was on of the reasons I opted for an inline message addended to the description.

[ironprogrammer]

I think another aspect of this might be to more clearly surface the fact that a plugin HAS a dependency, not just IS a dependency. This would help introduce and highlight the Requires plugins dependency idea.

An initial challenge will be for extenders to adopt the Requires plugins practice, so showing this meta data without enforcing rules might be a less invasive point of entry that could pave the way toward the future goals of the project.

For your consideration:

Add "Requires" to plugin cards, per plugin's own Requires plugins list. Indicator shows whether dependency is already installed. Could alternatively use three states: not installed | installed | active.

Add "Requires" to plugins list page.

[afragen]

@ironprogrammer to break down what I think you're suggesting,

• Add a Requires item in the plugin description field
• Add this in both the plugins page and the install plugins page

My impression is that most plugins that require other plugins are not going to be in dot org. Some will, but I think the primary use case is for things like WooCommerce extensions, etc.

Do you mean just show the requirements without any ability to install them or enforce them?

[ironprogrammer]

In response to @afragen:

Add a Requires item in the plugin description field

I mean to leverage the already proposed Requires plugins plugin PHP header. So if my plugin includes Requires plugins in the header, then my plugin's card would clearly list that requirement. This way if I wanted to install a plugin (in or out of .org's directory), I'd see what I needed to install first.

This suggestion is the reverse of (but can be complementary to) the screenshot in #4. The originally proposed ideas focused on highlighting plugins' dependents, not their own dependencies. (They were perhaps from a plugin author-centric approach?)

This also mitigates the need for an additional "install" tab, since existing cards would more clearly communicate their dependencies.

Do you mean just show the requirements without any ability to install them or enforce them?

I think visibility of plugin dependencies would be valuable, whether or not they are auto-installed. As a plugin author, I might be keen on the idea that my plugin's dependencies could be auto-installed, so this project helps my objectives. However, as a site admin looking at this feature, automatic changes to an environment are risks I'm not ready for. But if the visibility of plugin dependencies becomes commonplace, then it will seem much more natural to introduce the option of automated installation for plugins I didn't specifically find/seek out.

Added Context: I'm trying to look at this through the lens of a site owner who has considered previous automated plugin (and WordPress!) features, and when it felt safe to adopt them. Regarding enforcement of dependencies, if the auto-installation of dependencies was opt-in (like existing updaters), then that seems best. I just wouldn't want to be forced into it.

[afragen]

@ironprogrammer interesting. Sort of approaching it in reverse. Display Requires instead of Required by. How do you propose the user find those dependencies. Would you make them search the plugin repository?

Also, there is no interest or intent to require automatically installing plugins.

[afragen]

Would you display Requires, Required by, or both in the plugins page.

Since we are modifying the plugin row of the dependency to not be able to deactivate/delete while the requiring plugin is active it makes sense to give some indication to the user as to why.

I think adding the Requires looks good but do we really need the extra coding required for the state of the requirement? Looks nice, but if a plugin has 3 requirements what does it look like?

[afragen]

[megphillips91]

The only really strong opinion I hold on this issue is that it makes sense for a plugin like mine that is a WooCommerce Extension. This particular use case (WooCommerce Extensions) is common among the people who have needed / wanted this feature. However, I find myself questioning what tertiary problems it could spawn.

My gut tells me that this is part of a bigger conversation regarding admin notices, and how badly they need to be cleaned up, and how badly developers need a better vehicle to communicate effectively. I know that jonathanbossenger is working on something with the goal of iterating a good solution to that issue.

I am interested, and have followed this repository. Please keep me in mind if you think I can help and be of assistance. :)

[afragen]

Thanks @megphillips91

Currently using an admin notice is the core method of informing the user of something.

Both current PRs use admin notices but in different ways. I would suspect that whenever the larger issue of better management of admin notices is solved this project would automatically get those benefits.

[megphillips91]

I think it clearly makes sense to put information in the plugin row if the plugin is a dependency and which plugins require it. The question then becomes, do include similar information for the requiring plugin.

That does not make sense for a plugin like WooCommerce. There must be 1000s of extensions requiring Woo - and it would never all fit or make sense in that way. It makes sense the other way around though. My plugin Charter Boat Bookings should say "requires WooCommerce" in the red box.

[afragen]

Scale will be an issue. The issue will be present for both the requiring plugin and the dependency. Both should show relevant data. The information should be in both directions.

More information is better, the solution will need to take into account plugins having multiple dependencies as well as plugins that are dependencies of multiple other plugins.

Your plugin should report what it's dependencies are but it doesn't need to be displayed in the plugins page. It should be wherever dependencies are grouped, like in a Dependencies tab in plugin-install.php 😉

[ironprogrammer]

In response to @afragen:

...Display Requires instead of Required by. How do you propose the user find those dependencies. Would you make them search the plugin repository?

I think adding the Requires looks good but do we really need the extra coding required for the state of the requirement? Looks nice, but if a plugin has 3 requirements what does it look like?

and @megphillips91:

It makes sense the other way around though. My plugin Charter Boat Bookings should say "requires WooCommerce" in the red box.

Apologies for the bundled reply, but they address the same theme of what I'm suggesting. In particular is the aspect of this that informs users as to what dependencies exist, before OR after installation. A good analogy would be "Requires 2 AAA batteries" on the box of a toy. Right now when you search for or install plugins, this is not clearly evident.

Here are some comparisons between the approaches:

"Required By" (what plugins I support)

• Does not require effort on the part of plugin authors to declare dependencies.
• Involves a scan through plugin code to find myriad ways in which a dependency might manifest (e.g. check if a specific class or file exists) -- the possibilities are almost endless, making for very complex implementation.
• The list of "Required By" plugins displayed could get quite extensive and impact the UI (e.g. for WooCommerce with a dozen WC plugins added.)
• The information only surfaces after you've installed both the dependency and its dependents.

"Requires" (what plugins I need)

• The plugin declares exactly what other plugin it depends on, indicated in the plugin's PHP header.
• Contributes to user awareness with upfront info on other plugins that will need to be installed.
• The "Requires" items could link to the corresponding plugin (e.g. new window).
• It's less likely that a plugin will have multiple dependencies on other plugins. Eg. in the WC example, my shipping plugin only requires that WC be installed, so the list won't be as long.
• If this information is missing, then it's simply a missed opportunity, but doesn't have any functional impact.

[ironprogrammer]

@afragen:

Scale will be an issue. The issue will be present for both the requiring plugin and the dependency. Both should show relevant data. The information should be in both directions.

One thought on this would be that instead of listing dependencies on the card itself, there would simply be a call-out link such as "*Dependencies" or similar. Then the info could be populated in the much more spacious "More Details" dialog, as a new section, tab, or sidebar content. For instance:

[afragen]

Burying information deeper just doesn't seem optimal. Much less likely that users will "stumble" upon it at all.

But it is a possibility.

[shaunandrews]

Plugins with requirements will display a new “Requires Plugin name” line below the author’s byline. There can many many requirements, and the interface will truncate the list with an “x more” button if it becomes too long. Pressing this button expands the list and shows all the required plugins. I expect that for more plugins, the list of requirements will be a single plugin but the design accounts for outliers.

I’m actually not sure if this new Requires line is necessary in this context; Is this information helpful when browsing and choosing to install a new plugin? Will seeing that there are requirements affect your decision making process in this scenario?

--

Similar to the plugin card, the list of installed plugins should show information about requirements including any plugins that may have a “parent,” or dependent plugin.

I briefly explored the idea of linking between installed plugins, but I'm not sure if this would be helpful or intuitive.

--

There's also the plugins pages page on WordPress.org (accessible in wp-admin from the "More details" link). This screen already lists a PHP and WordPress version requirement. This new design groups these requirements along with the plugin requirements.

[ironprogrammer]

@shaunandrews, thank you so much for the graphical deep-dive in how this might be realized! 🙌🏻