某個經營網站的小型工作室，某天登入後台，看到佈景主題那欄跳出一個小紅點，提示有新版本可以更新。心裡想的多半是「不就版本號往上跳一格」，順手點了更新，回到前台卻發現排版整個跑掉，某些頁面甚至只剩一片空白。
WordPress 主題更新表面上只是把主題資料夾換成新版本，實際上牽動的是主題、外掛、WordPress 核心三者的相容性，任何一個環節版本沒對上，前台就可能跟著出狀況。外掛、主題與核心彼此不相容，正是網站更新後最常見的出包原因之一。搞懂更新前該先準備什麼、更新時該按什麼順序、更新後版面跑掉又該怎麼一步步排查，下次後台跳出更新通知，就不必再靠運氣賭一把。
先從主題更新為什麼容易讓網站出狀況講起，再一路拆到更新前的準備與更新後的排查步驟。
主題更新為什麼常常讓網站出狀況？
多數人以為 WordPress 主題更新只是把一個資料夾換成新版本，實際上 WordPress 從來不是單一個東西，而是核心程式、外掛、佈景主題三層彼此呼叫的系統，任一層版本往前跳，另外兩層沒跟著調整就容易出狀況。更麻煩的是，不少人習慣直接在主題檔案裡加自訂程式碼，這類客製化在更新當下最容易被整批覆蓋掉，這也是「更新完客製化不見了」的根本原因。往下先看這兩件事，分別是牽動關係怎麼運作，客製化又是怎麼不見的。
主題、外掛、核心，彼此牽一髮動全身
外掛與主題很少獨立運作，幾乎都會掛勾 WordPress 核心提供的函式與掛勾（hook）才能發揮功能，像是抓文章列表、渲染版面、串接資料庫查詢，背後呼叫的都是核心程式碼。核心版本更新後，如果外掛或主題還停留在舊版邏輯，原本呼叫的函式可能被替換或棄用，程式就會找不到對應的東西執行，前台輕則版面跑位，重則直接跳出錯誤訊息。
這種依存關係也會反過來發生。主題或外掛更新時，開發者可能會調整原本的樣式類別名稱或程式碼函式，如果另一邊剛好倚賴著那個舊名稱、舊邏輯，對方就會跟著出錯。這正是外掛、主題、核心三者互不相容最容易出狀況的地方，而且往往不是單一方的問題，是三者版本沒對齊造成的連鎖反應。
直接改過的主題檔案，更新當下就會被覆蓋
如果曾經直接打開主題的 functions.php 加過一段自訂功能，改過 style.css 調整顏色，或動手修改版型檔案微調排版，這些修改都只存在主題資料夾裡的檔案本身。WordPress 更新主題的做法，是把整個主題資料夾換成官方發布的新版檔案，不會去比對哪些檔案被動過，新版一到，舊檔案就整批被覆蓋掉，改過的內容自然跟著消失。
這正是「更新前」要先盤點自己有沒有動過主題檔案的原因。如果只用過後台的外觀客製化工具調整顏色與版面，這類設定存在資料庫裡，更新通常不受影響；但只要曾經打開過程式碼編輯器改過任何一支檔案，更新前就該先把改過的內容記下來或另外存一份，免得更新完才發現東西不見了，卻想不起來原本改了什麼。
更新前，這些準備不能省
搞懂三層版本為什麼會打架、客製化又為什麼容易不見之後，接下來要顧的是按下更新鍵之前，能先把風險降到多低。備份聽起來是老生常談，卻是這幾項準備裡最常被跳過的一步，原因往往是「應該不會這麼剛好出事」。除了備份，更新前該顧的還包括先看一眼這次更新改了什麼，以及有沒有測試環境可以先跑一次再上正式站。
全站備份，資料庫與檔案缺一不可
很多人以為備份就是把主題資料夾複製一份存起來，其實網站的內容跟版面是分開存放的。資料庫裡存的是文章、留言、頁面設定，以及佈景主題「自訂」工具裡調整過的顏色與版面選項；檔案裡存的則是主題、外掛程式本身，還有上傳過的圖片與媒體。WordPress 官方文件說得很直接，資料庫存的是網站上的每一篇文章、每一則留言，但不包含讓這些內容呈現出來的主題與外掛檔案，兩者要一起備份到，才能真正還原成更新前的樣子。
實際做法上，多數主機商後台都內建一鍵備份功能，也有備份外掛可以排程自動備份資料庫與檔案，並存到站外的雲端空間。不管用哪一種方式，重點是備份要在更新前完成，而且要確認備份檔案真的能打開、能還原，不是點了「開始備份」就假設一定成功。
更新前為什麼要先看一眼更新日誌？
主題或外掛的更新頁面，通常會附一份更新日誌（changelog），列出這次版本改了哪些功能、修了哪些錯誤，以及有沒有提高對 PHP 或 WordPress 版本的需求。按下更新前先花幾分鐘看過這份清單，能提早發現這次更新是不是跟自己的主機環境不相容，而不是更新完才發現網站出狀況，回頭才想起主機的 PHP 版本早就太舊了。
WordPress 官方系統需求頁公告，目前建議的執行環境是 PHP 8.3 以上，搭配 MariaDB 10.11 以上或 MySQL 8.0 以上；舊版本如 PHP 7.4、MySQL 5.5.5 理論上還能勉強跑，但這些版本都已經停止官方維護，存在資安風險，也可能撐不住新版主題或外掛用到的新功能。更新前對照一下自己主機的版本，是最容易被忽略、卻也最能提前避開問題的一步。
沒有測試環境，還能怎麼降低風險？
如果手上有測試站或子網域，更新前可以先在那裡套用同一次更新，確認版面與功能都正常，再套用到正式站，這是最保險的做法。但不是每個網站都有這種環境，沒有的話，備份就要做得比別人更確實，更新時也要照後面提到的更新順序，一項一項來，不要一次全部按下去。
沒有測試環境不代表只能碰運氣，把備份做確實、更新日誌看過、更新時分批進行，三件事加起來，已經能擋掉大部分更新後才發現網站出狀況的情形。
核心、外掛、主題，更新順序該怎麼排？
備份做好、更新日誌也看過，接下來是按下更新鍵的那一刻該怎麼選。後台常常一次跳出三個更新通知，核心、外掛、主題全部亮著紅點，很多人會直接點「全部更新」一次解決。這麼做的風險在於，一旦更新完前台出狀況，完全不知道是哪一個環節造成的，因為三個異動同時發生。比較穩妥的做法是把異動來源愈拆愈少，依核心、外掛、主題的順序一項一項更新，每更新完一項就到前台測一次，再進行下一項。
為什麼要一項一項更新，不要一次全部按下去？
具體做法是每次只勾選一個項目更新，送出後立刻打開無痕視窗看一次前台首頁，再點開一篇文章頁確認排版正常，沒問題才進行下一項。這個順序聽起來麻煩，但只要某一項更新完前台就出狀況，能馬上鎖定是剛剛那一項造成的，不必同時懷疑三個地方。
更新前也順手記下目前各項目的版本號，萬一某一項更新完真的出狀況，還能知道要退回哪個版本。分階段更新、每完成一項就先確認網站運作正常再繼續下一步，才是降低更新風險最務實的做法，而不是一次把全部項目按完。
為什麼主題適合放在更新順序的最後？
三個項目要更新，核心通常風險最低也最容易被忽略，外掛次之，主題則建議放在最後一個處理。理由是主題出狀況最容易被使用者一眼看出來，配色跑掉、版型跑位、選單不見了，前台的異常一望即知；相較之下，核心與外掛出問題有時只是某個功能失效，不一定馬上被發現。
把核心與外掛先確認穩定，最後才動最容易看得出問題的主題，一旦更新完版面真的跑掉，就能直接鎖定是這次主題更新造成的，不必同時排查三個地方。多個項目同時更新時，最難處理的就是判斷這次的錯誤是外掛、主題，還是核心造成的。
更新後版面跑掉，該怎麼排查？
就算照順序一項一項更新，還是有機會遇到更新完前台不對勁的狀況，這時候排查的順序原則是先做風險最低、最簡單的動作，行不通才往下一步走。從清快取開始，接著找外掛衝突，再換回預設佈景主題確認範圍，最後才是打開偵錯模式看實際的錯誤訊息。
先清快取，很多版面異常其實是舊快取作祟
如果網站裝了快取外掛，或主機端本身就有快取機制，更新完看到的畫面很可能還是更新前的舊版本，不是真的跑版。第一步永遠是先清快取，快取外掛的設定頁裡通常都有「清除快取」按鈕，清完再重新整理瀏覽器，並順手清一次瀏覽器本身的快取，或用無痕視窗開一次，確認問題是不是還在。
不少人一看到版面異常就急著停用外掛、換主題，結果只是白忙一場，因為清完快取問題早就自己消失了。先把這一步做完，再往下判斷是不是真的有更嚴重的問題。
停用外掛後，怎麼抓出真正衝突的那一個？
清完快取問題還在，下一步是到外掛頁面把全部外掛一次停用，重新整理前台。如果畫面立刻恢復正常，就代表問題出在某個外掛，而不是主題或核心。接下來一個一個重新啟用，每啟用一個就重新整理前台看一次，啟用到哪一個又讓畫面壞掉，那個就是造成衝突的外掛。
如果後台完全進不去，沒辦法用滑鼠點停用，也可以透過 FTP 連進主機，把 wp-content/plugins 資料夾底下想停用的外掛資料夾改個名字，WordPress 偵測不到原本的資料夾名稱，就會自動把那支外掛視為停用狀態。
換回預設佈景主題，能看出什麼問題？
停用外掛後問題依然存在，代表問題不在外掛身上，下一步是暫時切換成 WordPress 內建的預設佈景主題，例如 Twenty Twenty-Four 這類官方主題。切換過去如果版面就恢復正常，代表問題出在主題本身，可能是這次更新帶進的錯誤，也可能是子主題或自訂 CSS 跟新版樣式衝突，沒跟著調整。
確認問題出在主題之後，就該回頭檢查子主題裡的程式碼，或後台自訂 CSS 欄位裡加過的樣式，看看有沒有哪一段是針對舊版樣式寫的，需要對應新版重新調整。如果連後台都進不去沒辦法切換，做法跟停用外掛類似，用 FTP 把目前啟用中的主題資料夾改名，WordPress 找不到原本的主題，就會自動切回預設主題。
打開偵錯模式，看錯誤訊息怎麼說？
如果連後台都進不去，或前台整片空白，可以透過 FTP 連進主機，打開網站根目錄下的 wp-config.php，啟用偵錯模式（Debug Mode），在檔案裡加入三行設定：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Code language: PHP (php)這樣設定後，WordPress 會把錯誤訊息寫進 wp-content 資料夾底下的 debug.log 檔案，而不是直接顯示在前台給訪客看。打開這個檔案，通常會直接標出是哪一支外掛、哪一個主題檔案，甚至哪一行程式碼造成問題，比自己一項一項猜快得多。
不需要碰 FTP，也有機會排查問題。WordPress 從 5.2 版之後，偵測到嚴重錯誤時會自動寄一封信到網站管理員的信箱，附上一個復原模式（Recovery Mode）的連結，點進去登入後台，有問題的外掛或主題會暫時被系統擋下，只影響這次登入，不影響前台其他訪客看到的畫面，管理者能安心進去排查。WordPress 官方文件也提醒，偵錯模式建議只在需要排查時打開，問題排除後記得關掉，正式站不適合長期開著，免得錯誤細節一直暴露給訪客看。
子主題是什麼？為什麼能保住客製化內容？
前面提到，直接修改主題檔案的客製化，在主題更新時會被整批覆蓋掉。子主題（Child Theme）正是用來解決這個問題的做法，它是建立在原本主題之上的獨立主題，原本那支主題這時稱為父主題（Parent Theme）。子主題預設會繼承父主題的所有版面與功能，把客製化的程式碼與樣式改寫進子主題裡，不去動父主題本身的檔案，更新父主題時，子主題完全不受影響。
父主題更新，子主題的客製化不受影響
子主題與父主題各自存放在 wp-content/themes 底下獨立的資料夾，兩者透過子主題 style.css 開頭的 Template 欄位建立關聯，這個欄位要填的名稱，必須跟父主題資料夾名稱一字不差。WordPress 更新父主題時，只會替換父主題那個資料夾裡的檔案，子主題資料夾完全不會被動到，寫在子主題裡的客製化程式碼與樣式，自然也就保留下來。
要留意的是，子主題本身不會因為父主題更新就自動跟著更新。如果父主題這次更新是修補資安漏洞或重大功能，子主題裡若有覆寫過同一支檔案，就要留意父主題的改動內容，手動比對合併進子主題裡，不然客製化雖然保住了，卻可能漏接父主題這次修補的安全性問題。
沒有子主題，也有辦法保護客製化
如果目前用的主題沒有提供子主題，或不想另外架設一套子主題的檔案結構，還有一個更輕量的做法，就是把原本寫在 functions.php 裡的自訂程式碼，搬到程式碼片段類的外掛裡管理。
這類外掛獨立於主題資料夾之外運作，主題更新時完全不會被動到，程式碼因此不會跟著消失，而且不需要額外準備子主題的檔案結構與樣式表，對不熟悉程式碼的人來說，操作起來也比架子主題單純。這個做法涵蓋不到樣式與版型層級的客製化，這部分還是子主題比較適合，但如果客製化主要是功能性的程式碼，這個做法已經足夠解決「更新完程式碼不見了」的問題。
更新前把資料庫和檔案都備份好，更新時核心、外掛、主題一項一項來，更新後版面跑掉別急著慌，照順序從清快取查到偵錯模式，幾乎都能找到問題出在哪。把子主題架起來，再養成更新前看一眼更新日誌、更新後測一次前台的習慣，下次後台再跳出 WordPress 主題更新的通知，就不會再是一場讓人心跳加速的賭注。