Prepare for Plugin Dependencies

[dd32]

The Plugin Dependencies feature plugin is ​currently slated for WordPress 6.3, although subject to change.

• ​https://make.wordpress.org/core/2022/02/24/feature-project-plugin-dependencies/
• ​https://github.com/WordPress/wp-plugin-dependencies

To prepare for this, we could:

• Block plugin submissions and updates which reference dependencies which are not valid
• Block plugin submissions which use the Dependencies feature but are not Requires WP >= 6.3
• Potentially delist existing plugins when the dependencies become unavailable (ie. Required plugin is removed from the directory, a plugin which requires that plugin should not be installable)

This ticket is a holding ticket for keeping it on the radar, but I have nothing to commit related to it right now.

[jsmoriss]

Potentially delist existing plugins when the dependencies become unavailable (ie. Required plugin is removed from the directory, a plugin which requires that plugin should not be installable)

You assume that a plugin would not depend on a commercial plugin that is not available on wordpress.org, or a free plugin that is available from another repository like github etc.

js.

[Otto42]

Correct. Part of the deal with hosting plugins on WordPress.org is that the plugin updates be available from WordPress.org. if the dependency does not exist here, then the plugin is invalid, because the dependency is not available here.

We would not serve updates or plugins if the required dependencies were not met, just as if the required PHP version was not met.

[jsmoriss]

Part of the deal with hosting plugins on WordPress.org is that the plugin updates be available from WordPress.org. if the dependency does not exist here, then the plugin is invalid, because the dependency is not available here.

So if plugin ABC depends on DEF, but plugin DEF hosted on github (for example), then wordpress.org will refuse the submission of plugin ABC, and if previously hosted on wordpress.org, once plugin ABC declares its dependency on DEF, it will be pulled from the repo. Is that correct?

Note that this is not a situation with any of my own plugins, but it struck me as wordpress.org creating a walled garden, which has not been the previous approach of the wordpress.org repo.

js.

[jsmoriss]

As a concrete example, this would mean that any plugin hosted on wordpress.org that depends on WP Rocket (a popular caching plugin not hosted on wordpress.org), then all those plugins will be pulled from the repo, is that correct?

js.

[afragen]

There are many Gravity Forms Add-on plugins currently in the repository. Gravity Forms is not available from the repository. If the devs of those add-on wish to take advantage of the messaging and function of the Plugin Dependencies features.

I hope that these plugins wouldn't then be removed, hidden, or be otherwise unaccessible. That would be tantamount to saying if the whole plugin stack is not available from the repository then an add-on plugin cannot be in the repository.

This feature isn't about whether the dependency is ONLY available from the repository. Please don't limit it as such.

The Plugin Dependencies feature plugin has a Requires at least: 6.0.

[afragen]

Replying to Otto42:

Correct. Part of the deal with hosting plugins on WordPress.org is that the plugin updates be available from WordPress.org.

Updates to the add-on plugin would be available from WordPress.org

if the dependency does not exist here, then the plugin is invalid, because the dependency is not available here.

This is a logical fallacy. Are you really prepared to say that the repository is not the place for free plugins, that just happen to be add-ons for premium plugins?

[afragen]

Honestly, there is nothing the Plugins API, nor the Plugin Repository, need to change for the Plugin Dependencies feature.

[Otto42]

Replying to afragen:

Updates to the add-on plugin would be available from WordPress.org

Not if it declared a dependency that was not available. That's the point of this ticket.

This is a logical fallacy. Are you really prepared to say that the repository is not the place for free plugins, that just happen to be add-ons for premium plugins?

Not at all. Simply that such plugins should not be using the dependencies feature, because the dependencies cannot be verified by the plugin directory.

Replying to afragen:

Honestly, there is nothing the Plugins API, nor the Plugin Repository, need to change for the Plugin Dependencies feature.

Clearly, that is not the case. I believe there was discussion about a phase two, which would allow for Uris to be included in the headers and allow installation of code from unvetted sources. Obviously, that would be a bad idea, since malicious code could then be easily be snuck in to the directory. You may think this is unlikely, but it happens on the regular and has for at least 15 years.

