Composer 不能直接管理 WordPress 插件的运行时行为，仅负责下载和组织代码；插件需置于 wp-content/plugins/ 并含标准插件头才能被识别，即使使用 composer/installers 也依赖包自身声明 "type": "wordpress-plugin"，而多数社区插件并未如此配置。

Composer 不能直接管理 WordPress 插件的运行时行为，它只负责下载和组织代码文件；想让插件在 WordPress 中生效，仍需手动激活或通过 WP-CLI 触发。

为什么 composer require 装完插件却没出现在后台？

WordPress 不原生识别 Composer 的 vendor/ 目录结构。插件必须放在 wp-content/plugins/ 下，且主文件需含标准插件头注释，WordPress 才会扫描到。

• 默认 composer require 把包装进 vendor/，不是 wp-content/plugins/
• 部分插件（如 johnpbloch/wordpress-core）用自定义安装器，但普通插件包几乎都不带 wordpress-plugin 类型声明
• 即使你用符号链接把 vendor/my/plugin 指向 wp-content/plugins/my-plugin，也得确保 my-plugin/my-plugin.php 文件存在且有正确插件头

用 composer/installers 让插件装到正确位置

这是最常用、也最接近“自动管理”的做法：靠 composer/installers 重定向安装路径。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 先执行 composer require composer/installers
• 在 composer.json 里加配置：

  "extra": {
    "installer-paths": {
      "wp-content/plugins/{$name}/": ["type:wordpress-plugin"]
    }
  }

• 然后装插件时，必须确认该包的 composer.json 中声明了 "type": "wordpress-plugin" —— 大多数社区插件（如 advanced-custom-fields/acf-pro）并不这么写，所以实际能用的很少
• 常见能用的只有官方维护或明确标注类型的包，比如 wpackagist-plugin/woocommerce（来自 WPackagist）

错误信息 Plugin could not be activated because it triggered a fatal error 怎么查？

这通常不是 Composer 的问题，而是插件加载时机或依赖冲突导致的 PHP 运行时失败。

• 检查错误日志里具体哪行报错，重点看是否调用了未定义的函数（如 acf_add_local_field_group() 在 ACF 加载前就执行）
• 确认插件依赖的其他插件是否已启用 —— Composer 不处理启用顺序，require 只管文件存在
• 如果插件用了命名空间或自动加载，但没在 plugins_loaded 钩子之后注册，也会出这个错
• 临时禁用其他插件，用 wp plugin activate my-plugin 单独激活测试，比后台点更易暴露真实错误

真正难的不是装插件，是让它们在 WordPress 的加载生命周期里不打架。Composer 管的是“有没有”，WordPress 核心管的是“能不能用”——中间那层钩子、依赖、激活状态，它一概不碰。