15 Comments

  1. Trevor Nelmes

    I raised this issue months ago, maybe nearly a year ago, calling for a dependency/third part asset manager to be built into core. The dependency/asset should be loaded in the same way we add drop ins. These should be maintained by the author of same. Each one has a universal ID which should only be allocated by a WP team, managing a dependency/asset repository from which they can be loaded/updated. Each theme/plugin that uses a dependency can then flag that it needs a particular dep/asset and will not activate until they are installed/activated (possibly with the option to install/activate). WP uses this data to load the dep/asset only once.

    And what did the WP team say? Well, I guess you can guess.

    Report

    • Peter Suhm

      It’s a dillemma. Stuff like this can end up becoming very complicated.

      For now, my main agenda is to make people aware of it! :-)

      Report

    • Gary Jones

      That sounds a little like what http://tgmpluginactivation.com/ does, and there are plans to create a version that would be suitable for inclusion in core (via a feature plugin).

      Report

      • Kalen Johnson (@Kalenjohnson)

        TGM Plugin activation is just for making sure other plugins are installed and activated. It’s a form of being able to include third-party code, and does use WP to handle it. However, it doesn’t cover any third-party PHP packages the same way Composer does, or third-party JavaScript like npm or Bower does. So there is still a lot of work needed to be done to create a developer-friendly ecosystem that allows for third-party code.

        Report

    • Alec Kinnear

      Thanks for trying Trevor. Alas, we’ve run into similar attitude when trying to help improve core (for example running multisite in a directory).

      Dependencies are extremely trying. With our video player FV Player we are highly dependent on jQuery. It’s amazing how many plugins break even jQuery by reloading their own version (we count on the latest version, which comes loaded by default in WordPress itself). I can only imagine how hard it is to get clean performance when reusing parts of other people’s plugins within your own plugin.

      Conflict resolution (naming conventions) should be built into these bits and pieces so you can’t end up fighting over data.

      It sounds like the namespaces solution is the only safe one. We’ll all be on PHP 7 very soon, so requiring PHP 5.3+ seems okay to me.

      Report

  2. Jonathan Wondrusch (@JWondrusch)

    I would love to see a shared Composer-like resource for WordPress assets. A really common would would be Stripe – imagine being able to use either stripe-php-1.18.0 if you want to provide 5.2 support, or the latest if not – or simply just version locking your dependencies :)

    I think the the major reason that this should be a priority for the Core team is how much potential it adds to the ecosystem.

    It does seem unlikely that it will even be a possibility until the minimum version of PHP gets bumped though :(

    Report

  3. Julien (@julien731)

    I have read you initial article and now this one. I completely agree with the point you make and having an “official” way to manage dependencies would be awesome.

    However, even though I saw you mentioned in the article that it is not a Composer issue, the beginning basically says the opposite. Many people won’t read the article entirely and will just remember “don’t use Composer for plugins development” which is not right.

    Report

  4. mobiteksp

    i use composer a lot.. and without any problems

    Report

  5. Otto

    Had anybody addressed how adding in things like “libraries” and such introduce issues, including security issues, to that faction that already doesn’t update in the first place?

    We’re still trying to get people to keep their themes and plugins and core up to date in an effective manner. Adding in third party libraries seems like a long-term recipe for a security disaster.

    Witness the large number of themes using outdated third-party sliders. How do you solve that problem, exactly? What is your solution to DLL-HELL?

    Report

    • James DiGioia (@JamesDiGioia)

      If the 3rd-party libraries are depended upon by plugins, then updating those libraries would be the responsibility of those plugins. Users wouldn’t have to deal with them. Dealing with this in core wouldn’t add any mental overhead for end-users.

      Report

    • Julien (@julien731)

      That’s true @Otto, but isn’t it restrictive to only say that about 3rd party libraries? I mean, if someone releases a plugin on WP.org and never updates it, when a security issue arises, like say an XSS vulnerability with add_query_arg(), then the security issue remains…

      Updating plugins / themes is the responsibility of the author, and this includes updating 3rd party dependencies. Not updating a plugin is just like not updating a dependency in terms of risks IMO.

      Report

    • Coen Jacobs

      Otto, with all due respect, that’s completely unrelated to this issue. People will bundle libraries anyway, wether they do it via Composer or manually. Composer will just make it easier and following a proven standard, to bundle libraries. Security issues will always be there and need to be dealt with.

      Actually, using Composer will make it easier for plugin developers to keep their dependencies updated. It’s as simple as running ‘composer update’, compared to having to manually replace all the files of the bundled libraries in your plugin. I just realised that if we would install those dependencies on a server level (based on the dependencies of all active plugins, as my proof of concept assumes), we could update them without having plugins to push updates!

      Report

  6. Steveorevo

    I’m toying with the idea of writing conflict scanner plugin (perhaps “mu” for early binding). Would scanning all plugins’ respective composer.json files for dependencies, gather their version numbers, and the load position/priority of the plugin help point out? The plugin could then notify WordPress users of compatibility issues of shared dependencies. Even better would be to notify the plugin author if they are in conflict (when the site is running the latest version of their plugin and it’s a victim of latent loading that conflicts with another latest version plugin). Perhaps that would encourage authors to synchronize?

    Report

  7. Page Carbajal – Software Engineer

    This article was quite useful. I am actually running into this trap more often than not lately.

    Links and comments here have been greatly helpful. I do not know if a solution for this issue will be added to the core anytime soon. However an easier solution to this dependency management hell could be to pay closer attention to how the ClassLoader gets implemented.

    Yes it is not ideal to add our dependencies to the plugin package, however since there’s no better availability do date this is a necessary evil.

    Report

  8. Jason

    I have thought about this same issue. I think a solution would be to run a php parser that autoprefixes namespaces when your composer requires a new dependency. It may be possible that composer already has functionality like this but I doubt it.

    Report

Comments are closed.

%d bloggers like this: