开发Wordpress插件时的第三方依赖性冲突 [英] 3rd party dependency conflict in developing Wordpress Plugin
问题描述
我正在开发一个使用composer ..的插件.这意味着它在plugin文件夹中有一个vendor文件夹，其中包括Guzzle HTTP依赖项
I am developing a plugin that used composer.. meaning it has a vendor folder inside the plugin folder which includes Guzzle HTTP dependency
在wordpress网站上，我们安装了此插件，现有的插件具有Guzzle HTTP
On wordpress site we installed this plugin, there is an existing plugin that has Guzzle HTTP
现在，当我们激活此插件时，出现类似以下错误:
Now when we activate this plugin i am getting an error something like this:
Fatal error: Cannot redeclare GuzzleHttp\uri_template() (previously declared in /nas/content/staging/project/wp-content/plugins/my-plugin/vendor/guzzlehttp/guzzle/src/functions.php:17) in /nas/content/staging/project/wp-content/plugins/other-plugin/includes/lib/aws-sdk/GuzzleHttp/functions.php on line 31
我尝试安装插件加载顺序"以强制其他插件"在我的插件"之前先加载 当前，该错误发生在另一个插件的资源上. 这样，错误就会在我们的自动加载中产生，并且我们可以捕获该错误.
I tried installing Plugins Load Order to force the 'other-plugin' to load first before 'my-plugin' currently the error is happening on the other-plugin's resources. this way, The error will yield in our autoload and we can catch that.
很不幸..插件加载顺序不起作用..
unfortunately.. Plugins Load Order did not work..
有什么想法可以解决这个问题吗?
any ideas how to solve this?
推荐答案
欢迎使用WordPress地狱.我们有2018年，WordPress仍然没有任何依赖项管理，并且仍然没有注意到Composer的存在.
Welcome to WordPress hell. We have 2018 and WordPress still does not have any dependency management and still didn't notice Composer existence.
WordPress生态系统仅依赖于假设，即功能/类的插件/主题名称应该是唯一的.显然，用您的插件/主题分发流行的第3部分Composer库会带来麻烦-当其他插件也这样做时，很容易发生名称冲突.解决这种情况没有好办法.
WordPress ecosystem simply relies on assumption, that functions/classes names of plugins/themes should be unique. Obviously distributing popular 3rd-part Composer libraries with your plugin/theme is asking for trouble - it is easy to get names collision when other plugin is doing the same. There is no good way out of this situation.
如果要为独立插件提供防弹解决方案，则应在vendor目录中每个软件包的名称空间前加上插件前缀，例如myplygin\vendor.然后GuzzleHttp\Client变为myplugin\vendors\GuzzleHttp\Client，因此不存在名称冲突的风险.这将需要一些工作来为此编写脚本(或者您可以使用一些现有的解决方案，例如 humbug/php-scoper )，您可能会得到很多重复的依赖项(10个插件可能带来10次相同的库，但是具有不同的名称空间)，但这是将现代工具和模式集成到过时的软件中的成本.
If you want a bulletproof solution for standalone plugins, you should prefix namespaces of every package in your vendor directory with plugin prefix, for example myplygin\vendor. Then GuzzleHttp\Client becomes myplugin\vendors\GuzzleHttp\Client, so there is no risk of name collisions. This will require some work to write script for this (or you may use some existing solutions, like humbug/php-scoper), and you may get many duplicated dependencies (10 plugins may bring the same library 10 times, but with different namespaces), but this is the cost of integrating modern tools and patterns into outdated software.
If you're writing this plugin for yourself and you're controlling final installation, you may try to use Composer for installing WordPress and its plugins. You still may need to fix 3rd-party plugins (via forking) if they're have bundled some composer library, but in the long run it should simplify many things and you may avoid duplicating libraries for every plugin.
这篇关于开发Wordpress插件时的第三方依赖性冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
