[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 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 [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].

 > > - 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.

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