开发 Wordpress 插件时的第 3 方依赖冲突 [英] 3rd party dependency conflict in developing Wordpress Plugin

查看:45
本文介绍了开发 Wordpress 插件时的第 3 方依赖冲突的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个使用 composer.. 的插件,这意味着它在插件文件夹中有一个 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 GuzzleHttpuri_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 目录中为每个包的命名空间添加插件前缀,例如 myplyginvendor.然后 GuzzleHttpClient 变成 mypluginvendorsGuzzleHttpClient,所以不存在名称冲突的风险.这将需要一些工作来为此编写脚本(或者您可以使用一些现有的解决方案,例如 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 myplyginvendor. Then GuzzleHttpClient becomes mypluginvendorsGuzzleHttpClient, 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.

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

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 插件时的第 3 方依赖冲突的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