Third party libraries/SDK: manage conflicts

  • Stefano Lissa

    (@satollo)


    3 years, 2 months ago

    Hi,

    lately, I’ve managed (but not resolved) on different sites the problem of third-party libraries loaded by different plugins and conflicting. Usually, it was the Amazon SDK. Searching the forum you can see how many reports there are about missing classes, missing methods, and so on. This usually is caused by autoloaders of two plugins mixing up classes from different SDK versions. Is not always so obvious to diagnose the problem and it usually ends in a “fatal error”.

    I would like to open a discussion to know your opinion about having, for example, a plugin providing one or more “common” SDK and other plugins relying on that one. Probably it would be just a “best practice” and an agreement between plugin/theme authors to ask the users to install it. Maybe a “WordPress Community” plugin. What do you think?

Viewing 1 replies (of 1 total)
  • Alan Fuller

    (@alanfuller)

    3 years, 1 month ago

    Currently, with libraries that are not written well for the WP env (i.e. forward compatible and detecting if already loaded) and without the concept of shared libraries for WP plugins which isn’t going the happen for a long long while if ever the ‘best practice’ is to uniquely namespace each plugin’s libraries that may conflict. I think your thoughts are along the lines of a shared / centralized library, this has issues in terms of 1) who would maintain it 2) Exceptions to plugin policy ( non functional / framework plugins not currently allowed ). AFAIK the plugin team prefer that plugins are self contained with their own copy of libraries.

    This requires plugin authors to 1) recognize that there is an issue 2) take action.

    There are a couple of tools that plugin developers can use – PHP-scoper https://github.com/humbug/php-scoper – personally I found this did more than needed and too complex to get working well and – Namespacer – https://github.com/Interfacelab/namespacer I use a fork of this one in my plugin build process. To date the only conflicting library I have had to deal with is the Stripe SDK – but I’m sure there are many others.

    • This reply was modified 3 years, 1 month ago by Alan Fuller.
    • This reply was modified 3 years, 1 month ago by Alan Fuller.
Viewing 1 replies (of 1 total)

The topic ‘Third party libraries/SDK: manage conflicts’ is closed to new replies.