用 Composer 管理 WordPress 核心与插件：依赖化建站实践

引言：为什么有人要用 Composer 装 WordPress

传统做法是 FTP 上传、后台点更新。问题在于：线上到底跑的是哪个版本的插件？上周改了什么？换台机器能不能还原成一样的？

如果你维护多个站点、有 CI/CD、或者团队协作，把 WordPress 当成”PHP 项目”来管理会更踏实：核心、插件、主题版本全部写进 composer.json，一条 composer install 还原整站代码。

原理分析：Composer 怎么装 WordPress 插件

Composer 默认从 Packagist 拉包，而 WordPress 插件不在 Packagist。解决方案是 wpackagist.org —— 它把 WordPress 官方目录的插件和主题镜像成了 Composer 包。

两个关键包：

• johnpbloch/wordpress（或 johnpbloch/wordpress-core）：WordPress 核心，支持自定义安装目录；
• wpackagist-plugin/* 与 wpackagist-theme/*：官方目录的插件和主题镜像。

还需要 composer/installers 插件来把不同类型的包装到正确目录（wp-content/plugins/、wp-content/themes/）。

保姆级实操

第一步：环境准备

php -v        # 建议 8.0+
composer -V   # 2.x

第二步：写 composer.json

{
  "name": "mimangfei/site",
  "type": "project",
  "require": {
    "johnpbloch/wordpress": "6.7.*",
    "wpackagist-plugin/wordpress-seo": "^24.0",
    "wpackagist-plugin/contact-form-7": "^6.0",
    "wpackagist-theme/twentytwentyfour": "*",
    "composer/installers": "^2.2"
  },
  "repositories": [
    { "type": "composer", "url": "https://wpackagist.org" }
  ],
  "extra": {
    "wordpress-install-dir": "web/wp",
    "installer-paths": {
      "web/wp-content/plugins/{$name}": ["type:wordpress-plugin"],
      "web/wp-content/themes/{$name}": ["type:wordpress-theme"],
      "web/wp-content/mu-plugins/{$name}": ["type:wordpress-muplugin"]
    }
  },
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "johnpbloch/wordpress-core-installer": true
    }
  },
  "minimum-stability": "stable",
  "prefer-stable": true
}

第三步：安装

composer install

目录结构会变成：

web/
├── wp/                  ← WordPress 核心
├── wp-content/
│   ├── plugins/
│   ├── themes/
│   └── uploads/
└── wp-config.php
└── index.php

第四步：让 WordPress 识别新目录

核心在 web/wp 而内容在 web/wp-content，需要在 wp-config.php 里声明：

define('WP_HOME', 'https://mimangfei.com');
define('WP_SITEURL', 'https://mimangfei.com/wp');

define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');
define('WP_CONTENT_URL', 'https://mimangfei.com/wp-content');

index.php 也要改成：

require __DIR__ . '/wp/wp-blog-header.php';

第五步：更新与回滚

composer update wpackagist-plugin/contact-form-7   # 更新单个
composer update                                     # 全部更新

回滚就是把 composer.json 里的版本号改回旧值再 composer update，比后台找旧版本包方便得多。

第六步：处理商业插件

付费插件不在 wpackagist。两种做法：

1. 自建私有仓库（Satis / Private Packagist）；
2. 用 artifact 类型仓库，把 zip 放在本地目录：

"repositories": [
  {
    "type": "artifact",
    "url": "packages/"
  }
]

常见踩坑与失败案例

1. allow-plugins 报错 —— Composer 2.2+ 默认禁止执行插件脚本，必须在 config.allow-plugins 里显式允许。
2. 插件装到了 wp-content/plugins/插件名/插件名 —— installer-paths 写法不对，或插件包类型未被识别。
3. 案例：某团队用 Composer 部署后，后台提示”插件需要更新”，运维点了后台更新，结果 composer.lock 与实际文件不一致，下次部署被回滚，站点插件版本倒退。用 Composer 管理就必须禁用后台更新：define('DISALLOW_FILE_MODS', true);
4. wpackagist 同步延迟 —— 插件刚发布的新版本可能要几小时后才同步到镜像。
5. 不适合小站点 —— 如果你只有一个博客，Composer 带来的复杂度大于收益。

总结

Composer 管理 WordPress 的核心收益是可复现性：composer.lock 记录了每个包的精确版本，换服务器、回滚、审计都有据可依。它的代价是禁用后台更新、需要理解目录重映射。适合多站点、团队协作、有部署流程的场景；单站点个人博客用传统方式反而更省事。