作曲家命名空间在WordPress插件开发中的碰撞

Question

我遇到了一个完全可预测但令人难以置信的烦人和难以解决的问题。

我一直在研究开发WordPress插件的PHP框架。它使用Composer进行依赖管理。当然，问题在于，如果在同一个WordPress安装中有两个我的框架实例，那么您有两个供应商文件夹以及框架所需的任何软件包的两个副本。这导致错误。

该框架作为一个单独的插件，然后由任何构建它的应用程序/插件继承。

将供应商文件夹移动到核心框架文件夹？

问题：我不知道如果我将两个composer.json文件和两个composer.phar文件写入同一供应商文件夹并使用相同的自动装载器，会发生什么情况。想必它不会好。除此之外，它不能解决与作曲家软件包相冲突的问题，这些软件包可以被我想要处理的任何其他脚本或插件使用。

所以我卡住了。这是一个可以解决的问题，还是它只是固有的PHP？

Answer 1

我不是很familar与作曲家或正在使用的插件框架，但在一般 - 避免功能/在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中，我不确定你的插件框架是如何设置的。

Answer 2

作曲家并不是真的要在同一个项目中多次使用。另一方面，它也没有什么可怕的错误，但是你失去了它的依赖关系特性，并且需要把它看作是在WordPress环境中依赖的一般情况。

换句话说 - 如果你没有做依赖关系作曲家的方式和WordPress根本就没有依赖关系，它将成为你的个人问题如何处理它。

我不知道如果我有两个composer.json文件，并写入同一供应商的文件夹，并使用相同的自动加载

我不继为什么是两个composer.phar文件会发生什么如果您使用多个作曲家安装，供应商文件夹将相同...您能否详细说明您如何构建它并且是为了公共还是私人使用？