本文译自 kikomono.com 英文原文《Check WordPress plugin update compatibility before you click update》，作者 Rita。原文链接：https://kikomono.com/guides/check-wordpress-plugin-update-compatibility/
简短回答
按顺序做三项检查：版本号跳变的大小、插件页面上的四个字段，以及这个插件在你的网站上动了什么。一个来自积极维护的插件、只修 bug 的补丁更新，在备份之后可以直接上正式站。而大版本跳变、未针对你的 WordPress 版本做过测试的插件，或者动了页面构建、结账、缓存、安全或登录的插件，每次都要先上预发布环境（staging）。如果三项检查里有一项答不上来，这本身就是“先上预发布环境”的答案。
1. 先看版本号跳变
WordPress 插件一般用三段式版本号：大版本、小版本、补丁。变的是哪一段，就说明开发者改了多少，也就说明你承担了多少风险。
| 变了什么 | 通常意味着什么 | 默认路线 |
|---|---|---|
| 只变补丁（最后一位数字） | 修 bug、小修正 | 其他检查通过的话，备份后直接上正式站 |
| 变小版本（中间一位数字） | 在修复之外加了新功能或改进 | 插件对网站重要就先上预发布环境；否则备份后直接上正式站 |
| 变大版本（第一位数字） | 重大改动或重构 | 一律先上预发布环境 |
大版本跳变是唯一一种更新日志比版本号本身更重要的情况。要在日志里找被移除的功能、改动过的设置、新的要求，以及任何标注为破坏性改动的内容。如果日志提到你依赖的功能要改行为，就要在预发布环境里测那个确切功能，而不只是打开首页看一眼。
2. 在插件页面上查四个字段
更新之前，打开这个插件在 WordPress 插件目录里的页面（付费插件则打开开发者自己的页面），对照你自己的网站读四个字段。
测试至（Tested up to）。这是开发者已确认插件能用的最新 WordPress 版本。如果你的网站跑的版本比上面列出的更新，插件可能仍然能用——但没人验证过。差一个版本是提醒；差两个或更多大版本，是开发已经停滞的有力信号，这类插件在证明没问题之前都属于预发布环境。
最低要求（Requires at least）。这是插件支持的最老 WordPress 版本。更新老网站时它很重要：一次插件更新可能悄悄要求比你现在跑的更新的 WordPress 版本。
需要 PHP（Requires PHP）。这是插件需要的最低 PHP 版本。一次要求比你的服务器所跑版本更新的 PHP 的插件更新，会失败或表现异常，而修复办法是改服务器，不是再做一次插件更新。更新之前先去主机面板里查你服务器的 PHP 版本，不要等报错出现之后再查。
最近更新（Last updated）。一个最近更新过、更新日志里提到你的 WordPress 版本的插件，和一个一年没动过的插件，风险完全不同。没人维护的插件不一定就危险，但它最不可能在更新出问题时得到修复，所以它值得一次预发布测试，以及一次对积极维护的替代品的搜索。
3. 问问这个插件动了什么
有些插件出问题时很安静，只看首页是发现不了的。如果一个插件动了下面任何一项，不管版本号跳变看起来多小，都要先上预发布环境：页面构建器和区块编辑器、商店和结账流程、缓存和性能优化、安全和登录，以及收集访客数据的表单。对这些插件，预发布测试必须实际跑通它对应的功能——用构建器编辑一个页面、提交一个表单、走一遍结账——而不只是加载首页就了事。
还要查有没有重复干活的插件。两个插件做同一件事——两个缓存插件、两个安全插件、两个功能重叠的联系表单插件——是冲突的经典来源，更新其中任何一个都可能把重叠暴露出来。一个活只留一个解决方案；去掉重复的那个，往往就是更新只是揭示出来的那个修复。
4. 预发布测试，一遍过
在预发布环境里，一次只更新一个插件。一次更新好几个能省几分钟，出问题时却要花几小时，因为你已经不知道是哪一次更新造成的。每次更新之后，都跑同一套简短检查：加载首页、编辑并保存一个页面、提交一个表单或完成一步结账、退出再重新登录，并查看错误日志有没有新增条目。判断结果之前先清缓存——过期的缓存页面会让坏更新看起来没问题，也会让好更新看起来坏了。
如果没有预发布环境，同样的纪律仍然适用于正式站，只是更慢、更小心：在非高峰时段更新、一次一个、备好备份，每次更新之后做同样的简短测试。没有预发布环境，是更小心的理由，不是跳过检查的理由。
5. 正式站的更新顺序
当检查结果说更新可以直接上正式站时，顺序是：先备份，再更新，再测试，再清缓存。备份只有在你知道怎么还原时才算数——一个你从来没有还原过的备份是愿望，不是计划。英文原文中的备份恢复指南讲了如何在真正需要之前证明一次还原能成功。如果更新之后出了任何问题，就还原备份，不要在一个坏掉的网站上叠加修复，记下出问题的插件版本和你还原到的版本，重新尝试之前先在预发布环境里测试这次更新。
从更广的角度看，英文原文中的 WordPress 小 VPS 指南能帮你理解流量增长时什么最先坏，英文原文中的首台 VPS 指南则提醒你在认定更大服务器是插件问题答案之前先想清楚。插件冲突是软件问题；更大的套餐修不好它。
常见问题
“标注为测试至更老 WordPress 版本的插件一定会坏吗？”
不一定。这意味着开发者还没有针对你的版本确认过它，所以风险是未经验证，而不是确定会坏。把它当作在预发布环境测试的理由，而不是坏掉的证据。
“小补丁更新可以直接上正式站吗？”
来自积极维护的插件、只修 bug 的补丁，是风险最低的情况——但前提是先有一个你知道怎么还原的备份。任何大版本跳变，或者任何动了结账、页面构建、缓存、安全或登录的插件，都要先上预发布环境。
“在预发布环境里更新插件之后要测什么？”
首页、一次页面编辑、一次表单提交或结账步骤、一次管理员登录，再看一眼错误日志。如果其中任何一项失败，这次更新就不能上正式站。
“插件更新把正式站搞坏了怎么办？”
还原备份，不要在一个坏掉的网站上叠加修复。记下出问题的插件版本和你还原到的版本，重新尝试之前先在预发布环境里测试这次更新。
发表回复