WordPress 後台文章列表打不開怎麼查？Object Cache 與外掛衝突排查

WordPress 後台文章列表突然打不開時，很容易把問題想成「網站壞了」或「某個外掛必須立刻重裝」。但後台文章列表其實同時碰到查詢、權限、快取、外掛 hook、分頁與欄位顯示；其中任何一層卡住，都可能讓 /wp-admin/edit.php 看起來像整個後台掛掉。

我會先把它當成一個可回復的排查題，而不是立刻做破壞性處理。尤其是有啟用 Redis、Object Cache、頁面快取或管理後台加速外掛的站，第一步通常不是改文章資料，而是先把快取層與外掛層分開看。

先確認症狀發生在哪一個入口

不要只說「後台壞掉」。先把能打開與不能打開的頁面列出來：

/wp-admin/                 後台首頁
/wp-admin/edit.php          文章列表
/wp-admin/post-new.php      新增文章
/wp-admin/upload.php        媒體庫
/wp-admin/plugins.php       外掛列表
/wp-admin/options-general.php 設定頁

如果只有 edit.php 卡住，但新增文章、媒體庫、外掛列表都能進去，問題就比較像文章查詢、列表欄位、分類法、快取資料或某個掛在文章列表上的外掛。若整個 /wp-admin/ 都進不去，才要往登入、權限、PHP fatal error 或主機資源看。

Object Cache 為什麼會讓文章列表出問題

Object Cache 的角色是把 WordPress 常用查詢結果暫存在記憶體或 Redis / Memcached 裡。正常時它能降低資料庫壓力；但在外掛更新、資料結構變更、Redis 連線異常或快取資料不一致時，後台可能拿到舊的、壞的或不完整的查詢結果。

這不代表 Object Cache 一定有錯，而是它是一個很適合早期排除的變數。因為停用或 flush 快取通常比直接刪外掛、改資料庫、重裝 WordPress 安全得多。

若可以使用 WP-CLI，我會先留下目前狀態：

wp plugin list --status=active
wp option get active_plugins
wp cache type
wp cache flush

wp cache type 不是每個環境都有一致輸出；如果指令不存在，就改看 Object Cache 外掛頁、wp-content/object-cache.php 是否存在，以及主機面板是否有 Redis / Memcached 設定。

安全的第一輪排查順序

我會照這個順序做，原因是越前面的步驟越容易回復：

先開無痕視窗重新登入，排除瀏覽器快取或登入狀態問題。
清除 WordPress / CDN / 主機面板快取。
若有 Object Cache 外掛，先暫停 object cache 或 flush Redis。
重新整理 /wp-admin/edit.php?post_type=post，觀察是否恢復。
若恢復，記錄「停用 Object Cache 後恢復」而不是直接宣告根因。
若未恢復，再進入外掛衝突、錯誤日誌與資料庫慢查詢排查。

比較保守的作法是先停用 drop-in，而不是刪外掛資料。WordPress 的 Object Cache 常見 drop-in 是：

wp-content/object-cache.php

如果一定要手動處理，先把檔案改名保存，比直接刪除更安全：

mv wp-content/object-cache.php wp-content/object-cache.php.disabled

做完要立刻記錄時間、操作者、變更內容與恢復方式。若這是正式站，最好先確認有檔案與資料庫備份。

什麼時候不要只怪快取

如果停用 Object Cache 後仍然打不開文章列表，就不要硬把問題歸咎於 Redis。接著要看錯誤日誌與外掛 hook：

tail -n 80 wp-content/debug.log

若主機環境沒有開 debug.log，可以短暫在 staging 或維護時段打開：

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

常見線索包括：

Allowed memory size exhausted：文章列表載入太多自訂欄位或外掛查詢。
PHP Fatal error：某個外掛、佈景主題或 mu-plugin 在後台列表頁出錯。
Redis connection refused：Object Cache 後端服務不可用。
Unknown column 或 SQL error：外掛升級後資料表欄位不一致。
timeout 但沒有 fatal error：可能是慢查詢、外部 API call 或列表欄位太重。

這些訊息比「我剛剛更新過某個外掛，所以一定是它」可靠。排查時要把時間點對齊：錯誤發生時間、更新時間、快取 flush 時間與恢復時間。

外掛排查要避免破壞現場

如果需要找外掛衝突，不建議在正式站一口氣全部停用，尤其是 WooCommerce、會員、SEO、快取、安全性外掛混在一起時。比較安全的方式是：

wp plugin deactivate plugin-slug --skip-plugins --skip-themes
wp plugin activate plugin-slug --skip-plugins --skip-themes

--skip-plugins --skip-themes 可以降低排查指令本身又被其他外掛干擾的機率。若沒有 WP-CLI，就先在 staging 複製問題，再逐一停用最近更新、最可能改後台列表欄位的外掛。

特別要留意會改文章列表的外掛，例如 SEO 欄位、文章排序、權限控制、自訂欄位、語系翻譯、內容分析、後台 UI 管理工具。它們不一定壞掉，但它們最有機會掛在 manage_posts_columns、pre_get_posts 或 admin_init 之類的流程上。

恢復後要補的紀錄

最糟的處理方式是「好了就算了」。後台文章列表恢復後，至少要留下這些紀錄：

發生時間：
影響頁面：/wp-admin/edit.php
可用頁面：
當時更新過的外掛或主機設定：
Object Cache 狀態：啟用 / 停用 / 已 flush
採取動作：
恢復時間：
仍未確認的風險：
下一次要觀察的 log：

如果停用 Object Cache 後恢復，下一步不是永遠關掉快取，而是確認 Redis 服務、Object Cache 外掛版本、PHP 版本、外掛相容性與快取清除策略。長期關掉快取可能讓前台變慢；但在找到根因前，短暫關閉是合理的止血方式。

我會怎麼下結論

比較負責任的結論會像這樣：

目前只能確認文章列表在停用 Object Cache / flush cache 後恢復，因此快取層是高機率關聯因素；尚不能排除文章列表欄位外掛、Redis 連線或升級後資料不一致。建議保留 log，觀察下一次外掛更新或快取重建後是否復發。

這種寫法比「Redis 壞了」更有用，因為它把已驗證事實與推測分開。WordPress 維護最需要的不是每次都猜中，而是讓下一次排查能從更好的證據開始。

延伸可以搭配 WordPress 外掛更新 Smoke Test 清單做更新後巡檢，或使用 WordPress 維護回滾紀錄模板把停用、恢復與觀察結果寫清楚。

WordPress 後台文章列表突然打不開：先停用 Object Cache 再往外查