[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 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: installing WordPress.org-hosted dependencies without searching
 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. 🙂

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