我遇到了一个完全可以预测但令人难以置信的烦人且难以解决的问题。
我一直致力于开发WordPress插件的PHP框架。它使用Composer进行依赖关系管理。当然，问题是，如果你在同一个WordPress安装中有我的框架的两个实例，你有两个供应商文件夹，以及框架所需的任何软件包的两个副本。这导致了一个错误。
该框架作为一个单独的插件，然后由构建在其上的任何应用程序/插件继承。
是否将供应商文件夹移到核心框架文件夹
问题：如果我有两个composer.json文件和两个componer.phar文件写入同一个供应商文件夹并使用同一个自动加载器，我不知道会发生什么。大概这不太好。除此之外，它并不能解决与composer包冲突的问题，这些包可以被我试图处理的之外的任何其他脚本或插件使用。
所以我被卡住了。这是一个可以解决的问题，还是PHP固有的问题？
Composer并不是真的要在同一个项目中多次使用。另一方面，它也并没有什么严重的问题，但您失去了它的依赖性功能，需要将其视为WordPress环境中依赖性的一般情况。
换句话说，如果你不做依赖性Composer的方式和WordPress根本不做依赖，这将成为你个人的问题如何处理它。
我不知道如果我有两个composer.json文件和两个componer.phar文件写入同一个供应商文件夹并使用同一个自动加载器会发生什么
我不明白为什么如果你使用多个composer安装，供应商文件夹会是一样的。。。你能详细说明一下你是如何构建的吗？它是供公共还是私人使用的？
我不太熟悉Composer或您正在使用的插件框架，但一般来说，在WordPress插件中避免函数/类名冲突是通过以下方式完成的：
-
假设你的插件（例如MyCoolPlugin）是面向对象编写的，例如作为一个名为MyCoolPlugin的类，你可以将助手类/库作为MyCool插件的子类。
-
class_exists（），这是PHPs查找类是否已定义的方法。假设你的助手类如下：
class MyHelperClass{
}
在每个插件中声明类之前，您可以使用以下检查：
if(!class_exists('MyHelperClass')){
class MyHelperClass{
}
}
当然，这里有一个权衡，因为只有类的第一个实例将通过我们的WordPress使用。例如，如果你有两个插件，其中包含两个不同版本的helper类，那么在任何给定的时刻，它们中只有一个是活动的并且可用。
- 全局变量，例如帮助文件中的
define('MY_HELPER_IS_LOADED', true);（如果您通过include()或require()包含它们）。然后，在每个包含的帮助文件开始时，使用if(defined('MY_HELPER_IS_LOADED')) return;进行检查，这将导致当前请求的包含/要求文件不包含在内
同样，上面的策略通常在PHP中使用，我不确定你的插件框架是如何设置的。