[wp-meta] [Making WordPress.org] #6921: Prepare for Plugin Dependencies

[Making WordPress.org]

#6921: Prepare for Plugin Dependencies
------------------------------+---------------------
 Reporter:  dd32              |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:  needs-patch       |
------------------------------+---------------------

Comment (by afragen):

 Replying to [comment:19 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, [https://make.wordpress.org/core/2022/02/24/feature-
 project-plugin-dependencies/| 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 [https://github.com/WordPress/wordpress-develop/pull/3032|
 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.

 a. By definition a required plugin is required. This feature is not for a
 nice to have add-on or a recommended plugin.
 b. 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 [https://developer.wordpress.org/plugins/wordpress-org
 /detailed-plugin-guidelines/#8-plugins-may-not-send-executable-code-via-
 third-party-systems 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.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6921#comment:20>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org