The plugin directory is very much a "walled garden". We vet plugins for malware, security, general issues and improvement. All sorts of things. I have done so for more than a decade. So, creating a hole, or backdoor if you will, to install unverified code from the general internet, is not acceptable for plugins in the directory to do. So yes, it very much does need to be limited by the plugin directory. And if necessary, completely disabled by the plugin directory.

[afragen]

@dd32 @Otto42 What are you thoughts if the ability to directly install a non-dot org plugin from the plugin card was completely unavailable?

I'd rather intentionally hobble the feature than have it be a reason for dot org to ban plugins.

[Otto42]

No one is speaking about "banning" anything. Simply not serving a plugin thru the API and possibly showing an error message to a plugin author when they use an incorrect dependency is what we're really talking about here.

If there is a dependency failure in a plugin, then we want to show an error to the author so they can correct it. If a plugin is submitted with an invalid dependency, we would want to show that error to them during the submission process. If a plugin is removed for cause or for whatever error, then we want to let any dependent plugins know about that fact.

If dependencies are going to exist, then they need to be managed properly, and code needs to be created to allow them to be useful in all aspects of the system. Things don't get made only to be useful for core.

[jsmoriss]

The plugin dependencies plugin/feature has been presented (so far) as a way to define plugin dependencies - there has been no distinction made between wordpress.org hosted plugins and non-hosted plugins. If this is changing to support only wordpress.org hosted plugin dependencies, it should be made clear to plugin authors and users.

js.

[Otto42]

Replying to jsmoriss:

The plugin dependencies plugin/feature has been presented (so far) as a way to define plugin dependencies - there has been no distinction made between wordpress.org hosted plugins and non-hosted plugins. If this is changing to support only wordpress.org hosted plugin dependencies, it should be made clear to plugin authors and users.

This is about the dotorg plugin directory. It has nothing to with the feature of adding dependencies in core. The code for the core will not necessarily have to change at all, depending on how discussion goes.

[jsmoriss]

This is about the dotorg plugin directory. It has nothing to with the feature of adding dependencies in core. The code for the core will not necessarily have to change at all, depending on how discussion goes.

I'm pretty sure that I haven't see any mention of the "Requires Plugins:" header value having to be a wordpress.org plugin, so if this is now the case, it should be made clear to plugin developers - otherwise, a plugin developer may list a plugin in the "Requires Plugins:" header that is not hosted on wordpress.org, and suddenly find their plugin closed.

js.

[jsmoriss]

Personally, I don't think using the dependency plugin as a way to handle plugin deprecations is a good idea. WordPress has always had a problem with plugin deprecation, and this should be addressed, but I don't think it should be half baked into a dependency feature. Deprecation and dependencies are two different things and should be handled separately.

js.

[Otto42]

Replying to jsmoriss:

I'm pretty sure that I haven't see any mention of the "Requires Plugins:" header value having to be a wordpress.org plugin, so if this is now the case, it should be made clear to plugin developers - otherwise, a plugin developer may list a plugin in the "Requires Plugins:" header that is not hosted on wordpress.org, and suddenly find their plugin closed.

Correct, that's why we want to adjust the directory to show them an error. To let them know what is broken about their dependency and why it does not work. To prevent them from submitting a plugin with a invalid dependency in the first place. That is what this ticket is about.

Regarding your other comment about deprecations, I have absolutely no idea what that means. This ticket has nothing at all to do with that.

[afragen]

Otto, the dependency isn’t invalid, it’s simply not available from dot org.

Just like a dev who advertises their premium plugin from their dot org plugin, reviews based on that stand. A poor experience will be the developer’s issue and they should provide information. Having a populated plugin card provides that information.

Obviously until we can find some compromise on how to provide this data I wouldn’t recommend developers add the headers for non dot org plugins. It is my hope that when a compromise is reached they will be able to provide that data and the experience will be nearly identical to a dependency from dot org.

[afragen]

@dd32 to answer the these questions directly.

To prepare for this, we could:

• Block plugin submissions and updates which reference dependencies which are not valid

I think we need to discuss what it means to have a valid dependency. My opinion is that if the dependency exists somewhere that the user can install it, it is valid. It may take the user purchasing and installing a premium plugin but this is no different for add-ons for Gravity Forms or WPML that currently exist.

• Block plugin submissions which use the Dependencies feature but are not Requires WP >= 6.3

