WordPress 6.5 现在支持插件依赖关系，这使得开发者们更容易管理插件之间的关系。

WordPress 6.5 现在可以让插件之间建立依赖关系了。

WordPress 的可扩展性是其最有用的功能之一，它通过插件和Hooks API实现了这一点。很多插件都是建立在其他插件之上的，用来扩展它们的功能。插件依赖功能的目的是让安装和激活扩展插件及其所依赖的插件的过程变得一致且简单。

新的插件标头

现在引入了新的标头 “Requires Plugins”。这个标头必须包含一个以逗号分隔的WordPress.org格式的插件别名列表，列出了插件所依赖的其他插件。例如，格式应该是像这样的：my-plugin, another-plugin。请注意，别名列表中不能包含插件的主文件路径，只能是插件的别名。

如何使用新标头

只需要在插件的标头中添加一个新的项，名称为 “Requires Plugins” 就可以了。

要求

对于依赖插件，有以下要求：

1. 在安装插件之前，必须先安装其依赖项。
2. 在激活插件之前，必须先激活其依赖项。

被依赖插件

对于被依赖插件，有以下要求：

1. 当其依赖项被激活时，无法停用被依赖插件。
2. 安装了其依赖项后，无法删除被依赖插件。

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

如果你通过FTP或其他方式删除了一个被依赖的插件，WordPress管理页面会显示一条通知，提醒你需要安装和/或激活相关的依赖项。此外，每个依赖项的插件行上将显示错误通知，提醒你有插件无法正常运行因为它的依赖项已经被删除了。

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

目前，你可以继续更新插件，即使它们有依赖项，这些依赖项仍将保持激活状态。当你在管理插件页面上操作时，会收到一条通知，提醒你需要安装和/或激活相关的依赖项。

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

循环依赖是指两个或多个插件之间形成了一个循环，它们互相依赖，导致插件之间的需求关系不清晰。

举个例子：插件A需要插件B，插件B需要插件C，而插件C又需要插件A。

插件依赖功能包括检测循环依赖，并会向用户显示通知，提醒他们插件之间存在无法满足的需求。这意味着这些插件无法激活。用户应该联系插件作者，让他们在必要时解决这些循环引用问题。

还需要防御性编码吗？

是的。插件依赖功能让用户更容易地安装和激活他们所需的插件，并在缺少这些插件时提醒他们。这意味着插件作者可以在用户未安装或激活所需的插件时，安全地删除检查和通知功能。
然而，目前，插件依赖功能并不包括对依赖插件的最小或最大版本支持，也不考虑插件加载的顺序。因此，插件作者应继续使用 function|class|interface_exists() 和版本检查，以确保他们的插件在特定功能可用时正常运行，即使它们依赖的插件可能在加载时不可用。

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

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

这可能会影响到 wp plugin activate –all 命令，如果依赖项出现在其依赖项之前，则可能需要多次运行该命令。我们计划与WP-CLI的维护者合作，探讨通过调整WordPress核心、WP-CLI或两者的加载顺序来减轻这一负担。

局限性

托管在 WordPress.org 上的插件

在WordPress.org上托管的插件只能声明依赖于同样托管在WordPress.org上的插件。如果你的插件需要依赖于WordPress.org上未托管的插件，建议你暂时不要在插件中使用”Requires Plugins“标头。

插件未托管在 WordPress.org 上

未托管在WordPress.org上的依赖插件可以声明它们的依赖项，无论这些依赖项是托管在WordPress.org上还是其他地方。但是，请注意，用户在UI界面中将无法找到第三方依赖项的安装链接，这意味着用户必须手动安装这些依赖项。

必须使用插件作为依赖项

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

需要插件的主题

目前，插件依赖项尚不支持主题需要的插件。因此，主题作者应该继续使用他们已有的检查方法和消息传递方式。

新过滤器

我们引入了一个名为 wp_plugin_dependencies_slug 的过滤器挂钩，它的作用是允许修改插件的依赖项。举个例子，如果一个插件声明依赖于 my-plugin，而且存在一个高级版本的 my-plugin，那么高级版本可以通过过滤 slug 参数，将其转换为 my-plugin-pro，这样插件就可以检测到新的插件依赖项了。

参数：

• string $slug：别名。

用法示例

用户界面的变化

插件 > 已安装的插件

我们对插件的依赖项行进行了以下更改：

1. 现在，依赖插件行包含其所需依赖项的列表，并提供链接到相应的插件页面，以便用户可以安装和激活这些依赖项。
2. 如果插件有未安装且未激活的依赖项，则“激活”链接将被禁用，以防止用户误操作。
3. 如果插件依赖的插件处于活动状态，则将禁用“停用”和“删除”链接，以确保依赖的插件保持活动状态。
4. 对于依赖插件的批量操作，现在已被禁用，以避免出现潜在的混乱情况。

前

后

插件 > 添加新插件

我们进行了以下更改：

