开发 Wordpress 插件时的第 3 方依赖冲突

Question

我正在开发一个使用 composer.. 的插件，这意味着它在插件文件夹中有一个供应商文件夹，其中包含 Guzzle HTTP 依赖项

在我们安装了这个插件的 wordpress 网站上，有一个现有的插件有 Guzzle HTTP

现在，当我们激活这个插件时，我收到如下错误：

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

我尝试安装插件加载顺序以强制“其他插件”在“我的插件”之前首先加载，当前错误发生在其他插件的资源上​​。这样，错误将在我们的自动加载中产生，我们可以捕获它。

不幸的是..插件加载顺序不起作用..

任何想法如何解决这个问题？

Answer 1

欢迎来到 WordPress 地狱。我们有 2018 年，WordPress 仍然没有任何依赖管理，仍然没有注意到 Composer 的存在。

WordPress 生态系统仅依赖于假设，即插件/主题的函数/类名称应该是唯一的。显然，将流行的第 3 部分 Composer 库与您的插件/主题一起分发是自找麻烦——当其他插件做同样的事情时，很容易发生名称冲突。没有什么好的办法可以摆脱这种局面。

如果您想要独立插件的防弹解决方案，您应该vendor使用插件前缀为目录中每个包的命名空间添加前缀，例如myplygin\vendor. 然后GuzzleHttp\Client变为myplugin\vendors\GuzzleHttp\Client，因此不存在名称冲突的风险。这将需要一些工作来为此编写脚本（或者您可以使用一些现有的解决方案，例如humbug/php-scoper），并且您可能会得到许多重复的依赖项（10 个插件可能会带来 10 次相同的库，但具有不同的命名空间），但这是将现代工具和模式集成到过时软件中的成本。

如果您正在为自己编写此插件并控制最终安装，您可以尝试使用 Composer 来安装 WordPress 及其插件。如果 3rd 方插件捆绑了一些 Composer 库，您仍然可能需要修复它们（通过分叉），但从长远来看，它应该简化很多事情，并且您可以避免为每个插件复制库。

Answer 2

根据设计，PHP和Composer假设您在受控环境中开发和分发代码。但是，当您在WordPress上发布插件或在Joomla上发布模块时，您会将代码分发到您无法控制其他作者安装的系统上。这种情况可能会导致名称冲突，例如Cannot redeclare GuzzleHttp\uri_template()....

要为多供应商设置准备代码，您必须为PHP 代码添加前缀，以避免名称冲突或版本冲突（首先加载具有不同版本的相同库）。例如，Guzzle 是一个众所周知且广泛使用的库，因此如果您发布包含它的插件，则必须在分发之前添加前缀。

乍一看，您可能认为仅给名称空间添加前缀就可以完成工作。但其他命名元素（例如全局函数和特征）也必须带有前缀，以避免所有可能的错误类型。

为了给 PHP 代码添加前缀，有一些工具或服务来执行任务：

• humbug/php-scoper。为文件/目录中的所有 PHP 命名空间添加前缀，以隔离 PHAR 中捆绑的代码。
• 接口实验室/命名空间。命名空间允许您重命名任何 Composer 包的命名空间。它的工作原理是向所有命名空间添加命名空间前缀。命名空间还为包名称添加前缀。然后它会生成一个名为“lib”的文件夹，您可以安全地将其包含在 WordPress 插件中。
• 科恩雅可布/莫扎特。WordPress 插件的开发人员工具：将所有项目依赖项包装在您自己的命名空间中。这可以防止与加载相同依赖项但版本不同的其他插件发生冲突。
• PHP 前缀。它是一项自动化在线服务，由复杂的基于规则的系统提供支持，可将前缀应用于 Composer 依赖项。在 中composer.json，您只需定义要应用的前缀，而不必担心具体细节。

免责声明：我是 PHP-Prefixer 的主要开发人员。