Plugins can still use the Plugin Dependencies feature plugin for compatibility. But certainly a response from the plugin review team indicating this would be in order with a recommendation to update to Requires at least: 6.3.

• Potentially delist existing plugins when the dependencies become unavailable (ie. Required plugin is removed from the directory, a plugin which requires that plugin should not be installable)

I don't think a plugin should be delisted. If a plugin dependency is not available and not installed/active, the dependent plugin will automatically be deactivated and will not be able to be activated until the dependency is met. Again, as long as the dependency exists and is installable by the user the dependent plugin is usable.

[dd32]

I think there's a potential disconnect between what the header means (Both to the team implementing it, what others think the team is building, and what I think the header means), what the WordPress.org plugin directory is, and what should be acceptable for a hosted WordPress.org plugin.

• Block plugin submissions and updates which reference dependencies which are not valid

I think we need to discuss what it means to have a valid dependency.

I agree.

My opinion is that if the dependency exists somewhere that the user can install it, it is valid. It may take the user purchasing and installing a premium plugin but this is no different for add-ons for Gravity Forms or WPML that currently exist.

I agree. That's a valid use of the header.
However. That doesn't answer the question of "Is this a plugin that should be hosted by WordPress.org"; Just because we can, doesn't always mean we should.

Obviously though, this is a valid use-case where a WordPress.org-hosted free plugin extends a non-WordPress.org-hosted non-free plugin.

That however, doesn't necessarily mean it's something that we directly need support. If the not-WordPress.org-hosted plugin is either a) not-necessary for it to work or b) is not GPL-compliant, then that free extension should arguably not be hosted by WordPress.org.

This is a situation where we'd likely have to have some manual process in place, or more likely probably through a whitelisted set of dependencies that plugins are allowed to use. I don't see any alternative here.

But there's another angle; A WordPress.org-hosted free plugin that requires a non-WordPress.org-hosted free plugin/library. This isn't something that we'd likely want to support at all, while technically the end-user can resolve this themselves, that doesn't mean this is a plugin we should want to offer to others to install through the plugin directory.

Basically; Use of the dependencies feature should not be possible to be used to bypass ​plugin guideline 8 - cannot install code from 3rd parties.

• Block plugin submissions which use the Dependencies feature but are not Requires WP >= 6.3

Plugins can still use the Plugin Dependencies feature plugin for compatibility. But certainly a response from the plugin review team indicating this would be in order with a recommendation to update to Requires at least: 6.3.

Again, plugin directory guidelines can (and are) more strict than 'what is possible' often. This is to prevent issues where plugin authors just 'do things wrong' which happens far more often than you'd think.

If anything, the 6.3+ remark is to ensure that someone who is using it actually understands the purpose of the header.

If you take your previous example of a free plugin extending a premium plugin, a plugin by adding the dependencies header and increasing the requires-at-least header would prevent updates being sent to WordPress < 6.3 sites. That is problematic, but not unheard of.

• Potentially delist existing plugins when the dependencies become unavailable (ie. Required plugin is removed from the directory, a plugin which requires that plugin should not be installable)

I don't think a plugin should be delisted. If a plugin dependency is not available and not installed/active, the dependent plugin will automatically be deactivated and will not be able to be activated until the dependency is met.

This goes back to the first point of this comment; "what is the feature", and I think there's a disagreement of what it is.
If plugin B on WordPress.org depends on plugin A, and plugin A is removed, we shouldn't offer sites to install plugin B. Simple as that. If plugin A can still be found via GitHub, that's irrelevant for the directory, we don't want end-users having to hunt around for the dependency to fix that. Either the plugin works, or it doesn't.

---

Based on the discussion on this ticket, initially, I expect the implementation is going to have to err on the side of limited support, possibly seeing how it ends up being used, and going from there.

It's likely we'll have to explicitly block any not-WordPress.org items, followed by allowing whitelited non-wporg items, and finally resolving the issue of what happens when a dotorg-hosted plugin is removed from the directory.

---

The core feature can be as expansive as the core team decides to accept, I personally feel it's too permissive at present (and likely is not in the best interests of WordPress end-users, but that's personal opinion and doesn't sway my opinion on what is needed for WordPress.org), but the WordPress.org plugin directory will ultimately always only support a subset of it's functionality, as part of the philosophy of WordPress.org and the plugin directory aims of providing the best user experience.

