把一個跑了好幾年的經典主題（Classic Theme）直接換成區塊主題（Block Theme），聽起來只是後台點一下「啟用」，實際上動到的是 WordPress 組裝頁面的整套邏輯。經典主題靠 PHP 模板與 Customizer，區塊主題改用 HTML 範本、theme.json 與網站編輯器（Site Editor），兩者的版型來源、樣式來源、選單與小工具的存放位置都不一樣。一刀切換的風險，是版型、選單、自訂 CSS、甚至 WooCommerce 的結帳流程在某個環節突然失效。
經典主題遷移區塊主題其實不必一次到位。WordPress 從 5.9 之後，逐步把區塊主題的功能開放給經典主題使用，於是中間多出一段「混合期」——你仍保留 PHP 模板，但同時開始導入 theme.json、區塊範本片段與模式（Patterns）。這段混合期是降低風險的關鍵，也是多數競品教學跳過的部分。這篇會把整個遷移拆成可控的階段，說明混合期該遵守哪些相容規則、哪些東西誰說了算，以及什麼時候該停在混合狀態、什麼時候才值得走完全區塊化。
經典主題、區塊主題與混合主題差在哪裡
先把三種主題的邊界講清楚，後面的策略才站得住。差別不在外觀，而在「頁面是誰組裝的、樣式存在哪裡、誰能改」。
經典主題是 WordPress 自 2005 年沿用至今的型態，用 PHP、HTML、CSS、JavaScript 寫成，版型邏輯放在 header.php、footer.php、single.php 這類模板檔裡，全站樣式靠 style.css 與 Customizer 管理。它的優點是 PHP 能寫高度客製的邏輯與整合；缺點是改動門檻高，連調個頁首順序，往往都得開模板檔。
區塊主題自 WordPress 5.9 起登場，版型改用 /templates 與 /parts 目錄下的 HTML 範本，內容是區塊標記（block markup），全站樣式集中在 theme.json，所有區域都能在網站編輯器裡用拖拉方式改，不必碰程式碼。判定一個主題是不是區塊主題的硬指標只有一個：主題裡有沒有 /templates/index.html，有就會被 WordPress 當成區塊主題載入。
混合主題（Hybrid Theme）落在兩者中間。它骨架仍是經典主題的 PHP 模板，但選擇性地接上區塊主題的功能，例如用 theme.json 定義色票與字級、用區塊範本片段取代部分模板、註冊區塊模式。它不是一種獨立的主題格式，而是「導入到一半的經典主題」。Jetpack 文件另外提到「通用主題」（Universal Theme），指的是既能吃網站編輯器、又能退回 Customizer 與小工具的主題，本質上也是為了銜接這段過渡而設計。
對遷移而言，混合主題不是終點，而是運輸工具。它讓你把風險拆成好幾筆小額付款，而不是一次刷一大筆。
漸進遷移為什麼比一次換掉更安全
漸進遷移最大的價值，是讓網站在每一步都維持可用，出問題時的回溯範圍小到一個功能、而不是整個版型。一次切換的問題在於：經典主題與區塊主題的選單、小工具、自訂 CSS、模板來源全部同時改變，一旦前台破版，你很難判斷是 theme.json 寫錯、還是某個外掛只認經典主題的鉤子（hook）。
把遷移切成階段，每個階段只動一類東西，就能逐項驗證再往下走。一個常見且風險可控的順序是這樣：
- 第一階段、先在子主題或測試環境放進 theme.json，只定義色票、字級、版面寬度這類全站樣式，不動任何模板。
- 第二階段、用區塊模式（Patterns）取代重複的 get_template_part() 區塊，例如行動呼籲區、頁尾資訊列。
- 第三階段、開啟 block-template-parts 支援，把頁首、頁尾改寫成 /parts 底下的 HTML 範本片段，再用 block_template_part() 在 PHP 模板裡呼叫。
- 第四階段、把單篇、頁面、彙整這些 PHP 模板，逐一改寫成 /templates 底下的 HTML 範本。
- 第五階段、當 /templates/index.html 就位、PHP 模板也清空，主題就正式成為區塊主題，網站編輯器全面接管。
這個順序的好處是：前三階段你都還待在「混合主題」狀態，網站隨時可發布；真正把主題翻轉成區塊主題的，是最後放進 index.html 的那一步。在那之前的任何階段，發現相容問題都能單獨退回，不會牽連全站。
混合期該遵守哪些相容策略
混合期最容易出事的地方，是同一件事有好幾個地方能設定，而它們的優先順序不一致。把以下規則先講清楚，混合期才不會變成一筆難還的技術債。
theme.json 與 add_theme_support 的關係要分清楚。早期經典主題靠 functions.php 裡一串 add_theme_support() 開啟編輯器色票、自訂字級、寬版對齊。一旦主題根目錄放了 theme.json，這類設定就該改寫進 theme.json 的 settings 區段——官方明確說明，align-wide、custom-line-height、custom-spacing、editor-color-palette、editor-font-sizes 等支援在 theme.json 存在時不會再從 add_theme_support 生效。換句話說，混合期請以 theme.json 為單一樣式來源，不要兩邊各設一份，否則之後排查樣式衝突會非常痛苦。少數例外像 responsive-embeds，目前仍透過 add_theme_support 開啟。
Customizer 的設定要規劃退場，而不是並存。色彩、字體、版面寬度在區塊主題裡改由 theme.json 與全站樣式管理。混合期若同時保留 Customizer 的同類設定，會出現「前台到底吃哪一份」的混亂。建議的做法是：每把一類樣式搬進 theme.json，就把 Customizer 對應選項關掉或標記為棄用，讓樣式來源逐步收斂到單一處。
選單與小工具是兩個高風險區。經典主題的選單走「外觀 → 選單」，區塊主題改用導覽區塊（Navigation Block）；小工具區（sidebar）則由區塊或範本片段取代。混合期可以先保留 PHP 的選單與 register_sidebar()，等頁首、頁尾改成範本片段那一步再一起換成導覽區塊與對應區塊。遷移前務必把小工具裡的文字內容、行動呼籲、自訂 HTML 先複製存檔，因為區塊主題不再有傳統小工具區，這些內容不會自動搬過去。
自訂 CSS 與 PHP 邏輯要逐筆盤點。Customizer 的「額外 CSS」、style.css 裡的客製樣式、functions.php 裡的掛鉤、以及追蹤碼（例如像素追蹤），都要先抄出來。混合期可以把通用樣式改寫進 theme.json 的 styles 區段，無法用 theme.json 表達的再留在 style.css，這個檔在區塊主題裡仍然存在、仍會載入。
收款與 WooCommerce 在混合期的注意事項
如果站台跑的是 WooCommerce，混合期要特別留意模板來源的切換點，因為購物車與結帳一旦破版，影響的是收款動線，比一般頁面破版嚴重得多。WooCommerce 8.0 之後內建了區塊版的商品頁、購物車與結帳範本，但部分 WooCommerce 擴充功能與既有客製，仍假設網站跑在經典主題的鉤子上。
這裡只客觀說明取捨，不展開金流設定本身。混合期的安全做法是：商品列表、單一商品這類展示型頁面可以較早改用區塊範本驗證；購物車、結帳這類牽涉交易完成的頁面，放到較後階段、且務必在測試環境完整跑過一輪下單流程再上線。盤點外掛時，要確認你用的金流外掛、運費外掛、發票外掛是否依賴只有經典主題才提供的模板鉤子；若某個擴充只認經典結帳模板，那就是把全站翻成區塊主題前，必須先解決或替換的相依項。
換言之，WooCommerce 站的「混合期」可以拉得比純內容站更長：前台展示先區塊化，交易頁面在確認所有金流相關外掛都相容前，先維持經典模板，這樣收款流程的風險被隔離在最後一步。
遷移前的準備與測試該怎麼做
正式動手前的準備，決定了出錯時能不能全身而退。這一步不能省，多數競品教學也都把它放在最前面，理由相同：遷移改的是版型與設定，內容本身（文章、頁面、商品、媒體庫、資料庫）會留在原處，但版型一旦做壞，沒有備份就難以還原。
開始前請依序完成幾件事。第一、做一份完整網站備份，包含資料庫與檔案，最好用能即時備份的工具，確保任何一步出錯都能回到前一個狀態。第二、在測試環境（staging）操作，不要直接動正式站；多數主機商有提供測試環境，沒有的話可用相關外掛建立。第三、複製並存檔小工具內容、Customizer 的額外 CSS、自訂 PHP 與追蹤碼。第四、逐一檢查外掛相容性，特別是頁面建構器、依賴傳統選單的外掛、依賴 Customizer 的外掛，以及前一節提到的 WooCommerce 擴充。
內容的部分通常不必擔心。用區塊編輯器或經典編輯器寫的頁面，切換後大多只需微調；經典編輯器的內容會自動包進一個「經典區塊」，選取後點「轉換成區塊」就能拆成對應的區塊。真正要花時間的是版型與全站樣式的重建，而不是搬內容。
測試環節要把每個階段當成獨立驗收。改完 theme.json 就比對前台色彩字體有沒有跑掉；改完範本片段就檢查頁首頁尾在各種螢幕寬度下的呈現；WooCommerce 站還要實際走一次加入購物車到結帳的流程。確認無誤，再用測試環境把變更推上正式站。
什麼時候該停在混合期、什麼時候才走完全區塊化
不是每個網站都需要走到全區塊主題，混合期本身就可以是一個穩定的長期狀態。判斷的標準不是「新不新」，而是「誰需要改、改的頻率多高、相依的外掛能不能跟上」。
適合停在混合期的情況：站台有大量依賴經典模板鉤子的客製或外掛、團隊的版本控制與部署流程建立在 PHP 模板上、或是 WooCommerce 擴充尚未全面支援區塊結帳。這些情況下，硬走到全區塊主題只會把可控的技術債換成不可控的相容風險。混合主題能讓編輯端享有 theme.json 與區塊模式帶來的彈性，同時讓開發端保留可預期、好進版控的 PHP 模板。
適合走完全區塊化的情況：希望非開發者（例如客戶或編輯）能自行調整頁首、頁尾、選單與模板而不必開工單、想擺脫笨重的頁面建構器外掛、或計畫未來頻繁換主題——因為當頁首頁尾與全站樣式都已區塊化，日後換主題不必再重建這些區域。
要提醒的是，混合做法本身會累積技術債：同一套網站裡並存兩種版型思維，新進的團隊成員得同時理解 PHP 模板與區塊範本。所以即使決定長期維持混合狀態，也要把「哪些區域已區塊化、哪些還是 PHP、樣式單一來源是 theme.json」這幾件事記錄清楚，避免半年後沒人說得出某個樣式到底在哪裡設定。
把經典主題搬到區塊主題，真正該追求的不是哪天按下全區塊化的開關，而是讓網站在整段過渡裡每一步都可用、每個改動都能單獨回溯。先用 theme.json 收斂樣式，再用範本片段與模式逐區替換，把交易相關頁面留到最後，遷移就從一場豪賭變成一串可驗收的小步驟。下一步，先在測試環境放進一份只管色票與字級的 theme.json，跑通了，再往下一階段走。