Composer如何管理WordPress插件依赖_Composer管理WordPress插件依赖总结-composer-PHP中文网

WordPress插件不能直接用composer require安装，因多数未发布到Packagist且不遵循Composer规范；需配置wpackagist.org仓库、设置installer-paths重定向至wp-content/plugins/，并注意更新会覆盖手动修改。

composer如何管理wordpress插件依赖_composer管理wordpress插件依赖总结

WordPress插件不能直接用 `composer require` 安装？

绝大多数 WordPress 插件没有发布到 Packagist，也没有遵循 Composer 的自动加载规范（如 autoload 配置、PSR-4 命名空间映射），所以执行 composer require wpackagist-plugin/akismet 会失败——除非你显式启用并信任第三方仓库。

真正能走标准 composer require 流程的，只有满足以下任一条件的插件：

作者自己维护了 composer.json 并发布到 Packagist（极少见）
你手动在 composer.json 中配置了 type: wordpress-plugin + 自定义仓库（如 wpackagist.org）
插件托管在 GitHub/GitLab 且你用 vcs 仓库类型直连（但需自行处理激活路径）

用 `wpackagist.org` 安装插件前必须加仓库配置

wpackagist.org 是社区维护的 WordPress 插件镜像源，但它不是 Composer 默认仓库，不加配置就运行 composer require 会报错：Could not find a matching version of package wpackagist-plugin/xxx。

正确做法是在项目根目录的 composer.json 中追加：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ],
  "require": {}
}

然后才能运行：

composer require wpackagist-plugin/advanced-custom-fields-pro

注意两点：

wpackagist-plugin/ 是固定命名前缀，不可省略或替换成 wp-plugin/ 等其他形式
插件名必须和 WordPress.org 插件页面 URL 的 slug 一致（例如 https://wordpress.org/plugins/woocommerce/ → wpackagist-plugin/woocommerce）

`installer-paths` 配置决定插件实际存放位置

默认情况下，composer install 会把所有包放进 vendor/ 目录，但 WordPress 要求插件必须位于 wp-content/plugins/ 才能被识别。因此必须用 composer/installers 插件 + installer-paths 显式重定向。

Workflow Decomposer

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

下载

先确保已安装 composer/installers：

composer require composer/installers

再在 composer.json 的 extra 字段中配置路径映射：

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

关键点：

路径必须是相对于项目根目录的相对路径（不是绝对路径）
{$name} 会被自动替换为包名（如 advanced-custom-fields-pro），不要写死
如果项目结构里 wp-content 不在根目录（比如在 public/wp-content），路径就得写成 public/wp-content/plugins/{$name}/

更新插件时可能覆盖手动修改的文件

用 Composer 管理插件后，所有插件文件都由 composer update 控制。如果你曾直接编辑过 wp-content/plugins/xxx/ 下的 PHP 文件，下次运行 composer update 会彻底覆盖这些改动——Composer 不做差异合并，只按包版本重新解压。

安全做法只有两种：