[afragen]

Replying to dd32:

I think there's a potential disconnect between what the header means (Both to the team implementing it, what others think the team is building, and what I think the header means), what the WordPress.org plugin directory is, and what should be acceptable for a hosted WordPress.org plugin.

In my initial post, ​Feature Project: Plugin Dependencies, I clearly state the problems that this feature is hoping to solve. There was a tremendous amount of discussion in the original ticket #22316 as well as the original PR ideas, which have subsequently been closed in favor of the current ​PR3032.

Fundamentally, this feature is about making plugin dependencies behave and function in a similar manner. This frees the plugin developer from checking to see if the dependency is installed and active.

Plugin Dependencies is THREE things:

1. Ensuring that all dependencies are installed and active before allowing a dependent plugin to be activated.
2. Ensuring that all dependent plugins are deactivated before a dependency can be deactivated.
3. A convenient way to install dependencies.

Dependencies are listed in the Dependencies tab of the Install Plugin page. Only dependencies that come from the plugin repository will be allowed to be installed directly from the Dependencies tab.

If a plugin dependency is not found in the plugin repository a generic plugin card is created with instructions for the user to ask the plugin developer where to find and install the dependency.

Plugin Dependencies is planned for 2 parts. The above is part 1.

@dd32 what is your understanding of the Plugin Dependencies feature?

• Block plugin submissions and updates which reference dependencies which are not valid

I think we need to discuss what it means to have a valid dependency.

I agree.

My opinion is that if the dependency exists somewhere that the user can install it, it is valid. It may take the user purchasing and installing a premium plugin but this is no different for add-ons for Gravity Forms or WPML that currently exist.

I agree. That's a valid use of the header.
However. That doesn't answer the question of "Is this a plugin that should be hosted by WordPress.org"; Just because we can, doesn't always mean we should.

Obviously though, this is a valid use-case where a WordPress.org-hosted free plugin extends a non-WordPress.org-hosted non-free plugin.

If we currently host these plugins in the plugin repository, and we do, why would the addition of a header to opt into the Plugin Dependencies feature now make them ineligible?

That however, doesn't necessarily mean it's something that we directly need support. If the not-WordPress.org-hosted plugin is either a) not-necessary for it to work or b) is not GPL-compliant, then that free extension should arguably not be hosted by WordPress.org.

1. By definition a required plugin is required. This feature is not for a nice to have add-on or a recommended plugin.
2. If the plugin repository is now trying to ensure that even peripherally related plugins must be GPL-compliant then I think that should be an addition to the Plugin Guidelines.

This is a situation where we'd likely have to have some manual process in place, or more likely probably through a whitelisted set of dependencies that plugins are allowed to use. I don't see any alternative here.

I, and I'm certain others, would be happy to help brainstorm the above idea.

But there's another angle; A WordPress.org-hosted free plugin that requires a non-WordPress.org-hosted free plugin/library. This isn't something that we'd likely want to support at all, while technically the end-user can resolve this themselves, that doesn't mean this is a plugin we should want to offer to others to install through the plugin directory.

We agree. Any plugin using this feature that is in the plugin repository will not be able to directly install the dependency from the Dependencies tab.

Basically; Use of the dependencies feature should not be possible to be used to bypass ​plugin guideline 8 - cannot install code from 3rd parties.

Agreed. And we know exactly how to ensure that this doesn't happen.

• Block plugin submissions which use the Dependencies feature but are not Requires WP >= 6.3

Plugins can still use the Plugin Dependencies feature plugin for compatibility. But certainly a response from the plugin review team indicating this would be in order with a recommendation to update to Requires at least: 6.3.

Again, plugin directory guidelines can (and are) more strict than 'what is possible' often. This is to prevent issues where plugin authors just 'do things wrong' which happens far more often than you'd think.

If anything, the 6.3+ remark is to ensure that someone who is using it actually understands the purpose of the header.

Since the ability to opt in to the Plugin Dependencies feature is simply a header comment. I'm not sure why the harder restriction. Especially as Plugin Dependencies feature plugin only requires WP 6.0. But I'm not really willing to fight this particular battle.

