前言

今天起来收到一封邮件：

我就知道又要出幺蛾子了，果不其然：

wordpress的备用站点由于自动升级插件失败导致无法使用/wp-admin登录后台仪表盘，但是如果不登录后台只是正常访问却是没有问题的，也就是说其实没啥大问题，只是因为某些原因(我这里是因为插件自动升级失败所致，不过也有上传主题失败所致)导致无法正常访问后台仪表盘而已。

---

遇到这种问题的时候，有时候我的邮箱可以收到有问题的wordpress发出的一封邮件(这是因为WordPress 从 5.2 版本之后的一个新功能：当检测到插件或主题发生错误时，回自动发送邮件通知管理员，即便是在后端完全无法访问的情况下)，里面有一个链接，直接点击是可以直接登录wordpress后台然后进行管理的，但是大部分时候，这封邮件是收不到的。。

---

鉴于这种问题出现已经不止一次了，而每次发生的时候我都基本忘记了上次是怎么处理的，所以决定还是记录一下处理的流程以备不时之需，当然，也可以随便水一篇文章。

处理方式汇总

能明确定位故障原因的

比如，我这次的插件升级失败，或者更换新主题后导致的失败，问题原因就很明确，所以可以针对性的处理，比如按照下图所示将插件所在目录进行重命名：

然后重启wordpress(如果是docker部署方式就重启docker，如果是源码部署就重启对应的service)，这个时候如果能够正常进入后台则可以对有问题的插件进行处理(根据需要重新升级或者删除或者重新上传安装)。

不过我依旧不能进入，原因可能是不止这一个插件升级导致，所以我就只能依次用相同方式对待其他插件，直到找到所有相关插件。

注：这里也有技巧，比如我直接以最近修改的时间进行排序，然后从最近修改的开始改：

最终修改了3个插件文件夹的名称之后，才能正常进入控制台：

然后将3个改名的文件夹改回原来的名字，刷新一下：

就进入正常状态了，然后是删除还是启用后进行升级，就看大家自己的需要了。

如果是升级主题引起的，处理方式也是类似，可以将原来使用的主题的文件夹删除或者改名，然后将其他主题文件夹的名称改为和原来使用主题的文件夹名并重启即可。

不能定位故障原因的

对于此类问题，就要依靠wordpress的debug模式了。通过开启debug模式，wordpress会将启动过程中遇到的错误发送到wp-content/debug.log文件中，通过log文件中记录的问题，就能够定位故障原因。

编辑wordpress/html/wp-config.php，找到以下内容：

define( 'WP_DEBUG', false );

如下图：

将其改为：

define('WP_DEBUG', true); #开启debug模式
define('WP_DEBUG_LOG', true); #将启动错误信息写入log文件
define('WP_DEBUG_DISPLAY', false); 

然后保存wp-config.php的改动，这时就可以通过wp-content/debug.log文件中的信息定位导致wordpress不能正常启动的原因。

处理完之后记得关闭调试模式：

define( 'WP_DEBUG', false ); #其他两条直接删除即可。

总结

如果是通过文章”家庭数据中心系列 wordpress多节点”半自动”、”近乎”实时同步方案“中所述的方式部署的多节点wordpress同步，则建议在除了主节点之外的其他节点中禁用插件的自动更新功能，因为这种方式在主节点自动升级更新了插件之后，其实其他节点都可以通过syncthing的同步功能跟着升级插件，只不过这种同步不一定会被本地的插件感知到(重启一下其他节点的wordpress就能正常识别了)。

所以，如果其他wordpress节点开启了自动更新，可能会导致本地插件检测到新版本之后又尝试自动升级，但是由于其实已经升级了，就会引发一些错误，这也是我为什么会觉得其他wordpress节点自动升级插件后触发致命故障的几率大大增加的原因。