1. 如果插件存在未满足的依赖项，那么在插件卡和插件信息模块中的“立即安装”和“激活”按钮将被禁用。这样可以防止用户尝试安装或激活插件，直到其所有依赖项都满足为止。
2. 现在，依赖插件卡会显示一个通知，列出了其依赖项，并提供指向依赖项信息页面的“更多详细信息”链接。用户可以通过这个链接了解更多关于依赖项的信息，并可以直接在该页面上进行“立即安装”或“激活”。
3. 现在，单击按钮后插件信息模块会保持打开状态，并且用户可以直接在模块内使用 AJAX 执行基于模块的插件安装和激活操作，而无需离开当前页面。

前

后

入门体验

由于在“插件 > 添加新”屏幕上现在使用了统一的 AJAX 方法，插件的激活不再自动将用户重定向到“插件 > 已安装的插件”屏幕，或者重定向到插件作者设计的入门体验页面。这意味着用户可以在不离开当前上下文的情况下安装和激活多个插件。

通常，具有入门体验的插件会包含一些检查机制。例如，如果用户通过 WP-CLI 安装并激活插件，那么当用户进入插件的设置屏幕之一时，入门体验就会触发。这种实现方式不受插件依赖关系的影响，用户也可以通过“插件 > 安装的插件”屏幕上的激活链接来激活插件。

新的WP_Plugin_Dependencies类

WP_Plugin_Dependencies 引入了一个新的类。

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

• 静态方法 initialize() 通过读取插件的 “Requires Plugins” 标头并获取依赖插件的 API 数据来初始化插件的依赖项。每次执行仅运行一次。

• 静态方法 has_dependents( $plugin_file ) 确定特定插件是否有其他插件依赖它。

参数：

• $plugin_file：插件文件的路径，相对于插件目录。

返回值：

• bool：表示插件是否有其他插件依赖它的布尔值。

• 静态方法 has_dependencies( $plugin_file )： 用于确定特定插件是否有其他插件作为其依赖项。

参数：

• $plugin_file：插件文件的路径，相对于插件目录。

返回值：

• bool：表示插件是否有其他插件作为其依赖项的布尔值。
  

• 静态方法 has_active_dependents( $plugin_file )： 用于确定特定插件是否有已激活的其他插件作为其依赖项。

参数：

• $plugin_file：插件文件的路径，相对于插件目录。

返回值：

• bool：表示插件是否有已激活的其他插件作为其依赖项的布尔值。

• 静态方法 get_dependents( $slug )： 用于获取依赖于指定插件的其他插件的文件路径。

参数：

• $slug：依赖项的 slug。

返回值：

• array：包含相对于插件目录的依赖插件文件路径的数组。
  

• 静态方法 get_dependencies( $plugin_file )：
  • 描述：用于获取指定插件所需的依赖插件的 slugs。
  • 参数：
    • $plugin_file：依赖插件的文件路径，相对于插件目录。
  • 返回值：
    • array：依赖插件的 slugs 数组。
      
• 静态方法 get_dependent_filepath( $slug )：
  • 描述：用于获取指定依赖插件的文件路径。
  • 参数：
    • $slug：依赖插件的 slug。
  • 返回值：
    • string|false：依赖插件的文件路径，相对于插件目录。如果插件没有依赖项，则返回 false。
      
• 静态方法 get_dependency_filepath( $slug )：
  • 描述：用于获取指定依赖项相对于插件目录的文件路径。
  • 参数：
    • $slug：依赖项的 slug。
  • 返回值：
    • string|false：如果已安装，则为相对于插件目录的依赖项的文件路径，否则为 false。
      
• 静态方法 has_unmet_dependencies( $plugin_file )：
  • 描述：用于确定指定插件是否具有未满足的依赖项。
  • 参数：
    • $plugin_file：插件的文件路径，相对于插件目录。
  • 返回值：
    • bool：插件是否具有未满足的依赖关系。
      
• 静态方法 has_circular_dependency( $plugin_file )：
  • 描述：用于确定指定插件是否存在循环依赖。
  • 参数：
    • $plugin_file：插件的文件路径，相对于插件目录。
  • 返回值：
    • bool：插件是否存在循环依赖。
      
• 静态方法 get_dependent_names( $plugin_file )：
  • 描述：用于获取需要指定插件的插件名称。
  • 参数：
    • $plugin_file：插件的文件路径，相对于插件目录。
  • 返回值：
    • array：依赖名称数组。
      
• 静态方法 get_dependency_names( $plugin_file )：
  • 描述：用于获取指定插件所需的插件名称。
  • 参数：
    • $plugin_file：依赖插件的文件路径，相对于插件目录。
  • 返回值：
    • array：依赖项名称数组。
      
• 静态方法 get_dependency_data( $slug )：
  • 描述：用于返回指定依赖项的 API 数据。
  • 参数：
    • $slug：依赖项的 slug。
  • 返回值：
    • array|false：成功时为依赖项的 API 数据，否则为 false。

要了解更多信息，请访问官方日志。