WordPress 區塊佈景主題與傳統佈景主題：一份誠實的比較

打開你的佈景主題資料夾。如果裡面有一個 templates 資料夾、裡頭放著 index.html，而且根目錄有 theme.json，那就是區塊佈景主題。如果裡面是 index.php，旁邊還有 header.php、footer.php 這類檔案，而且後台側邊欄顯示的是「外觀 → 自訂」，那就是傳統佈景主題。

光是這一個結構差異，就決定了誰能改網站的哪些東西、這些變更存在哪裡，以及 WordPress 外掛生態裡哪一半會正常運作。

30 秒辨識法

判斷點	傳統佈景主題	區塊佈景主題
根範本檔	index.php	templates/index.html
頁首與頁尾	header.php、footer.php	parts/header.html、parts/footer.html
全域設定	functions.php	theme.json（functions.php 可選用）
後台選單	外觀 → 自訂	外觀 → 編輯器
變更儲存在哪	磁碟上的檔案	資料庫，以 wp_template 文章形式
小工具頁面	有	沒有

WordPress 是靠有沒有 templates/index.html 來判定的。一個帶了 theme.json 但仍保留 PHP 範本的佈景主題，依然會被當成傳統佈景主題——這個中間狀態很常見，也有自己的名字，下面會談到。

如果你有指令列權限，一行指令就能定案：

wp eval 'var_dump( wp_is_block_theme() );'

面對不是自己做的網站，WP-CLI 是最快的檢查方式，尤其是當某個頁面編輯器已經把後台選單藏起來的時候。

對負責編輯網站的人來說有什麼不同

在傳統佈景主題裡，頁首、頁尾、側邊欄、顏色和標誌都躲在自訂器後面，而你只拿得到佈景主題作者當初決定做出來的那些控制項。如果作者沒有為頁尾的版權文字註冊控制項，那就是沒有。你要嘛去改 PHP 檔案，要嘛忍耐。

在區塊佈景主題裡，網站編輯器把整個頁面攤開來。頁首、頁尾、文章列表、404 頁面、搜尋結果版面——全都是區塊，全都能讓從沒看過 PHP 的人直接編輯。這是真正的重點功能，而且份量確實很大。

代價是：整個頁面也都能被一個從沒看過 PHP 的人改掉。客戶可能凌晨兩點把頁首的網站標題刪掉，而磁碟上沒有任何版本紀錄可以還原，只剩下網站編輯器自己的修訂紀錄。你可以用區塊鎖定，以及限制誰能進入編輯器來收緊權限，但這些都是要主動去做、而且要記得做的工作。

還有兩個實務上會咬人的小損失：區塊佈景主題沒有小工具頁面（小工具區塊由範本組件和區塊取代），而傳統選單被導覽區塊取代，導覽項目變成獨立的內容型態儲存，不再放在熟悉的「選單」頁面裡。

對開發者來說有什麼不同

傳統佈景主題使用 PHP 範本階層。WordPress 會沿著一條已知的鏈往下解析一個請求——single-{post-type}.php，接著 single.php，接著 singular.php，再到 index.php——然後執行你的檔案，呼叫 get_header()，跑主迴圈，輸出你能一個字元一個字元控制的 HTML。

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

區塊佈景主題沿用同一套階層命名，只是副檔名換成 .html，而檔案內容是區塊標記——HTML 加上寫在註解裡的區塊分隔符——而且沒有範本標籤可用：

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

開發者馬上會撞到三個後果：

get_header() 和 get_footer() 永遠不會執行。 掛在這兩個動作上的東西，不管是在外掛還是舊的子佈景主題裡，都會默默失效。wp_head 和 wp_footer 仍然會觸發，所以多數載入資源的程式碼還活著，但頁首專屬的 hook 就不行了。

資料庫會贏過你的檔案。 只要有人在網站編輯器裡儲存了某個範本，WordPress 就會把那個版本存成 wp_template 文章，並改用它來輸出，不再理會你的檔案。你可以整個下午都在改那個 HTML 檔，前台卻毫無變化。把該範本的自訂內容清掉，才會回到檔案版本。這是最常見的「我的區塊佈景主題壞了」回報內容，而它並不是錯誤。

樣式搬進 theme.json。 顏色、間距級距、字體排版、各區塊的預設值，都以資料而非 CSS 的形式宣告，再由 WordPress 產生 CSS。這樣更乾淨、也一致得多——直到你需要某個結構描述表達不出來的效果，那時你還是得寫 CSS，而且得跟產生出來的規則比選擇器權重。

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

記得對照你所使用的 WordPress 版本去確認 version 的值——這套結構描述已經改版過不只一次，從舊教學裡照抄版本號，會讓你的設定被默默忽略。

另外，functions.php 並沒有消失。區塊佈景主題還是會用它來載入資源、註冊 add_image_size 設定、建立自訂內容型態，以及任何其他 PHP 工作。只是你在那裡做的範本相關工作少了非常多。

你實際換到什麼，又實際失去什麼

改用區塊佈景主題，你換到： 對整個頁面的編輯掌控權、由 theme.json 強制維持的設計一致性、更少要維護的檔案，以及編輯器與前台的樣式相符程度遠高於傳統佈景主題所能做到的。

改用區塊佈景主題，你失去： 對輸出 HTML 的直接控制、以 hook 為主的直觀客製方式、與所有預設 PHP 範本的工具之間的相容性，還有「網站外觀都在版本控制裡」這份安心感。

最後一點值得強調。在傳統佈景主題裡，git log 會告訴你改了什麼。在區塊佈景主題裡，網站外觀有相當一部分活在資料庫，而你的部署流程根本不會去看那裡。

什麼情況下傳統佈景主題仍然是正確答案

• 網站由頁面編輯器主導。 Elementor、Divi、Beaver Builder 這類工具本身就接管了範本工作。在底下再墊一層區塊佈景主題，等於多了一套什麼事都沒做的範本系統。
• HTML 必須精準。 客製元件庫、嚴格的無障礙標記、特殊的結構化資料需求——區塊能輸出什麼就限制了你能做什麼，硬要跟它拚，成本比直接寫 PHP 還高。
• 大量依賴外掛範本。 會員、線上課程、目錄站，以及較舊的電商擴充功能，經常會提供 PHP 範本覆寫檔。現在有不少已經有區塊版本，但也有不少沒有。
• 網站已經完成而且運作正常。 一個累積了五年客製內容的佈景主題，沒有升級到區塊的路徑，只有重做一途。「這是比較新的做法」不是一個商業理由。
• 除了你以外沒有人會編輯它。 網站編輯器的主要好處是把控制權交給非開發者。如果根本沒有非開發者，你就是在為沒有人使用的好處付出代價。

混合式的中間地帶

傳統佈景主題也可以加上一份 theme.json，拿到全域樣式系統、顏色與間距預設值，以及一致的編輯器樣式，同時保留原本的 PHP 範本和自訂器。WordPress 不會因此把它當成區塊佈景主題，網站編輯器也仍然不會出現，但你用一小部分的工作量，就拿到了設計系統的大部分好處。

對一個大致上運作良好的既有網站來說，這通常是最該先走的一步。加上 theme.json，定義好調色盤與間距，刪掉被它取代的那些 CSS，然後再看看你是不是真的還想要其餘的部分。