Automatically install Plugin & Theme Dependencies.

[dd32]

Plugins that require other plugins, and Themes that require other themes (ie. Child themes) could be automatically install those dependencies when required.

Examples:

• Broken theme: https://playground.wordpress.net/?theme=skincare-brand&url=wp-admin%2Fthemes.php (Playground/Site works, just without the proper styles)
• Broken plugin: https://playground.wordpress.net/?plugin=block-ip-address-for-woocommerce&url=wp-admin%2Fplugins.php (Playground crashes upon attempting to activate the plugin, which is not allowable when dependencies are not met)

[adamziel]

@dd32 This would be a useful feature! Some thoughts:

• It would need to be a on/off switch to:
  • Keep the existing URLs working in the same way as they did so for
  • Support testing the case when the plugin is installed but one or more dependencies aren't met
• We'd need a dependency resolver. fetch() could be slow with dependencies going a few levels deep – could we have a wp.org API endpoint such as /dependency-graph/skincare-brand or even /dependency-graph?plugin[]=skincare-brand&plugin[]=woocommerce that would resolve the dependencies for us?
• WordPress doesn't seem to have a good way of indicating the supported version range of the required plugins. My plugin might depend on version 4.4.15 of another plugin, but the latest version of that plugin is 5.1.13 and the API is backwards incompatible. I'm not yet sure how to handle those scenarios.

[dd32]

This was partly an extension of #2580 (Which was why I first went down that rabbit hole, the name was a bonus).

It would need to be a on/off switch

Darn. But that makes sense as a basis of how playground is used. Would you expect this to be on or off by default?

WordPress doesn't seem to have a good way of indicating the supported version range of the required plugins.

This is specifically not provided by WordPress dependencies. Plugins should be graceful in their implementations. Likewise, Child themes shouldn't require a specific version of a parent theme. etc.

We'd need a dependency resolver.

If we use the API as above, we can add a dependency-graph to the API output, which is currently exposed as parent for themes (There can only ever be a singular dependency) and required_plugins for plugins - except this is only for that specific plugin, ie. A requires B, it doesn't include B requires C & D. We can expand that to include the recursive lookup (Which it should really be, but I don't think has ever been raised, nor am I aware of any plugins that have this)

[adamziel]

It would need to be a on/off switch

Darn. But that makes sense as a basis of how playground is used. Would you expect this to be on or off by default?

@dd32 I'd say off by default. It's a trade-off:

• As a developer, I want a fine-grained control over what's happening. No magic.
• As a user, I want Playground "just figure things out for me".

At the platform level, I'd rather offer low-level APIs that higher-order tools can pick up to build useful automations. We could also build some affordances into Playground UI itself, e.g. a dedicated error screen "this plugin couldn't be installed, it seems to have unmet dependencies, would you like to auto-install plugins X, Y, and Z, too?" or a query param plugin-with-dependencies=woocommerce.

This is specifically not provided by WordPress dependencies. Plugins should be graceful in their implementations. Likewise, Child themes shouldn't require a specific version of a parent theme. etc.

Warning: Huge tangent ahead

I get the argument, I'm not convinced how realistic that is. Here's how I understand it, and please correct me if any of those assumptions are wrong:

Once a plugin participates in a dependency graph in any way, it:

• Can never break BC in its future release, or else it will immediately break all its downstream dependencies.
• Must monitor its upstream dependencies for BC breakages daily, or else it may blow up one day.

Here's the story I imagine: Adam's FragileChildTheme sets Dion's PowerfulParentTheme v0.99 as a parent theme. FragileChildTheme uses the do_the_magic("yay!") function provided by the parent theme. Then, PowerfulParentTheme v1.0 gets released without the do_the_magic(string $arg) function. From that day, FragileChildTheme fails with a fatal error – it has no way of expressing "I'm only compatible with versions PowerfulParentTheme<1.0". It will continue failing until I identify the error, find a heuristic to express if( PowerfulParentTheme<1.0 ) { do_the_magic(); } else { new_way_of_doing_things(); } and release it.

Ideally, themes and plugins would not break BC, but in practice they do – even between WordPress and Gutenberg. About 3 years ago noone really knew which Gutenberg plugin versions are compatible with which WordPress versions despite the explicit "* Requires at least: 6.7" annotation. I once made this matrix to map which WP/GB combinations actually boot together:

Can we still revisit the concept of version pinning?

If we use the API as above, we can add a dependency-graph to the API output, which is currently exposed as parent for themes (There can only ever be a singular dependency) and required_plugins for plugins - except this is only for that specific plugin, ie. A requires B, it doesn't include B requires C & D. We can expand that to include the recursive lookup (Which it should really be, but I don't think has ever been raised, nor am I aware of any plugins that have this)

This would be amazing both for Playground and for WordPress core. Clicking "install plugin" in wp-admin could prompt the user "hey, this plugin requires a few other plugins – do you want to install them all together?" It would solve the problem of distributing php-toolkit – a set of libraries meant for consumptions in multiple plugins. I'm happy to start using the dependency graph API in Playground very soon after it's available.