WordPress 外掛更新審核紀錄｜版本、備份、WP-CLI 與回滾驗證

WordPress 後台出現外掛更新紅點時，最危險的反應是「先全部更新再說」。外掛更新看似日常維護，但它可能同時影響編輯器、前台樣式、REST API、表單、會員登入、快取、SEO metadata 與付款流程。若沒有紀錄，出問題時很難判斷是哪一個外掛、哪一個版本、哪一次操作造成。

我會把外掛更新視為一個小型變更管理流程。重點不是把流程做得很重，而是每次更新前後都留下足夠證據：目前版本、更新原因、相依外掛、備份狀態、測試範圍、WP-CLI 輸出、前台 smoke test 與回滾方式。這樣即使只是個人網站，也不會在故障時只能靠印象猜測。

先判斷：這次更新是安全修補、功能需求，還是例行整理？

不是所有更新都同樣急。更新前先把動機分類，決策會清楚很多：

更新類型	優先順序	審核重點
安全性修補	高	是否有 CVE、官方公告、受影響版本與暫緩風險
相容性更新	中高	是否為 WordPress core、PHP、主題或 WooCommerce 相容
功能修正	中	是否真的修到目前遇到的問題
例行小版更新	中低	是否可排入固定維護時段
大版號升級	需審核	是否有 breaking changes、資料庫 migration 或 UI 重寫

這一步的目的是避免兩種極端：一種是永遠不更新，讓安全風險累積；另一種是每次看到更新就全部套用，最後無法回溯問題。

更新前先留下外掛現況

如果可以使用 WP-CLI，我會先輸出目前外掛狀態，並把結果貼進維護紀錄：

wp plugin list \
  --fields=name,status,update,version,update_version \
  --format=table

同時記錄 WordPress、PHP 與主題版本：

wp core version
wp option get template
wp option get stylesheet
php -v

若沒有 WP-CLI，也可以從後台外掛頁截圖或複製版本資訊。重點不是工具形式，而是更新前要能回答：目前啟用哪些外掛？哪些外掛有更新？更新前版本是多少？有沒有停用但仍保留的舊外掛？

我會用這份審核紀錄做決策

每次更新前，至少補齊下面欄位：

[observe] plugin update candidate
site: example.com
plugin: contact-form-example
current version: 2.8.4
available version: 2.9.1
reason:
  security fix and editor compatibility
risk:
  affects frontend form submission and email delivery
backup:
  database backup verified at 2026-08-10 08:40
  files backup verified at 2026-08-10 08:42
decision:
  test on staging first, then update production in low traffic window

這份紀錄不需要漂亮，但要能被未來的自己看懂。若有多個外掛要更新，我會把高風險外掛拆開，不要一次更新十幾個後才開始測試。

先確認備份與回滾路徑，不要更新後才找

外掛更新前，至少要知道三件事：

資料庫備份在哪裡，是否能下載或還原。
wp-content/plugins 檔案是否有備份，或能否重新安裝指定版本。
若更新後前台壞掉，誰可以在多快時間內回復。

可以把回滾紀錄寫成這樣：

[rollback plan]
restore database: hosting panel backup 2026-08-10 08:40
restore plugin files: wp plugin install plugin-slug --version=2.8.4 --force
disable plugin if needed: wp plugin deactivate plugin-slug
verification after rollback:
  - homepage 200
  - wp-admin loads
  - representative form submits
  - cache purged only after rollback is stable

很多事故不是因為沒有備份，而是更新當下沒有人知道備份是否可用、版本從哪裡拿、回復後要測哪些頁面。

在 staging 先做一次低風險演練

如果網站有 staging，外掛更新應該先在 staging 走一次。測試時不要只看「後台沒有白屏」，而要檢查代表性流程：

首頁與重要 landing page 是否正常載入。
文章頁、分類頁與搜尋結果是否正常。
表單、會員登入、付款、下載或預約流程是否正常。
編輯器是否能開啟、儲存與預覽。
REST API、admin-ajax、圖片載入與快取是否異常。
瀏覽器 Console 是否出現新的 JavaScript error。

如果 staging 環境資料太舊，至少要標註限制，不要把「staging 正常」誤寫成「production 一定安全」。

更新後要驗證輸出，不要只看成功訊息

WP-CLI 的 Success 只是變更完成，不代表網站功能正常。更新後我會做一輪最小 smoke test：

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

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

再搭配瀏覽器檢查：前台是否有破版、表單是否送得出去、後台外掛頁是否正常、Console 是否出現新錯誤。若有快取或 CDN，清快取前後都要知道自己正在驗證哪一層。

把結果寫成 observe / change / verify / rollback

最後，把整次更新整理成一段可追蹤紀錄：

[change] plugin update batch
updated:
  - seo-plugin-example 4.1.0 -> 4.1.2
  - form-plugin-example 2.8.4 -> 2.9.1
commands:
  wp plugin update seo-plugin-example form-plugin-example
verify:
  homepage 200, wp-json 200 application/json
  editor opens and saves a draft
  contact form test mail received
rollback:
  not used; backup path documented
notes:
  purge CDN cache after verification, not before root cause is known

這種紀錄的價值在下次故障時才會明顯。你可以快速知道最近哪些外掛改過、當時測了什麼、哪些假設沒有被驗證，而不是從一串模糊的後台通知開始猜。

UCAMC 的維護判斷

對長期內容站來說，外掛更新不是「按鈕任務」，而是網站可信度的一部分。越是依賴 WordPress 後台、API、自動化匯出與舊文整理，就越需要知道每次更新前後的狀態。把版本、命令、測試與回滾寫下來，可以讓維護變成可複製流程，而不是一次次靠運氣通過。

下一次看到更新紅點時，可以先問三個問題：這次更新解決什麼風險？如果壞了我要怎麼回復？更新後我要用哪些證據判斷網站仍然正常？能回答這三題，再按 Update 會安全得多。

WordPress 外掛更新不要只按 Update：用審核紀錄降低維護風險