Try to allow for dependencies that may come in a non-premium or a premium plugin.

Possibly use a filter from the premium plugin to remove the non-premium slug as a dependency and insert itself.

I simple thought occurred to me as reflecting on how we'd use this in GiveWP. We currently, and will continue to, do version checking when someone installs one of our add-ons — we need to make sure it's compatible with the version of core installed.

I understand that versioning is out of the scope of this, which is fine. What would be useful would be to have the ability to filter the plugin names as they appear in the dependency lists. Even if it's not functionally doing anything, being able to have the dependency appear as "GiveWP 2.21.4" instead of just "GiveWP" — as a subtle communication to the user.

When a plugin that has dependencies is active, currently the bulk select checkbox is always removed.

I believe this should only be the case if other plugins that depend on it are active (as is the case with the "Deactivate" link):

https://github.com/WordPress/wp-plugin-dependencies/blob/cda4a6a96edb98e64cfc0615f0a96321c55d547f/wp-admin/includes/class-wp-plugin-dependencies.php#L319

While translating on translate.wordpress.org I noted an issue with one string. It should be:

$string = sprintf(
    /* translators: 1: Opening <strong>-tag, 2: Closing <strong>-tag, 3: List of dependent plugins. */
    esc_html__( '%$1sRequired by:%$2s %$3s' ),
    '<strong>,
    '</strong>',
    esc_html( $sources )
);

Cheers!

Hello,

This is a really great idea, thanks for it.

I think adding a plugin header information like "Depedencies:" should be a great idea for plugins which are requiring dependency.

If your plugin installed or one it will be in Core, WordPress or your plugin will parse the plugin header like it's done today and be able to add the required plugins to the mechanism.

This admin notice better reflects what has occurred: some plugins had to be deactivated because their dependencies are now unmet.

The reason being that their dependencies were deleted, which WordPress lists as separate admin notices below.

Currently the admin_notices() method contains the message:

"... plugin(s) could not be activated. There are uninstalled or inactive dependencies. Go to the Dependencies install page."

However because the UI helpfully:

1. Does not allow you to Activate a plugin if if it has unmet dependencies
2. Does not allow you to Deactivate a plugin with active dependencies

This message currently does not see the light of day.

This makes me think that not only could this notice be removed, but also the deactivate_unmet_dependencies() method (and the need for the wp_plugin_dependencies_deactivate_plugins transient).

I can see that in the future there may be circumstances where you may require this logic (activating/deactivating plugins through the WP-CLI for example), but removing unused complexity at this stage seems like a good idea.

Or perhaps I am missing something?

If there are plugins with unmet dependencies, a notice is displayed in the admin section that says: "There are additional plugins that must be installed. Go to the Dependencies install page."

This notice is displayed even for users who do not have the capability to install plugins. For example, the notice is displayed even for users with the Subscriber role. The notice does not make much sense for such users because they can't actually do anything that the notice suggests. If they click on the "Dependencies" link, they just get a page with an error message (which is to be expected, because they do not have the required capability).

I think it would be better to do either of the following:

1. I think it would be best simply to not display the notice at all if the user does not have the capability to install plugins.
2. If you still want to display a notice to such users, it would be best to reword it (for those users) to something like "There are additional plugins that must be installed. Please notify the site administrator." This is similar to the wording currently used in WordPress core when there is an update available.

/**
* Get names of required plugins.
*
* @param array $data Array of plugin or theme data.
*
* @return string
*/
private function get_requires_plugins_names( $data ) {

The parameter is a string not an array. Should we name it $plugin_file?

• Update screenshots to reflect current release UI
• Removes Hello Dolly from screenshots (see below)

I noticed that unlike the screenshot-1 shows, in the case of Hello Dolly the modify_plugin_row action does not actually do anything; due to the fact that unlike the code expects, the plugin is is not contained within a directory (i.e. it lives in plugins/hello.php).

I realise that this is a weird edge case, but as it is not a true reflection of the current release I thought it might be best removed from the screenshots.

Minor text tweak. The plugin description states "Parses 'Requires Plugin' header", which is not the correct header. This changes the text to be "Parses 'Requires Plugins' header".

Instructions

1. Install a plugin with a dependency
2. On Plugins > Installed Plugins, click the link of a dependent plugin in the "Requires: {Plugin}" list
3. Click "Install Now" in the modal to install the plugin

Actual Outcome

The dependent plugin is installed but the plugin is not listed in the list of plugins until the page is refreshed

Expected Outcome

The dependent plugin is listed in the list of plugins and the plugin with dependencies has its options updated to reflect the installed dependency

There are effectively two types of plugin that I can think of that has dependencies

1. addon plugins - for example a plugin that adds features to WooCommerce

2. plugins that use other plugins as libraries, e,g, using CMB2

I want to talk about type 2.

I think that 'new 'plugins submitted as frameworks or libraries are no longer acceptable / frowned up

What many plugins do is include third party open source libraries, indeed this is possible with CMB2, but there are many other libraries such as the Stripe PHP SDK in common use.

What this then means each plugin loads their own copy of the libraries and unless they are specifically designed for WP this can result in conflicts ( e.g. different versions of the Stripe PHP SDK are not compatible - so require them to be re-namespaced to avoid conflict ).

What I think would be a good idea is to have curated set of the most common third party libraries and a WordPress driven autoloading subsystem for these so only the library is loaded.

I do realise this changes a dynamic of plugin in that they currently only have to use WP core libraries and introducing third party libraries starts to get complex in terms impact of change, however today we have the issue of 'plugin conflicts' Also a security fix to a common third party library can be done once rather than chasing say 1,000 developers.

That is my thoughts so wanted to at least bring it up here.

I'm really passionate about the idea that some of the most shining genius in the WordPress community lies with 'builders' who don't necessarily write plugins and extensions, but they have a good handle on which ones do the one thing really well. I could imagine a way to build a plugin which would act as a solution manager to provide a solution package to micro-veritical problems.

I don't know if that makes sense, but sometimes the right solution is the combination of other solutions. To me, that is the beauty of open source in a sense...like a pantry of ingredients. The chef isn't growing the vegetables and herbs, but he certainly knows how to cook a great meal.

I know there is no discussion of including a theme here, but can themes require plugins? I'm just rubber ducking, but my solution for charter boat captains is theme + plugins + other plugins = a whole solution. Anyway, just wanted to start that conversation as we consider how we consider creating elegant solutions to real world challenges :)

Maybe we could tackle this in two parts and benefit in two ways.

Two Parts:

• how do we accomplish requiring plugins from plugin code? (the mechanism)
• how do we communicate to the site administrator and provide freedom of choice? (the communication)

Two Benefits:

• we could encapsulate the solutions with better separation of concerns
• we could establish and seek more partners across the community who are already working on the communication vehicle and therein make the solution more 'future proof'

Just a suggestion :)

Adding this as it came up often in the discussion on the Make Post

While this is probably out of scope, I can say that just using my PR it is possible to to include plugins not hosted in the WordPress.org repository simply using existing core filters and adding the slug in the Requires Plugins header.

How do we want to display and install these plugin dependencies? Each of the PRs has opinions about how this should happen.

1. Each plugin dependency admin notice has a link to install the plugin.

• non-standard method of plugin installation
• No clear way to view additional information about the dependency

2. A distinct view/tab in the Plugin Install page showing all the plugin dependencies as plugin cards. This gives the advantage of being able to display more Information about the dependency as well as install/activate the plugin from the familiar core method.

• Having a tab in the Plugin Install page offers an easy method to show all the actual dependencies and their installation/activation status.