WPGraphQL项目中get_plugins()函数的MU插件加载问题解析

在WPGraphQL项目中，开发者发现了一个关于插件加载机制的重要问题。该问题主要出现在使用Bedrock架构的WordPress项目中，当插件被安装到mu-plugins目录时，系统无法正确识别这些插件。

问题的核心在于Updates类中的get_plugins()函数实现。这个函数原本设计用于获取WordPress插件列表，但存在一个明显的功能缺陷：它没有包含对必须使用插件(mu-plugins)的扫描和加载。在标准的WordPress环境中，get_plugins()函数确实只扫描常规的plugins目录，而get_mu_plugins()函数则专门处理必须使用插件。

这个缺陷会导致以下具体问题：

1. 当开发者使用Composer将WPGraphQL等插件安装到mu-plugins目录时
2. 系统无法正确识别这些插件的存在
3. 插件更新检查等功能会因此失效
4. 可能影响插件的正常功能加载

问题的复现步骤清晰地展示了这一缺陷：

1. 在Bedrock项目中配置Composer，将WPGraphQL指定为必须使用插件
2. 通过Composer安装后，插件被正确放置到mu-plugins目录
3. 但系统更新机制无法检测到这个插件的存在

从技术实现角度来看，正确的解决方案应该是在获取插件列表时，同时合并常规插件和必须使用插件的列表。这需要修改Updates类的相关代码，使其能够全面扫描所有可能的插件位置。

这个问题特别值得Bedrock项目用户注意，因为Bedrock鼓励使用Composer管理插件，并常常将核心插件安装为必须使用插件。这种架构选择使得该问题在Bedrock环境中表现得尤为明显。

对于开发者而言，理解这个问题的本质很重要：它反映了WordPress插件架构中常规插件与必须使用插件管理机制的差异。在开发需要支持多种安装方式的插件时，必须考虑到这种差异，确保插件在各种安装位置下都能正常工作。

该问题的修复方案已经通过Pull Request提交，主要改动是增强get_plugins()函数的功能，使其能够正确处理必须使用插件。这一改进将提升WPGraphQL在不同WordPress架构中的兼容性，特别是对采用现代开发工作流(如使用Bedrock和Composer)的项目。