另一个插件依赖关系讨论，这次两个提案

它已经超过九年以来，自最晚的Alex Mills在WordPress TRAC标题为插件依赖项(又一插件依赖性票)上打开了一张票.它不是最古老的类似功能请求，但它仍然是打开的.大多数前身都用"WONTFIX"标签关闭，这通常是棺材的最终钉子，也是如此.

票证的目标是创建一个系统，允许一个插件需要一个或多个其他人进行操作.依赖关系在编程世界中没有什么新鲜事.作曲家，标准的PHP包管理器，是转弯10岁的两周害羞.在JavaScript结束时，NPM已经发生了12年了，WordPress已经大量收到了核心代码.

但是，这些是开发人员工具.WordPress是为用户而构建的，解决插件依赖项需要在用户界面内发生.

ills在机票中写道:

自从我们查看插件依赖项以来已经几年了，而这似乎仍然是一个真正的人真正的人，特别是对于不是一个不是共享的功能插件本身.例如，一个不足以在核心的PHP库，但足够受到多个插件的流行.

目前可能更相关.在过去的十年中，许多插件已经增长了自己的附加插件生态系统.确保安装依赖项的责任通常落在最终用户的肩部上.开发人员提出内部解决方案，以便于这种负担，而TGM插件激活脚本已成为 De Facto 标准.

依赖于依赖项几乎是一个在任何插件项目中给出的，至少在平均构建工具设置中播放了一部分.可能是安全的，说明更多的WordPress插件开发人员在需要今天需要第三方代码的环境中编码，而不是他们在WordPress的形成年份.

对于一直努力实现现代化的平台，解决插件依赖性就像在火箭船上到狂野的西方旅行.

这个想法并非没有先例的WordPress世界.虽然它是一个不太复杂的案例，Wordpress自动下载并在从目录中安装子主题时安装父级.

插件依赖系统的许多参数属于附加方案.最明显的用例是Woocommerce，数十几个延伸的延伸.

但是，其他方案可以深入了解开发人员在WordPress顶部的构建是融合框架和图书馆.现在，插件作者必须在他们的项目中捆绑第三方代码，并确保如果在完全单独的插件中已捆绑在一起，则不会加载.

代码重用是编程的基石之一.目前，捆绑代码库或脚本没有标准.而且，WordPress插件目录不允许新框架和类似库.

对于透明度，我至少有十几个项目适合这个类别，坐在其他人可以使用的包裹.因此，我至少有游戏中的一些皮肤，我相信许多其他人都在同一条船上.

WordPress Github存储库上有两个Pull请求，用于插件依赖系统.还有一个Google Docs文件，它详细概述了两个提案.

每个都要求开发人员通过插件标头定义依赖项.以下是需要Woocommerce和Gutenberg的示例:

<?php
/**
 * Plugin Name: Sample
 * Requires Plugins: woocommerce, gutenberg
 */

这两种方法都是相似的.从用户的角度来看，它们会:

• 显示一个管理员注意，有依赖关系要安装.
• 禁止插件的删除或停用，而不删除或取消激活他们所需的插件.
• 输出消息在管理插件上的插件卡.

第一个实施是由Ari Stathopoulos.它创建一个"激活队列"，只有在用户激活所需的插件后，只能激活插件.它还允许用户取消激活请求.

激活依赖关系的通知.

Andy Fragen的解决方案在插件管理屏幕上创建一个新的"依赖性"选项卡.这种方法将自动停用具有未满足依赖性的任何插件，并通过管理通知向用户通知.

他还在github上单独发布了插件依赖关系标签项目.

插件依赖关系选项卡.

两者仍然存在一些实际问题.即，当支持版本之间存在冲突时会发生什么?当前的建议将其留给插件，不要在用户端中打破任何东西.

可能是所有这一切的最不自信心的曲线.但是，很可能是最实际的路线.此外，WordPress不会解决其当前狂野的西部系统中的版本冲突.

依赖解决方案也可能是更多代码现代化的机会.欢迎查看更多开发人员拥抱界面(合同)等功能.与尊贵的家属编码意味着通过不同于任何给定项目是独立插件的架构问题的思考.