WordPress 維護 command output 怎麼記錄｜WP-CLI、curl 與 log 判讀

WordPress 維護紀錄裡最常看到的句子是：「已清快取」、「已停用外掛」、「已跑 WP-CLI」。問題是，下一次同樣狀況發生時，這些句子幾乎不能判斷當時到底發生什麼事。真正有價值的不是指令名稱，而是執行環境、輸出結果、你怎麼解讀它，以及改完後用什麼方式確認沒有副作用。

如果只是把一串 shell history 貼到記事本，也不算完整紀錄。command output 需要被整理成「可判讀」的維護筆記：讀的人不用猜當時網站版本、不用猜錯誤是在 WordPress、PHP、Nginx、CDN 還是快取層，也能知道哪些步驟只是觀察、哪些步驟真的改動了正式站。

先把觀察指令和變更指令分開

維護筆記第一個要分清楚的是：這個指令只是讀資料，還是會改變網站狀態。

# 觀察型：讀取目前狀態
wp plugin list --status=active
wp option get home
wp cron event list --due-now

# 變更型：會改變網站狀態
wp plugin deactivate some-cache-plugin
wp cache flush
wp rewrite flush --hard

我會建議在紀錄中直接標示：

observe：只讀狀態，不改網站。
change：會改變外掛、快取、rewrite、資料庫或檔案。
verify：用來確認前一步是否有效。
rollback：用來回復前一步。

這樣做的好處是，未來要回顧事故時，不會把「檢查」誤看成「修復」。很多 WordPress 問題是快取、排程或 CDN 疊在一起造成的，如果沒有分清楚變更點，就很難知道是哪一步真的讓網站恢復。

紀錄 command output 時，不要只留最後一行

有些指令的 exit code 是 0，但輸出內容仍然透露風險。例如外掛清單裡出現停用中的 cache plugin、cron event 堆積、或 HTTP response 其實是登入頁 HTML。

比較有用的紀錄格式會長這樣：

[observe] 2026-08-06 09:10 +0800
host: production-web-01
path: /var/www/example.com/public
command:
  wp plugin list --status=active

output summary:
  - cache plugin: active
  - seo plugin: active
  - backup plugin: active

judgement:
  cache layer is present, so frontend freshness issues
  should not be judged by WordPress admin state alone.

這不是為了把每個字都保存下來，而是把「輸出重點」和「判斷」放在同一段。若 output 很長，可以只保留關鍵片段，但不要刪掉錯誤碼、版本、路徑、外掛名稱與時間。

curl 要同時看 status、content-type 和下載大小

WordPress 前台頁面、圖片、REST API 或 sitemap 看起來「打得開」，不代表回應是正確內容。最少要同時看三件事：

curl -L -sS -o /dev/null \
  -w 'status=%{http_code} type=%{content_type} size=%{size_download}\n' \
  'https://www.example.com/wp-json/'

判讀時可以這樣寫：

[verify]
url: /wp-json/
status: 200
content-type: application/json
size: 18432
judgement:
  REST API endpoint is reachable and returns JSON.
  This does not prove wp-admin is healthy,
  but excludes a basic routing or WAF block.

如果 status=200 但 content-type=text/html，可能是被導到登入頁、維護頁或錯誤頁。若 size 小得不合理，也要打開 response body 看是不是只有一段防火牆訊息。這類細節如果沒有記錄，下一次排查會重新踩一次。

log 片段要保留前後文，不要只貼 ERROR

只貼一行 PHP Fatal error 通常不夠。至少保留錯誤前後幾行、時間、request path、plugin/theme 路徑與 PHP version。範例格式：

[observe]
source: php-fpm error log
window: 2026-08-06 09:00-09:15 +0800
keyword: Fatal error

context:
  request: /wp-admin/edit.php
  plugin path: wp-content/plugins/example-plugin/
  repeated: 12 times in 15 minutes

judgement:
  the symptom appears in wp-admin post list,
  but the repeated stack points to one plugin path.
  Do not clear all caches before isolating that plugin.

如果目前沒有完整 log，就誠實寫「尚未取得完整 log」。不要把猜測寫成結論，也不要說「應該是某外掛壞掉」但沒有任何堆疊、URL 或時間證據。

把回復方式寫在變更旁邊

正式站維護最怕的是改完有效，但沒有人知道怎麼回復。每一個 change 最好旁邊就有 rollback：

[change]
command:
  wp plugin deactivate some-cache-plugin
reason:
  isolate whether page cache is serving stale post list.

[rollback]
command:
  wp plugin activate some-cache-plugin
verify after rollback:
  curl homepage, /blog, and one article URL;
  confirm status, content-type, and expected title snippet.

這樣的紀錄讓維護不只是「做了什麼」，也包含「做錯了怎麼退」。如果是資料庫、檔案或 CDN 設定，更應該先確認備份與權限，不要把不可逆變更當成一般排查步驟。

UCAMC 會怎麼把它整理成文章或內部筆記

公開文章不需要貼出敏感路徑、IP、token、客戶網域或完整伺服器資訊；內部維護筆記則可以保留更細的環境資訊。比較好的做法是分兩層：

內部紀錄：完整保存時間、環境、指令、output、判斷、回復方式。
公開文章：抽象化網域與機密資訊，只保留可學習的排查順序與判讀方法。

這篇文章採用的是第二種寫法。它不假裝已取得某一次正式事故的完整 log，而是整理 WordPress 維護紀錄應該如何被保存，讓下一次面對外掛衝突、快取 stale、WP-Cron 堆積或圖片 CDN 問題時，不會只剩「我好像清過快取」這種無法交接的描述。

最後檢查：這份紀錄能不能讓別人接手？

寫完維護紀錄後，可以用三個問題檢查：

沒參與當天維護的人，能不能知道哪一步是觀察、哪一步是變更？
如果同一問題明天又發生，能不能重跑同一組 verify 指令比對結果？
如果修復造成副作用，能不能找到 rollback 指令或至少知道回復方向？

若三個答案都是「可以」，command output 就不只是貼上去的文字，而是能支撐長期網站經營的技術資產。

WordPress 維護不要只貼指令：command output 要怎麼留下可判讀紀錄