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 界面的路径.