前言
今天起來收到一封郵件:
我就知道又要出廬蛾了,果不其然:
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節點自動升級插件後觸發致命故障的幾率大大增加的原因。
之前換主題時就遇到過,因為主題裡的JS宣告的變數名稱和其他外掛程式JS裡宣告的變數名稱一致。導致後台沒辦法進入。透過WP自動發送的郵件定位到問題,修改了主題的文件解決了。
我也遇過不只一次,要不就是插件,要不就是主題,關鍵每次遇到的時候都忘記得差不多了,又要去網上搜~~,所以這次乾脆記錄下處理過程。