Gutenberg 開發團隊確認 Meta Box API 不會被正式棄用

在一位參與者對 GitHub 問題發表評論後，圍繞古騰堡將如何處理元框的討論在周末升溫，並擔心元框支持已從最近的里程碑中刪除。

“我看到這個重要問題已從任何里程碑中刪除，”@steveangstrom 說。 “它再次被取消優先級，而博客編輯的花里胡哨的工作量很大，並被添加到測試版中。 這對於 WordPress 作為 CMS 的未來非常令人擔憂。”

該項目的主要開發人員之一詹姆斯·尼倫（James Nylen）向該主題的追隨者保證，古騰堡團隊並沒有忘記這個問題，而是“一個極其複雜的問題，我們才剛剛開始研究，與許多人一起，讓編輯器正常工作的許多其他優先事項。” 他還請求社區幫助規劃和測試支持元框的實現。

這個回應讓很多事情都不清楚。 討論的參與者，其中許多人是擔心必須將所有元框重寫為 React 組件的前景的開發人員，他們想知道為什麼元框不能與新的古騰堡編輯器一起工作，以及為什麼團隊選擇將元框包含在項目的範圍。

“是否可以用 Gutenberg 替換現有的 TinyMCE 帖子編輯器，同時保持界面的其餘部分（包括元框和現有掛鉤）保持不變？” 凱文霍夫曼問道。 當 Nylen 澄清今天所寫的 Gutenberg 旨在成為post_content編輯器時，Hoffman 總結了許多開發人員表達的擔憂：

如果 Gutenberg 真的打算成為一個post_content編輯器，那麼元框應該不理會，因為它們與post_content無關。

此外，需要一個 API 來將 PHP 元框轉換為 React 元框是一個人為的問題。 這不一定是個問題，但它已經成為一個問題，因為在某個地方決定重寫post_content編輯器也應該完全改變元框的工作方式。

您已在 #2251 中概述了編寫此類 API 的巨大挑戰。 將 PHP 元框轉換為 React 用於像 ACF 這樣流行的自定義字段解決方案已經足夠具有挑戰性了，更不用說為當今存在的每個元框實現都這樣做了，無論流行與否。 它不縮放。

正如 Gutenberg 貢獻者所分享的，他們才剛剛開始研究元框問題，現在很清楚為什麼沒有關於該項目如何處理“遺留”PHP 元框的路線圖。 7 月，Nylen 說：“如果我不得不猜測我們最終會在哪裡結束：當前的元框將被移至“遺留”區域，我們將提供 API、文檔和註冊“新式”元框塊的示例——東西。”

管理元盒庫、代理機構和其他相關方的插件開發人員正在關注該問題，以了解如何規劃 WordPress 5.0，該版本已成為 Gutenberg 版本的目標。 Andrey Savchenko 詢問 WordPress 是否計劃正式棄用 meta box API，最終得到了團隊的明確答复。 馬蒂亞斯文圖拉回應：

“WordPress 是否打算正式棄用 Metabox API？”
不。

尚未完全回答的問題是元框如何在古騰堡編輯器的上下文中工作。 它們應該保持不變還是發展？ 我們如何才能以盡可能少的干擾實現設計目標？

這個問題一直揮之不去，不是因為缺乏慾望，而是因為缺乏資源。 該項目的主要重點是提供豐富的內容編輯界面，通過塊的概念優化用戶內容的直接操作。 （在各種項目中廣泛使用元框後，我相信塊可以為滿足其中許多需求提供更好的一步，同時提供更好的用戶體驗。）

Ventura 列出了團隊為處理元框考慮過的幾個選項，並請求社區提供幫助以構建最佳解決方案：

• 如果我們檢測到一個元框已註冊，我們可以回退到舊界面，沒有任何變化。
• 我們可以將編輯內容和修改元信息分成兩個屏幕或階段。
• 我們可以嘗試看看在內容下方呈現它們（PHP）的可行性：#2251。
• 主題/插件/CPT 可以根據需要取消註冊新界面。
• 依賴元框的各種項目可以轉換為 UI 塊（仍然單獨存儲數據）。
• 我們可以實現基於 API 的元框可擴展性，例如 Fields API。

當被要求回答為什麼元框被包含在新編輯器的上下文中的問題時，古騰堡設計負責人 Joen Asmussen 澄清了團隊如何決定將元框包含在項目範圍內：

古騰堡確實只是從編輯框開始的。 啟動目標是在一個統一的塊接口下統一多個不同的接口。 很快就會發現，為了讓我們圍繞這個統一的塊界面創造引人入勝的體驗，我們必須考慮完整的寫作流程，包括設置和發布。

如果 WordPress 的主要優勢是讓任何人都可以輕鬆創建豐富的帖子，那麼我們不能只為我們這些已經知道如何使用編輯器的人設計。 我們必須考慮以前從未使用過 WordPress 的用戶，以及他們對現代發布界面的期望。 否則，我們只會給已經很重的界面增加認知負擔。

元框如何適應古騰堡編輯器的上下文的問題仍然懸而未決。 為了向後兼容，也因為它會影響有關 Gutenberg 開發和屏幕設計的持續決策，討論中的參與者渴望回答這個問題。

“我完全了解在‘屏幕’更換方法方面做了多少工作，”哈維·伊瓦爾斯評論這個問題。 “但是，一個以‘帖子內容編輯器’替換為目標的項目不應該在單方面決定替換整個編輯器屏幕之前回到社區嗎？”

元框 API 並未被棄用，但對於 Gutenberg 將如何支持“遺留”PHP 元框也沒有明確的路徑。 古騰堡團隊表示，由於缺乏資源，該問題尚未得到解決。 如果團隊要找到一種解決方案，該解決方案將無縫地將大多數 WordPress 網站引入古騰堡時代，並且破壞最少，該項目需要社區投入和更好的溝通。

目前，在內容下方呈現遺留 PHP 元框的可行性充滿挑戰，仍有待商榷。 如果開發人員沒有足夠的時間或客戶資源將他們的工作重寫到 JS 驅動的元框中，那麼對於需要保留舊版“PHP”元框的站點來說，可能需要一條明確的退出 Gutenberg 界面的路徑.