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