If you take your previous example of a free plugin extending a premium plugin, a plugin by adding the dependencies header and increasing the requires-at-least header would prevent updates being sent to WordPress < 6.3 sites. That is problematic, but not unheard of.

Again, since the opt in is only a header, nothing makes the plugin incompatible with earlier versions of WP, it only means they won't be able to take advantage of the Plugin Dependencies feature.

• Potentially delist existing plugins when the dependencies become unavailable (ie. Required plugin is removed from the directory, a plugin which requires that plugin should not be installable)

I don't think a plugin should be delisted. If a plugin dependency is not available and not installed/active, the dependent plugin will automatically be deactivated and will not be able to be activated until the dependency is met.

This goes back to the first point of this comment; "what is the feature", and I think there's a disagreement of what it is.
If plugin B on WordPress.org depends on plugin A, and plugin A is removed, we shouldn't offer sites to install plugin B. Simple as that. If plugin A can still be found via GitHub, that's irrelevant for the directory, we don't want end-users having to hunt around for the dependency to fix that. Either the plugin works, or it doesn't.

Please let me know your understanding of the feature. What you are describing here is precisely what currently exists and is allowed. If the Plugin Repository chooses not to host "add-on plugins", I believe that would be a new policy and would need to be publicized widely.

---

Based on the discussion on this ticket, initially, I expect the implementation is going to have to err on the side of limited support, possibly seeing how it ends up being used, and going from there.

Again, part 1 of the feature is only about dependencies in dot org and a generic plugin card for all others.

It's likely we'll have to explicitly block any not-WordPress.org items, followed by allowing whitelited non-wporg items, and finally resolving the issue of what happens when a dotorg-hosted plugin is removed from the directory.

I'm certain we can all have a great discussion about part 2 of Plugin Dependencies once that ticket is opened. I wasn't planning on creating that ticket until after part 1 has been committed. If you have concerns about what is described as Plugin Dependencies part 1, please let us know of them.

---

The core feature can be as expansive as the core team decides to accept, I personally feel it's too permissive at present (and likely is not in the best interests of WordPress end-users, but that's personal opinion and doesn't sway my opinion on what is needed for WordPress.org), but the WordPress.org plugin directory will ultimately always only support a subset of it's functionality, as part of the philosophy of WordPress.org and the plugin directory aims of providing the best user experience.

I understand and some of the design of this feature extends beyond the scope or the Plugin Repository. I would still like to know why you don't believe it to be in the best interests of WP end users.

Thanks for your concerns. We look forward to further discussions so that we can all come to a place where we think the end users receive the most benefit.

We are still working on Plugin Dependencies part 2. We are trying to provide the best user experience while mitigating the concerns of WordPress.org and the Plugin Repository.

[dd32]

Replying to afragen:

Obviously though, this is a valid use-case where a WordPress.org-hosted free plugin extends a non-WordPress.org-hosted non-free plugin.

If we currently host these plugins in the plugin repository, and we do, why would the addition of a header to opt into the Plugin Dependencies feature now make them ineligible?

It doesn't, as I said, it's a valid use-case. It was missed from my initial description here, but that doesn't convey intention, more of oversight.

That however, doesn't necessarily mean it's something that we directly need support. ![...]

1. By definition a required plugin is required. This feature is not for a nice to have add-on or a recommended plugin.

Correct; by definition, but that has not stopped people in the past on other platforms using dependency injection to require non-essential code that doesn't meet the guidelines of the platform it's on.

2. If the plugin repository is now trying to ensure that even peripherally related plugins must be GPL-compliant then I think that should be an addition to the Plugin Guidelines.

This is already the case AFAIK, even if it's not explicitly stated. IMHO it's covered as ​Guideline #1 - if a plugin was to extend upon a non-GPL compliant WordPress plugin it inherently violates that guideline, as it can't claim to be GPL compatible, being a derivative of a non-GPL-complying product.
A premium plugin can be GPL-compatible, even if not publicly available.

Any plugin using this feature that is in the plugin repository will not be able to directly install the dependency from the Dependencies tab.

Will it force the user to install it though? The technical difference between "Click here to install it" vs "Go here and install this on your site" is irrelevant.

