上一篇提到 theme.json 是 Block Theme 的鑰匙。今天要介紹的主題，我第一次接觸時覺得有點抖，因為客戶在後台點幾下，居然就能改掉整個網站的頁首，不用開編輯器、不用碰 header.php、不用 FTP，這就是全站編輯（Full Site Editing，FSE）帶來的轉變，而它動到的不只是操作方式，是開發者和網站管理者之間的維護分工。
傳統佈景主題有一條很清楚的界線：管理者能改的是「內容」，開發者才碰得到「結構」。想換頁尾的版權文字？改 footer.php。想調整文章頁的版面？動 single.php，如果想要讓管理者在後台修改這些東西，就是開 ACF 欄位，但 FSE 把這條邊界給打破了。
FSE 到底把什麼交給了管理者
全站編輯的核心，是讓原本寫死在 PHP 範本裡的東西，變成可以在後台視覺化編輯的區塊。打開網站編輯器（Site Editor，後台路徑 外觀 → 編輯器），你會看到四個以前開發者才碰得到的東西全攤在眼前：
- 樣式 –
theme.json定義的色票字型，變成後台一個可視化面板 - 導覽列 – 網站的主選單，再也沒有傳統佈景主題的「外觀 > 選單」選項
- 頁面 – 內容與版面在同一個畫面編輯
- 範本 – 就是前一篇提到的
single.html、page.html那些，現在使用者可以直接拖拉修改。 - 區塊版面配置 – 頁首、頁尾這些跨頁面共用的區塊。
換句話說，以前要改 header.php 才能動的頁首，現在網站擁有者自己在後台拖一拖就好。開發者第一次面對這件事，通常會有一個很直覺的擔憂：那我寫在主題資料夾裡的 templates/single.html，會不會被管理者改掉？
一個必須先搞懂的機制：檔案 vs 資料庫
答案是：會，而且這正是 FSE 最需要理解的一個設計。
同一個 single 模板，其實可能同時存在於兩個地方。一個是你主題資料夾裡的 templates/single.html，這是開發者提供的預設。另一個是使用者在網站編輯器改過之後，WordPress 存進資料庫（wp_posts 表，post_type 為 wp_template）的版本。
當這兩個版本同時存在，資料庫的版本會優先讀取。
這帶來一個傳統主題不存在的維護情境：你在本機改好了 single.html部署上線卻發現網站沒變化，因為管理者早就在後台改過同一個範本，資料庫版本蓋住了你的檔案，如果要還原成檔案的範本，需要在區塊版面配置這邊以表格檢視的方式，點選右側功能選單中的重置會回退到檔案版本：
這對開發與維護的實際衝擊
傳統主題的維護模型很單純，實際看到的畫面就在檔案裡，版控處理好部署到線上環境，網站長怎樣就是跟本機一模一樣。FSE 之後真相變成兩份，檔案跟資料庫各一份，然後資料庫的那一份會蓋過檔案。
實務上會分成兩種團隊策略，第一種：把所有範本編輯權都交給客戶，開發者只給一個起始版本，之後不再從檔案端維護模板，適合交付後就放手的專案。第二種：給客戶編輯者角色，讓他只能編輯頁面與文章，進不了網站編輯器，若要連範本內容都開放但保護結構，需要用到區塊鎖定，這適合需要長期維護、多站共用同一套主題的情境。
我自己傾向第二種，原因是客戶在後台拖出來的版面很難進 code review，也很難跨環境同步，但這沒有標準答案，取決於你交付後還要不要繼續維護這個站。
一張表看 FSE 改變了什麼
| 面向 | 傳統佈景主題 | Block Theme + FSE |
|---|---|---|
| 改頁首 | 改 header.php、FTP 上傳 | 後台網站編輯器拖拉 |
| 誰能改模板 | 只有開發者 | 開發者與網站擁有者都能改 |
| 樣式真相來源 | 檔案（CSS） | 檔案 + 資料庫，資料庫優先 |
| 部署後不生效 | 幾乎不會 | 可能被資料庫自訂版本覆蓋 |
| 版本控制 | Git 管全部 | Git 只管檔案端，資料庫端不進 Git |
FSE 把力量交給了管理者，代價是開發者要多管一個「資料庫也是真相來源」的心智模型。
講完傳統佈景主題與 Block Theme 的機制對照，下一篇我們把焦點放在這整個系列的主軸：為什麼在 AI 時代，Block Theme 這套宣告式、結構化的設計會比傳統主題更吃香？