jdp*_*jdp 10 php wordpress composer-php
我遇到了一个完全可预测但令人难以置信的烦人且难以解决的问题.
我一直在研究用于开发WordPress插件的PHP框架.它使用Composer进行依赖关系管理.当然,问题是如果你在同一个WordPress安装中有两个我的框架实例,你有两个供应商文件夹,以及框架所需的任何软件包的两个副本.这会导致错误.
该框架作为一个单独的插件运行,然后由构建在其上的任何应用程序/插件继承.
将供应商文件夹移动到核心框架文件夹？
问题:我不知道如果我有两个composer.json文件和两个写入同一供应商文件夹并使用相同自动加载器的composer.phar文件会发生什么.大概这不会是好事.除此之外,它没有解决与作曲家包冲突的问题,可以被我正在尝试处理的任何其他脚本或插件使用.
所以我被卡住了.这是一个可以解决的问题,还是仅仅是PHP固有的问题？
Composer并不是真的意味着在同一个项目中多次使用.另一方面,它也没有什么特别的错误,但是你失去了它的依赖特性,需要像在WordPress环境中那样对待依赖的一般情况.
换句话说 - 如果你没有依赖于Composer方式而且WordPress根本没有做依赖,那么如何处理它就成了你个人的问题.
我不知道如果我有两个composer.json文件和两个composer.phar文件写入同一个供应商文件夹并使用相同的自动加载器会发生什么
如果你使用多个作曲家安装,我不会理解为什么供应商文件夹是相同的...你能详细说明你如何构建它,它是否适合公共或私人使用？
我不太熟悉 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;，这将导致当前请求的包含/要求文件不被包含。同样，上述策略通常在 PHP 中使用，我不确定你的插件框架是如何准确设置的。