search

WordPress / wp-plugin-dependencies

WordPress Feature Project: Plugin Dependencies
https://make.wordpress.org/core/2022/02/24/feature-project-plugin-dependencies/
MIT License
69 stars 9 forks source link

Common Libraries #7

Open alanef opened 2 years ago

alanef commented 2 years ago

There are effectively two types of plugin that I can think of that has dependencies

  1. addon plugins - for example a plugin that adds features to WooCommerce

  2. plugins that use other plugins as libraries, e,g, using CMB2

I want to talk about type 2.

I think that 'new 'plugins submitted as frameworks or libraries are no longer acceptable / frowned up

What many plugins do is include third party open source libraries, indeed this is possible with CMB2, but there are many other libraries such as the Stripe PHP SDK in common use.

What this then means each plugin loads their own copy of the libraries and unless they are specifically designed for WP this can result in conflicts ( e.g. different versions of the Stripe PHP SDK are not compatible - so require them to be re-namespaced to avoid conflict ).

What I think would be a good idea is to have curated set of the most common third party libraries and a WordPress driven autoloading subsystem for these so only the library is loaded.

I do realise this changes a dynamic of plugin in that they currently only have to use WP core libraries and introducing third party libraries starts to get complex in terms impact of change, however today we have the issue of 'plugin conflicts' Also a security fix to a common third party library can be done once rather than chasing say 1,000 developers.

That is my thoughts so wanted to at least bring it up here.

afragen commented 2 years ago

There is clearly an opportunity here but I don't think anyone is really interested in trying to create composer for WordPress. What you seem to be describing is really a package manager like composer and not a plugin dependency system.

There is lots of discussion about this in one of the PR proposals.

alanef commented 2 years ago

They are sort of related, and yes it would be something like composer taht is a good way of describing it, although composer has a lot of features that wouldn't be required.

Not sure why anyone would not be interested. I'll look at the PR proposals. to get up to speed with the discussions.

the only thing stopping doing this as a custom solution at the moment is plugin guideline policies.

On the subject of plugin dependencies, if we ignore libraries, is there another use case beyond addons?

As if it addons only I can't actually see a need for a dependency system, either the master plugin is there and it's classes or hooks available or it is not.

So lets take the simple case of CF7 and Flamingo. If you install Flamingo to add on features to CF7 but don't install CF7 then simply flamigo doesn't do anything. Am I missing somethings? ( I probably am )

alanef commented 2 years ago

p.s. I can see the use-case for themes requiring plugins

alanef commented 2 years ago

Ah the PR objection to composer is an a objection to using composer as opposed to a plugin header for plugin dependencies.

Which I get. And the use case is pretty trivial for plugin dependencies, as a comment PR says it just saves developers the need to write some checks that the master plugin is available.

Ironically all that is needed is a simple library that does that for you, pass some args and job done - I think some one wrote one of those :)

afragen commented 2 years ago

I believe the other issue has a lot to do with version control of the "packages". Unfortunately as the plugin repo no longer supports frameworks it's not likely to happen.

afragen commented 2 years ago

The use case is for actual plugin requirements. As in I have a WooCommerce add on that requires WooCommerce.

In your example Flamingo requires CF7 in order to function.

lsl commented 2 years ago

[paraphrasing] addon plugins vs libraries+frameworks as plugins

The reason framework plugins are frowned upon seems to be based on poor user experience not any particular technical reason.

On a technical level I don't think there is any real difference between inter-dependent plugins and libraries. The only thing library plugins really need is a way to hide themselves from view in search or on plugins.php.

Once this feature project has figured out how to add and manage dependent addon plugins it should be relatively trivial to add an extra "is_library" flag to the plugin header and filter those out from search / plugins.php user views.

I don't think anyone is really interested in trying to create composer for WordPress.

I would like to see this [not here]. Composer or more precisely, semver, is inherently incompatible with WordPress plugin development.

scrobbleme commented 1 year ago

I like the idea of "libraries", but don't think this should be "possible" for 3rd-party developers.

Instead - for me - this is a WP core issue.

  1. Most of the time I need a "library" is for missing core parts. Specifically, WP is missing a "core framework" for custom fields (like ACF), advanced user roles and a proper UI framework for building unified forms (the block editor is already fine for building layouts).
  2. WP itself should offer a carefully curated list of useful and widely used 3rd party libraries (mostly JS libs). As of now, they just offer outdated list of jquery libs... I.e. select2 is used by a lot of plugins, so make it available for developers via enqueue_library or something like this.