[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):

 Replying to [comment:20 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. ![...]
 >
 > a. 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.

 > 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 already the case AFAIK, even if it's not explicitly stated. IMHO
 it's covered as [https://developer.wordpress.org/plugins/wordpress-org
 /detailed-plugin-guidelines/#1-plugins-must-be-compatible-with-the-gnu-
 general-public-license 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.

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