[wp-trac] [WordPress Trac] #22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)

[WordPress Trac]

#22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
------------------------------------+---------------------
 Reporter:  Viper007Bond            |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  5.9
Component:  Plugins                 |     Version:  3.4.2
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+---------------------

Comment (by brianhenryie):

 I'm really surprised to have read all this and see no mention of [afragen
 /wp-dependency-installer](https://github.com/afragen/wp-dependency-
 installer) which addresses what the recent PR is addressing, although the
 PR's approach of using the plugin's header is neater. Here's an [example
 implementation](https://github.com/BrianHenryIE/woo-manage-fraud-
 orders/blob/address/src/Admin/class-dependencies.php).

 I've admonished a few plugin authors for writing `is_plugin_active()`
 checks that end in `die`, so to some extent this is an improvement.

 I certainly welcome a dismissable admin notice saying ~"WooCommerce is
 required, without it plugin-x will not work correctly, you should consider
 activating it."

 But I don't think there's a good reason to ''deny'' activating the plugin
 when e.g. WooCommerce is not active. The correct approach is to hook only
 to appropriate actions of the parent, and some sparse function checks. I
 know this isn't always available, I just today opened [an issue with
 Action Scheduler](https://github.com/woocommerce/action-
 scheduler/issues/749) with a feature request for better actions to
 facilitate this!

 If I want to install and activate a plugin, I should be able to activate,
 e.g. EasyPost shipping plugin, without being told I MUST also activate
 WooCommerce. I use that example because I use a third party EasyPost
 plugin for purchasing shipping labels – my plugin automates it, it
 provides the UI I need. Admittedly I am using and do need WooCommerce, but
 it's not hard to imagine another e-commerce plugin either forking
 WooCommerce or trying to work upon a compatible set of actions and filters
 to give itself access to the breath of relevant plugins that are already
 written.

 In the simplest case, I create a plugin which is really just a facade on
 WooCommerce (which is probably in my /vendor/ directory) such that all the
 WooCommerce classes are available, most of the functionality is being
 used, but my plugin's slug is ''brian-commerce'' instead. All
 WooCommerce's plugins CAN and SHOULD work, but if they have REQUIRED
 rather than SUGGESTED WooCommerce, then they will never work.

 I think this is antithetical to the philosophy of open source, as
 WordPress says in "Our Bill of Rights": The freedom to run the program,
 for any purpose.

 So, I do like the PR, but it should just suggest, not enforce.

 Composer is a different topic!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/22316#comment:168>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform