將 WordPress 主題移植到 Astro 與 EmDash
以實務角度看待主題遷移：把 WordPress 主題當成前端與內容模型轉譯專案，而非一對一程式碼轉換。
將 WordPress 主題移植到 EmDash，不應從尋找一對一模板對應開始。
這種做法通常會帶入過多舊有耦合。WordPress 主題常把呈現、CMS 假設、輔助邏輯與副作用混在一起——在歷史上或許合理，但在現代前端堆疊裡會變得彆扭。
較好的做法是先把「主題實際在做什麼」分開來看。
從主題的真正職責開始
在撰寫任何 Astro 程式碼之前，先用白話盤點現有主題。
辨識：
- 頁面類型
- 共用版型
- 導覽模式
- 彙整（archive）行為
- 可重複使用的 UI 元件
- 主題專屬的資料需求
這會形成一張地圖：哪些必須重建、哪些可以簡化。
轉譯「行為」，不是轉譯「檔案」
WordPress 主題檔案並非 EmDash 裡有意義的單位。有意義的單位是「呈現出來的體驗」。
在 Astro 與 EmDash 中，典型主題會變成：
- 各頁面類型的路由
- 共用結構的版型（layouts）
- 可重複 UI 的元件（components）
- 視覺系統決策的樣式
- 主題所依賴內容模型的 schema 定義
這比傳統「把更多邏輯塞進主題直到能用」健康得多。
在追逐視覺對等之前，先重建內容模型
當團隊在尚未理解目標內容結構前，就試圖保留舊 HTML 輸出時，主題遷移往往失敗。
若 WordPress 主題依賴自訂文章類型、文章 meta、短碼或區塊專屬假設，這些都必須先轉成 EmDash 原生的內容類型與欄位。
否則 Astro 層會一直在補救薄弱的 schema。
若網站仍處於內容轉移階段，請先從 WordPress 遷移至 EmDash 指南 著手。
保留舊設計中值得留的部分
WordPress 主題裡並非一切都要丟棄。常見正確做法是：
- 保留資訊架構
- 保留品牌系統
- 保留已驗證的頁面模式
- 拿掉舊實作包袱
這樣編輯者與讀者仍會感到熟悉，又不必強迫 Astro 去模仿 PHP 時代的主題結構。
應刻意重寫的部分
移植時，下列區塊幾乎都應重新設計：
- 任何與
functions.php綁在一起的東西 - 藏在主題輔助函式裡的邏輯
- 脆弱的短碼驅動呈現
- 依賴外掛的視覺元件
這些正是「忠實遷移」常變成「技術債轉移」的地方。
務實的成功標準
成功的主題移植，不是保留每一個實作細節，而是：
- 保留讀者在乎的內容體驗
- 給編輯者更清楚的結構
- 讓前台更易維護
- 降低安全性與執行期耦合
這正是 Astro 與 EmDash 的強項：你可以像現代前端專案一樣重建呈現層，而不必把主題程式碼當成不可侵犯的聖物。