WordPress 通过插件和Hooks API的可扩展性是其最有益的功能之一。有许多插件纯粹作为其他插件的扩展，在其之上构建功能。插件依赖项功能旨在使安装和激活插件（依赖项）及其依赖的插件（依赖项）的过程一致且简单。

新插件头

Requires Plugins引入了新的标头。

它必须包含其依赖项的以逗号分隔的WordPress.org格式的 slugs 列表，例如my-plugin(my-plugin/my-plugin.php不支持)。它不支持插件中的逗号。

如何使用新标头

/**
 * Plugin Name: Express Payment Gateway Checkout for Shop
 * Requires Plugins: shop, payment-gateway
 */

要求

依赖插件

对依赖插件有以下要求：

• 在安装其依赖项之前无法安装。
• 在激活其依赖项之前无法激活。

依赖插件

对依赖插件有以下要求：

• 当其依赖项被激活时无法停用。
• 安装其依赖项后无法删除。

如果不再满足依赖性会发生什么？

如果通过FTP或部署删除依赖项插件，管理的插件屏幕上将显示一条通知，通知用户缺少需要安装和/或激活的依赖项。此外，不再满足依赖项的每个依赖项将在其插件行中显示错误通知。

如果插件更新有新的依赖项会发生什么？

目前将允许更新，并且依赖项将保持活动状态。管理的插件屏幕上将显示一条通知，通知用户缺少需要安装和/或激活的依赖项。

如果存在循环依赖会发生什么？

循环依赖是指两个或多个插件在其需求中形成循环。

例如：插件A需要插件B需要插件C需要插件A

插件依赖包括循环依赖检测，并且会显示通知以告知用户需求无效的插件。插件无法激活，用户应联系插件作者，以便在适当的情况下打破此循环引用。

还需要防御性编码吗？

是的。插件依赖项使用户可以更轻松地安装和激活所需的插件，并在不满足这些插件时通知他们。这意味着插件作者可以在未安装或激活其依赖项时安全地删除检查和通知。

但是，目前，插件依赖项不包括对依赖项的最小或最大版本支持，也不考虑插件的加载顺序。因此，插件作者应该继续使用function|class|interface_exists()和版本检查，他们的插件依赖于在给定时间可用的特定功能。

插件依赖关系会影响WP-CLI吗？

插件依赖项不会阻止通过 WP-CLI 安装没有依赖项的依赖插件，因为假设使用 WP-CLI 的用户是了解其依赖项堆栈的高级用户。但是，为了避免丢失依赖项而被忽视，在依赖项被激活之前，无法使用 WP-CLI 激活依赖项插件。

这会影响wp plugin activate --all，如果依赖项按字母顺序出现早于其依赖项，则可能需要运行多次。我们计划与 WP-CLI 维护者合作，通过探索 WordPress Core、WP-CLI 或两者（如果合适）中的加载顺序来减轻这一负担。

局限性

托管在 WordPress.org 上的插件

WordPress.org 上托管的依赖插件只能声明也在 WordPress.org 上托管的依赖项。如果您托管在 WordPress.org 上的插件需要未托管在那里的插件，建议您Requires Plugins此时不要在插件中使用标头。

插件未托管在 WordPress.org 上

未托管在 WordPress.org 上的依赖插件可以声明依赖项，无论托管在 WordPress.org 还是其他地方。但是，UI不会提供第三方依赖项的安装链接，这些依赖项必须继续由用户手动安装。

必须使用插件作为依赖项

WordPress Core 目前不正式支持必须使用的插件作为依赖项。讨论将在#60504中继续，我们将在做出有关未来可能支持的决定后发布更多信息。

需要插件的主题

插件依赖项目前不支持需要插件的主题，主题作者应继续使用他们现有的检查和消息传递。

新过滤器

wp_plugin_dependencies_slug引入过滤器挂钩是为了允许更改依赖项。例如，如果依赖插件声明my-plugin为依赖项，并且存在高级版本my-plugin，则高级版本可以过滤 slug 并将其转换my-plugin-pro为插件依赖项可以检测到的插件。

• 参数
  string $slug——子弹。

用法示例

add_filter( 'wp_plugin_dependencies_slug', 'convert_myplugin_to_myplugin_pro' );

function convert_myplugin_to_myplugin_pro( $slug ) {
	if ( 'my-plugin' === $slug ) {
		$slug = 'my-plugin-pro';
	}
	return $slug;
}

用户界面的变化

插件 > 已安装的插件

进行了以下更改：

