將 WordPress 外掛移植至 EmDash
保留外掛的用戶可見行為與資料模型，但無需逐行翻譯 PHP 程式碼。WordPress 與 EmDash 的責任劃分不同，因此首先需決定每個功能應歸屬於網站結構（site schema）、Astro 程式碼、沙盒外掛還是受信任的原生外掛。
在實作外掛程式碼前，請先載入 creating-plugins。當移植會影響集合、種子資料、查詢或前端模板時，請載入 building-emdash-site。那些技能定義了當前的 API，而本技能則涵蓋遷移決策。
了解原始碼
檢查外掛原始碼、安裝行為、資料庫變更、鉤子（hooks）、REST 端點、排程工作、管理員畫面、短代碼或區塊、前端輸出、權限及外部服務。將用戶依賴的行為與 WordPress 特定的實作區分開來。
記錄：
- 必需的內容與配置資料；
- 會變更或發佈資料的操作；
- 授權與信任邊界；
- 背景或重試行為；
- 前端與管理員互動；
- 匯入、遷移與回滾需求；
- 複製資產或程式碼的授權義務。
如果原始碼、預期行為或目標 EmDash 環境缺失，請報告缺口，而非自行發明對等方案。
分配每個責任
| WordPress 責任 | EmDash 目的地 |
|---|---|
| 自訂文章類型、分類法或元資料（metadata） | 透過網站結構或種子資料建立的集合、分類法與欄位 |
| 全站呈現設定 | 由 Astro 模板讀取的網站設定（site setting） |
| 外掛所有的用戶設定 | ctx.settings；將憑證宣告為加密的 secret 欄位 |
| 外掛所有的游標（cursors）、快取或內部狀態 | 外掛範圍的 ctx.kv |
| 外掛所有的可查詢記錄 | 已宣告的 ctx.storage.<collection> 儲存 |
| 內容探索、翻譯或發佈 | 以能力（capability）控制的 ctx.content 與 ctx.schema；政策鉤子與操作擁有獨立的權限 |
| 執行時分類法或重導向管理 | 具有狹義讀寫能力的 ctx.taxonomies 或 ctx.redirects |
| 留言管理 | ctx.comments；讀取會暴露個人資料，審核使用預期狀態 |
| WordPress REST 端點 | 已宣告的外掛路由，包含明確的方法、輸入、標頭與回應模式 |
| 排程事件 | cron 鉤子與 ctx.cron 排程 |
| 管理頁面或表單 | 沙盒外掛使用 Block Kit；僅限受信任的原生外掛使用 React |
| 文章編輯器 metabox 或已儲存條目操作 | 私人路由上的 admin.editorPanels 或 admin.editorActions |
| 用戶或作者查詢 | 需 users:read 權限的 ctx.users |
| 對外 HTTP 請求 | 使用 ctx.http.fetch()，需 network:request 與 allowedHosts 條目 |
| 媒體操作 | 分離的元資料讀取、位元組讀取、元資料寫入以及上傳/刪除權限 |
WP_Query 或模板標籤（template tag） | Astro 網站程式碼中的 EmDash 內容 API |
| 短代碼（shortcode）或編輯器區塊 | 盡可能使用現有的 Portable Text 內容；自訂 Portable Text 區塊需要受信任的原生外掛 |
| 原始 head 標記或指令碼（scripts） | 受信任的原生外掛使用 page:fragments；透過註冊表安裝的外掛僅能貢獻經過驗證的 page:metadata |
請勿透過直接存取 EmDash 系統表格來建立集合或分類法。應使用公開的結構（schema）、種子資料（seed）、CLI 或管理員邊界。請勿使用內部 REST 路由來模擬不存在的沙盒 API。
保持權限分離：讀取媒體元資料不代表可讀取位元組，審核不代表可刪除，發佈政策不代表可執行發佈操作，內容還原不代表可讀取一般內容。
選擇外掛格式
預設使用沙盒外掛。它透過安裝時的信任合約支援可攜式鉤子、路由、已宣告的儲存、媒體、網路存取、MCP 工具以及 Block Kit 管理員 UI。
僅在功能需要主進程存取、React 管理員程式碼、Astro 渲染元件、原始頁面片段或自訂 Portable Text 區塊定義時，才使用受信任的原生外掛。請在遷移計畫中說明額外權限與發佈限制。
某些 WordPress 外掛並不需要對應的 EmDash 外掛。自訂文章類型加上前端模板可能僅需轉換為結構（schema）、種子資料與 Astro 頁面。當靜態網站結構已涵蓋行為時，請勿添加執行時擴充。
規劃資料搬移
在編寫執行時期程式碼之前，先描述現有 WordPress 資料如何對應：
- 對應文章 ID、slug、語言、作者、狀態、修訂版本與發佈日期；
- 保留文章、分類術語、媒體與外掛自有記錄之間的關聯；
- 區分一次性匯入與需要持續同步的資料；
- 讓匯入過程可重新啟動，並定義如何偵測重複資料；
- 當需要用於調解或重導向時，保留來源識別碼；
- 識別無法在沒有產品決策的情況下表示的內容。
使用種子資料作為新網站的初始結構與範例內容。使用匯入器或遷移路徑處理現有網站的生產資料；種子資料並非備份或持續同步機制。
驗證等效行為
透過用戶與執行環境操作的邊界進行測試：
- 針對內容模型變更進行結構與匯入資料的斷言；
- 針對沙盒鉤子、路由、儲存與權限進行生產邊界的外掛測試；
- 針對管理員與前端流程進行瀏覽器驗證；
- 當來源功能依賴於重啟、重複傳遞、授權與失敗情況時，也應測試這些情況。
比較可觀察的行為，而非內部結構。記錄有意的差異，以及任何仍不受支援的 WordPress 功能。
交付移植成果
提供：
- WordPress 行為與資料的簡明清單；
- 責任對應表與沙盒/原生外掛的決策；
- 資料遷移或種子計畫；
- 外掛與網站程式碼的實作；
- 驗證證據與已知缺口；
- 重複使用程式碼或資產的歸屬與授權聲明。