自已故的亚历克斯·米尔斯在 WordPress Trac 上打开一张名为 插件依赖（又一个插件依赖票）. 它不是最古老的类似功能请求，但它仍然是开放的。 大多数前辈都被贴上了“wontfix”的标签，这通常是好主意和坏主意棺材里的最后一颗钉子。
票证的目标是创建一个系统，允许一个插件需要一个或多个其他插件才能运行。 依赖关系在编程世界中并不是什么新鲜事。 Composer 是标准的 PHP 包管理器，距离 10 岁还有两周。 在 JavaScript 端，npm 已经存在 12 年了，而 WordPress 已经在核心代码中大量采用了它。
但是，这些是开发人员工具。 WordPress 是为用户构建的，解决插件依赖关系需要在用户界面中进行。
米尔斯在罚单中写道：
自从我们查看插件依赖项以来已经有几年了，这似乎仍然是人们真正非常想要的功能，尤其是对于本身不是插件的共享功能。 例如，一个 PHP 库在核心中不够流行，但足够流行以捆绑在多个插件中。
该声明在今天可能更加相关。 在过去的十年中，许多插件已经发展了自己的附加插件生态系统。 确保安装依赖项的责任通常落在最终用户的肩上。 开发人员已经提出了内部解决方案来减轻这种负担，并且 TGM 插件激活 脚本已成为事实上的标准。
在任何插件项目中几乎都需要依赖依赖项，至少在一般的构建工具设置中发挥了作用。 可以肯定地说，与 WordPress 形成时期相比，如今更多的 WordPress 插件开发人员更愿意在需要第三方代码的环境中进行编码。
对于一个一直在努力实现自身现代化的平台来说，解决插件依赖就像乘坐火箭飞船前往狂野西部。
这个想法在 WordPress 世界中并非没有先例。 虽然这是一个不太复杂的情况，但 WordPress 在从目录安装子主题时会自动下载并安装父主题。
插件依赖系统的许多参数都属于附加方案。 最明显的用例是 WooCommerce 以及为它编写的数十个扩展。
然而，另一个可以深入了解开发人员如何在 WordPress 之上构建的场景是包含框架和库。 现在，插件作者必须在他们的项目中捆绑第三方代码，并确保如果已经捆绑在一个完全独立的插件中，它不会被加载。
代码重用是编程的基石之一。 目前，没有捆绑代码库或脚本的标准。 而且， WordPress 插件目录不允许使用新框架 和类似的库。
为了透明起见，我至少有十几个项目属于这个类别，其他人可以使用的软件包。 所以，我至少在游戏中有一些皮肤，我相信很多其他人都在同一条船上。
WordPress GitHub 存储库中有两个针对插件依赖系统的拉取请求。 还有一个 Google Docs 文件 详细概述了这两个提案.
每个都要求开发人员通过插件头定义依赖项。 以下是需要 WooCommerce 和 Gutenberg 的示例：
两种方法都是相似的。 从用户的角度来看，他们会：
- 向管理员显示需要安装依赖项的通知。
- 不允许删除或停用插件而不删除或停用其所需的插件。
- 在管理插件屏幕上的插件卡中输出一条消息。
第一个实现 由 Ari Stathopoulos 撰写。 它创建了一个“激活队列”，只有在用户激活了所需的插件后才会激活插件。 它还允许用户取消激活请求。
激活依赖项的通知。
Andy Fragen 的解决方案 在插件管理屏幕上创建一个新的“依赖项”选项卡。 这种方法会自动停用任何具有未满足依赖项的插件，并通过管理员通知通知用户。
他还发布了 插件依赖项选项卡 在 GitHub 上单独进行项目。
插件依赖项选项卡。
两者仍然存在一些实际问题。 即，当支持的版本之间发生冲突时会发生什么？ 当前的提议让插件不破坏用户端的任何东西。
这可能是所有这一切中最不鼓舞人心的部分。 但是，这可能是最实用的路线。 另外，WordPress 没有解决其当前狂野西部系统中的版本冲突。
依赖解决方案也可能是更多代码现代化的机会。 欢迎看到更多开发人员采用接口（合同）等功能。 考虑到依赖项进行编码意味着以不同于任何给定项目是独立插件时的方式思考架构问题。