• 依赖插件行现在包含其依赖项列表，链接到相应的插件模式以安装和激活依赖项。
• 依赖插件行现在包含其依赖项的列表。
• 如果插件具有未安装且未激活的依赖项，则“激活”链接将被禁用。
• 如果插件具有处于活动状态的依赖项，则“停用”和“删除”链接将被禁用。
• 依赖插件的批量操作被禁用。

改进前

没有列出依赖项或依赖项。

改进后

列出依赖项和依赖项，并根据需求的状态启用/禁用操作。

插件 > 添加新插件

进行了以下更改：

• 如果插件具有未满足的依赖项，则其插件卡和插件信息模式中的“立即安装”和“激活”按钮将被禁用。
• 依赖插件卡现在包含一个列出其依赖项的通知，其中包含指向依赖项信息模式的“更多详细信息”链接，其中包含基于当前安装状态的“立即安装”或“激活”按钮。
• 现在，单击按钮后插件信息模式会持续存在，并且现在可以直接在模式内通过 AJAX 执行基于模式的插件安装和激活。

改进前

改进后

使用体验

由于插件 > 添加新屏幕上现在使用统一的 AJAX 方法，插件的激活将不再自动重定向到插件 > 已安装的插件屏幕，或插件作者实现的入门体验。这允许用户在不离开当前上下文的情况下安装和激活多个插件。

具有入门体验的插件通常会包含检查，例如，如果使用 WP-CLI 安装并激活其插件，则当用户进入插件的设置屏幕之一时，将触发入门体验。此类实现将不受插件依赖关系的影响，从插件 > 安装的插件屏幕激活链接激活也是如此。

新WP_Plugin_Dependencies CLass

WP_Plugin_Dependencies引入了一个新类别。

可以使用以下公共 API 方法：

static ::initialize()
通过从 Requires Plugins 标头读取依赖项并获取依赖项的插件 API 数据来初始化插件依赖项。每次执行仅运行一次。

static ::has_dependents( $plugin_file )
确定插件是否有依赖于它的插件。

• 参数
  string $plugin_file– 插件文件，相对于插件目录。
• 返回值
  bool插件是否有依赖它的插件。

static ::has_dependencies( $plugin_file )
确定插件是否具有插件依赖项。

• 参数
  string $plugin_file– 插件文件，相对于插件目录。
• 返回值
  bool 插件是否有插件依赖。

static ::has_active_dependents( $plugin_file )
确定插件是否有活动的依赖项。

• 参数
  string $plugin_file– 插件文件，相对于插件目录。
• 返回值
  bool插件是否有活动的依赖项。

static ::get_dependents( $slug )
获取需要依赖的插件的文件路径。

• 参数
  string $slug– 依赖项的 slug。
• 返回值
  array相对于插件目录的依赖插件文件路径的数组。

static ::get_dependencies( $plugin_file )
获取依赖项所需的插件的slugs。

• 参数
  string $plugin_file– 依赖插件的文件路径，相对于插件目录。
• 返回值
  array依赖插件 slugs 的数组。

static ::get_dependent_filepath( $slug )
获取依赖插件的文件路径。

• 参数
  string $slug– 依赖插件的 slug。
• 返回值
  string|false依赖插件的文件路径，相对于插件目录，如果插件没有依赖项，则返回 false。

static ::get_dependency_filepath( $slug )
获取依赖项相对于插件目录的文件路径。

• 参数
  string $slug– 依赖项的 slug。
• 返回值
  string|false如果已安装，则为相对于插件目录的依赖项的文件路径，否则为 false。

static ::has_unmet_dependencies( $plugin_file )
确定插件是否有未满足的依赖项。

• 参数
  string $plugin_file– 插件的文件路径，相对于插件目录。
• 返回值
  bool插件是否有未满足的依赖关系。

static ::has_circular_dependency( $plugin_file )
确定插件是否具有循环依赖。

• 参数
  string $plugin_file– 插件的文件路径，相对于插件目录。
• 返回值
  bool插件是否存在循环依赖。

static ::get_dependent_names( $plugin_file )
获取需要该插件的插件的名称。

• 参数
  string $plugin_file– 插件的文件路径，相对于插件目录。
• 返回值
  array依赖名称数组。

static ::get_dependency_names( $plugin_file )
获取插件所需的插件名称。

• 参数
  string $plugin_file– 依赖插件的文件路径，相对于插件目录。
• 返回值
  array依赖项名称数组。

static ::get_dependency_data( $slug )
返回依赖项的 API 数据。

• 参数
  string $slug– 依赖项的 slug。
• 返回值
  array|false成功时为依赖项的 API 数据，否则为 false。