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

WordPress Trac noreply at wordpress.org
Fri Nov 3 09:19:34 UTC 2017

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

Comment (by MikeSchinkel):

 Replying to [comment:81 ideag]:
 > Regarding versioning, I think WordPress should always update libraries
 to the latest ''stable'' version. If a new version of the library comes
 out, WordPress would update it the same way it updates itself, themes,
 plugins and translations. And plugin developers would need to stay up to
 date with that. The same way they have to stay up to date with core API's
 and Core version of jQuery, etc. I know that's a bit idealistic, but I
 think this would be good for the ecosystem as a whole. And Core would not
 need to deal with the mess of 12 different plugins requiring 12 different
 versions of the same library.

 While I agree that it is theoretically ideal I don't think such a strategy
 could ever be practical.

 One of WordPress' core principles is to minimize problems for end users,
 and part of that means no breaking things that the end users have no
 expertise to fix.  So if a plugin requires version 1.x of a library and
 core were to force install 2.x of the library -- which by definition would
 include a breaking change -- then the end user would feel the pain and not
 have the knowledge or skill to fix the problem ''(it might require major
 code changes in the plugin or theme!)''

 In the case of the plugin or theme developer they could be using an older
 version of a library that is perfectly acceptable for their needs and for
 which there are no security concerns. Or many they are using an older
 version because the older on is better!  For example it is possible that
 v2.x of a library requires twice the memory of v1.x and thus the developer
 chooses to stick with the earlier version of the library. Or the newer
 version could have bugs the older version does not have!

 And let's say all plugins on the site use v1.x out of choice so it would
 be a very bad idea to force them both to a breaking change in v2.x just
 because it is a newer version.

 Plugins and theme choices are the domain of the end user but libraries are
 the domain of the developer so I think whatever would happen with
 libraries would need to be 100% invisible to end users and library support
 should cater to the needs of developers, not end-users. And forcing
 upgrades could potentially cause problems for both without certain benefit
 in many cases.

 Bottom line, whatever is done, if anything is done, it has to be pragmatic
 and have almost zero possibility of negatively impacting end users.

 Anyway, #jmtcw

 P.S.The more I think about it the more I wonder if we shouldn't use add
 our own namespaces to libraries so that plugins could use different
 versions of the same libraries and just handle it that way?

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

More information about the wp-trac mailing list