A statement such as This plugin requires *Plugin Name* be installed to activate is different to You are required to install *Plugin Name* from *https://github.com/.....

Again, since the opt in is only a header, nothing makes the plugin incompatible with earlier versions of WP, it only means they won't be able to take advantage of the Plugin Dependencies feature.

For the purposes of WordPress support, we can safely ignore that the plugin exists. The plugin being present on a pre-core-merge site is irrelevant in this situation.
If the Header conveys required plugins, and the plugin is targeting older versions, they can use their own polyfill or existing admin notice. Progressive enhancement.

If plugin B on WordPress.org depends on plugin A, and plugin A is removed, we shouldn't offer sites to install plugin B. Simple as that. If plugin A can still be found via GitHub, that's irrelevant for the directory, we don't want end-users having to hunt around for the dependency to fix that. Either the plugin works, or it doesn't.

[..] What you are describing here is precisely what currently exists and is allowed.

You are conveniently skipping that this is focused on the use-case where both Plugin A AND B are WordPress.org hosted plugins. This comment is not intended on focusing on the use-case of a whitelisted non-WordPress.org-hosted-plugin.

[dd32]

In 12532:

Plugin Directory: Import the Requires Plugins header on plugin import.

At present this is not used for anything, and is for future purposes.

See #6921, ​https://core.trac.wordpress.org/ticket/22316.

[dd32]

In 12533:

Plugin Directory: Store required plugins as an array, and an additional flag for when dependencies are not met by published WordPress.org-hosted plugins.

See #6921, [12532].

[dd32]

In 12534:

Plugin Directory: When a plugin has an empty or malformed Requires Plugins header, don't store empty slug keys.

See #6921.

[costdev]

Any plugin using this feature that is in the plugin repository will not be able to directly install the dependency from the Dependencies tab.

Will it force the user to install it though?

The dependent plugin can be installed but will not be able to be activated unless all dependencies are installed and activated.

For WordPress.org-hosted dependencies, each will have a clickable Install button on the Dependencies tab - very much like the Popular tab, except it's a list of known dependencies.

For non-WordPress.org-hosted dependencies, the plugin card shown on the Dependencies tab will not have a clickable Install button. Therefore, if the user wants to activate the dependent plugin, they'll first have to go find the dependency, then install and activate it.

So, after installing a dependent plugin, the user can choose either to install and activate all dependencies, or they can choose to remove the dependent plugin. Plugin Dependencies doesn't force a user to do anything against their will.

It only serves to standardize and simplify:

1. informing users of dependencies.
2. preventing activation of dependents with unmet dependencies.
3. deactivating dependents with unmet dependencies (e.g. if deleted from the plugins directory).
4. viewing all dependencies.
5. Part 1: clicking to install each WordPress.org-hosted dependency without first having to search for each one individually.

These are usually handled by dependent plugin authors with different implementations and mixed results, so we're not introducing new functionality, just standardizing and simplifying its implementation, with added protection for dependent plugins whose authors may miss potential Fatal Error conditions.

There are no automatic installations or activations, only automatic deactivations, similar to what Core already has.

---

Different question: @dd32 I see you're skipping empty or malformed slugs. Just wondering if this includes malformed/invalid slugs like --howdy--&-admin--, etc? If not, would that be useful to do here so that invalid slugs aren't stored/used in searches? This is probably already handled elsewhere on WordPress.org, so it might not be useful to preg_match() or similar here - I don't know, hence my question. 🙂

[dd32]

In 12538:

Plugin Directory: Ensure that the specified slug matches the slug found on WordPress.org.

See #6921, [12533].

[dd32]

In 13233:

Plugin Directory: Dependencies: Don't import plugins which specify invalid dependencies.

See #6921.

[dd32]

In 13234:

Plugin Directory: Store errors encountered during the plugin import process.

See #6921, #6108.

[dd32]

In 13238:

Plugin Directory: Add warnings generated during a plugin import to an alert on the plugin page to the author.

See #6108, #7477, #6921.

[dd32]

In 13241:

Plugin Directory: API: Prepare to include the Plugin dependencies in the update api.

See #7483, #6921.

[dd32]

Marking as fixed; Any requests to expose plugin dependencies on plugin pages or handle them differently than we do should be in a new ticket.