手动升级与降级 WordPress 核心：覆盖法升级与安全回滚

引言：什么时候必须手动升级

后台点”现在更新”失败的原因很多：权限不足、磁盘满、wp-content/upgrade 不可写、HTTP 请求被防火墙拦截、更新包下载超时。

这时候手动升级是唯一出路。另一种场景是降级：更新到 6.8 后某个插件崩了，你需要回到 6.7.2，后台没有”降级”按钮，只能手工做。

原理分析：WordPress 核心由哪些部分组成

升级 WordPress 时，只需要替换两个目录和根目录的部分文件：

必须替换：
  wp-admin/        整个目录
  wp-includes/     整个目录
  根目录的 .php 文件（index.php、wp-login.php 等）

绝不替换：
  wp-config.php    你的配置
  wp-content/      你的内容
  .htaccess        你的伪静态规则

所以”覆盖升级”是安全的——把新版本的核心文件覆盖上去，你的内容、插件、主题、设置全部保留。

数据库结构则由 wp-admin/upgrade.php（访问后台或执行 wp core update-db）负责升级，WordPress 会自动比对 db_version 并执行必要的 ALTER。

保姆级实操：手动升级

第一步：备份（不可跳过）

wp db export before-upgrade-$(date +%F).sql
tar czf site-files-$(date +%F).tar.gz wp-content wp-config.php .htaccess

第二步：下载目标版本

cd /tmp
curl -O https://wordpress.org/wordpress-6.7.2.tar.gz
curl -O https://wordpress.org/wordpress-6.7.2.tar.gz.sha1
sha1sum -c wordpress-6.7.2.tar.gz.sha1    # 校验完整性
tar xzf wordpress-6.7.2.tar.gz

校验这一步别省，下载中断的包覆盖上去会导致站点半残。

第三步：替换核心文件

cd /var/www/mimangfei.com

# 删除旧核心
rm -rf wp-admin wp-includes

# 复制新核心
cp -a /tmp/wordpress/wp-admin .
cp -a /tmp/wordpress/wp-includes .
cp -a /tmp/wordpress/*.php .

# 修正属主
chown -R www-data:www-data wp-admin wp-includes *.php

注意 cp -a 会保留原文件的属主，所以要用 cp 后统一 chown，或者先 cp 再 chown -R。

不要复制 wp-content 目录，新包里有个空的 wp-content，覆盖会破坏你的站点。

第四步：更新数据库

sudo -u www-data wp core update-db

或浏览器访问 https://mimangfei.com/wp-admin/upgrade.php 点”更新 WordPress 数据库”。

第五步：验证

wp core version
wp core verify-checksums      # 校验核心文件完整性
wp rewrite flush
wp cache flush

wp core verify-checksums 会比对官方校验和，输出被篡改或缺失的文件，非常有用。

保姆级实操：降级回滚

方法一：WP-CLI 指定版本（最简单）

wp core update --version=6.6.2 --force
wp core update-db

--force 是必需的，否则 WP-CLI 会认为”已经是最新版”而跳过。

方法二：手动覆盖（同上，换成旧版本包）

从 WordPress 版本存档 下载旧版本 tarball，按上面的步骤覆盖。

方法三：从备份恢复核心

如果你有整站备份，只恢复 wp-admin、wp-includes 和根目录 PHP 文件即可（不要恢复数据库，除非你确认降级需要回滚数据库结构）。

降级的注意事项

1. 数据库结构不回滚：降级核心后，数据库可能已经是新版本结构。多数情况下向后兼容，但不绝对。这就是为什么降级前必须备份数据库。
2. 插件可能已升级：如果降级是因为插件不兼容，记得同时回滚插件版本：wp plugin update 插件 --version=旧版本。
3. 主题兼容性：新主题可能用了新版本才有的函数，降级后会报 fatal error。

常见踩坑与失败案例

1. 覆盖后后台提示”需要更新数据库”反复出现 —— db_version 与实际结构不一致。执行 wp core update-db 后刷新。
2. 案例：某站手动升级时把新包的 wp-content 也复制了进去，导致主题和插件目录被覆盖成空，站点前台全白。修复靠从备份恢复 wp-content。永远只复制 wp-admin、wp-includes 和根目录的 PHP 文件。
3. 降级后插件报 Call to undefined function —— 插件用了新版本才有的函数。要么升级插件，要么接受降级不适用于该插件。
4. .htaccess 被覆盖 —— 新包里没有 .htaccess（除非你手工复制），但有些教程会让你复制所有文件。只复制明确列出的部分。
5. 文件属主变 root —— 用 root 执行 cp 后忘了 chown，之后后台又弹 FTP 凭据。
6. 升级过程中断导致半新半旧 —— 文件复制一半失败。用 wp core verify-checksums 检查，有问题就重新下载完整包再覆盖一次。

总结

手动升级 WordPress 的核心操作只有三步：备份 → 覆盖 wp-admin 与 wp-includes（外加根目录 PHP 文件）→ 执行 update-db。降级则用 wp core update --version=X --force。两个关键纪律：一是绝不复制新包的 wp-content，二是操作前后都用 wp core verify-checksums 校验完整性。把这套流程写进运维文档，即使后台更新功能失效，你也能在任何时候安全地升级或回滚。