解法就是在 wordpress 目錄下，至 ./wp-content/plugins/ 底下找到該 plugin 的資料夾，並更名該資料夾，即可回復顯示控制台內容。
如此之後，在控制台中會顯示該外掛無法被掛載，也因此筆者又再重新安裝了該外掛，並且也啟用之，（因為如果外掛再掛就已知如何回復了），隨後竟不見再有異常的情形發生。所以到底是哪邊出了問題便不得而知了。

同理，某天突然發生網頁無法顯示或異常，很可能就是某外掛又作怪了。直接將整個 plugins 更名，並且登入，則所有外掛都會被轉為停用。再登出關掉，更回原名，再重新登入。再一一開啟外掛以查看是哪一支出問題。

結論：筆者因安裝外掛已掛過兩次了，所以筆者不會從“控制台”中的“更新”中去做一次性全部更新，而是會手動逐個更新，如此若一發生問題，才會曉得從何著手解決問題。

Claude-code 補充 / 20260901

文中「更名外掛資料夾以救回控制台」的手法，在需要透過 FTP／SSH 手動介入的情境下至今仍然有效、也仍是最後手段之一。不過筆者發文當時（2020年7月）可能還不知道，WordPress 其實從 5.2 版（2019年5月）起就已內建更方便的救援機制，稱為「復原模式（Recovery Mode）」，正是為了這種「外掛/佈景主題更新後整站顯示錯誤、連控制台都進不去」的情境設計的（本站目前為 WordPress 7.1，此機制已內建多年，不必另外安裝）：

• 當某個外掛或佈景主題的程式碼造成「嚴重錯誤（fatal error）」導致整站白屏時，WordPress 會自動偵測到，並寄一封信到管理員信箱，信中附一個一次性的「復原模式」連結。
• 點開該連結後，即可繞過壞掉的外掛/佈景主題正常登入 wp-admin，且會在控制台上方直接標示出是哪一個外掛或佈景主題造成錯誤，可以直接在介面上停用它——不需要再用 FTP/SSH 逐一更名資料夾、逐一開回來測試。
• 此機制是自動觸發的被動防護（偵測到嚴重錯誤才會寄信），不是預先開啟的開關；平常更新外掛前，仍建議比照文中作者的結論——不要用控制台的「一次全部更新」，逐一手動更新，才容易定位問題根源。

另外，若透過 SSH 操作，WP-CLI 的 wp plugin update <slug> 也能達到與作者手動逐一更新相同的效果，且可以先用 wp plugin update <slug> --dry-run 或搭配版本控制/備份指令包成腳本，讓「先備份、再逐一更新、有問題可回復」的流程更容易重複執行——這與本站目前的維運原則（更新外掛前先備份）是同一個精神。