Gutenberg 贡献者探索将 iframe 用于 Meta Box 的替代方案

周末，围绕在古腾堡元盒中使用 iframe 的讨论变得更加激烈，因为相关的开发人员恳请团队考虑当前方法的不利之处。 古腾堡领导层的回应最初转移了人们的担忧，将 iframe 的实施展示为“目前有效”的实验，但不是团队将要发布的。

凯文霍夫曼没有得到对 iframe 方法的性能和可访问性的具体担忧的回应，而是被敦促考虑元框的未来以及“不会转换为块的情况（如果有的话）”。 当开发人员社区被反复要求测试和提供反馈，但在对使用 WordPress 作为 CMS 的网站至关重要的问题上遇到偏差时，GitHub 的讨论开始变得更加激烈。

“人们很担心，也很沮丧，在我看来，他们完全有权这样做，因为人们认为，从事古腾堡工作的团队对元盒的使用方式知之甚少，不太关心会产生什么影响，并且无论如何都将朝着他们的愿景前进，”约翰霍普金斯大学对外事务办公室的首席开发人员 Jimmy Smutek 在回应古腾堡合作者承认对反馈不屑一顾时表示。

在几轮开发人员加入该线程以揭穿元框的 iframe “现在工作”的概念之后，Gutenberg 首席开发人员 Matias Ventura 昨天加入了讨论，并确认该实验可能很快就会被放弃。

“我很高兴谈话最终重新聚焦到了这个话题的问题上：当前在 iframe 中处理元框的方法是否可行？ 答案是否定的，”文图拉说。 “iframe 是一个实现细节，我认为我们可以相对容易地放弃。 所以让我们专注于此。”

他还谈到了流行的观点，即 WordPress 应该在对元框进行大修之前对编辑器本身（而不是整页）进行迭代增强。

“有些人所说的务实方法与该项目从一开始就具有的设计方向不相一致 - 朝着完全网站定制的方向发展 - 以及迄今为止决定我们决定的因素，”文图拉说。 “这里没有什么必须是最终解决方案，我们正在探索设计场所内的可能性，并将其放在那里进行测试。”

文图拉说，不改变编辑屏幕的其他方面肯定是古腾堡采取的最简单的方法，但它“对项目的目标和 WordPress 的长期用户不公平”。

WordPress 开发人员 Gary Jones 认为，追求更迭代的方法不会改变项目的目标，但会使更多网站在此过程中出现。

“一次迈出一步，无论如何都不会损害项目的目标，”琼斯说。 “如果这是目标，您仍然可以进行全尺寸定制，但通过逐步进行，您将与开发者社区的其他成员一起参与。” Jones 将定制器作为 WordPress 中的一个功能示例，其概念随着时间的推移通过多次迭代而得以实现。

Ventura 回应澄清了 Gutenberg 团队对项目进行迭代的方法，这是一种从一开始就支持基于块的内容创建的范式转变。

“我们提出了一种分阶段的方法，从马特最初的新焦点帖子中，它只是考虑了不同的步骤，”文图拉说。 “古腾堡项目通常分为三个阶段：从帖子编辑器到页面模板，再到网站建设。 最原始的是，范式是内容是一个单一的区域，以块为主要概念，结果可以清晰地直观地表示出来，而不需要过多的抽象。”

Ventura 还向后续讨论的人保证，该项目不会放弃对元框的支持，但需要更多时间来试验不同的界面选项。

“WordPress 总是与用户一起移动，我们承担了找出开发路径以简化现有代码转换的负担，”他说。 “作为一个项目，我们之前说过我们不会放弃对 WordPress 元框的支持，而且我们必须探索在新范式中我们必须做出哪些界面决策，包括加载经典编辑器的可能性当我们检测到我们无法处理或与试图更清楚地描述什么是内容和什么是元数据的编辑器直接冲突的元框时。”

他还表示，该团队计划创建更多机制来处理不兼容问题，并“允许选择加入更多内容（例如，如果您对在古腾堡中显示的元框感到满意，您可以声明支持它，反之亦然。 ”

目前正在开发一种不使用 iframe 来渲染元框的新方法。 Riad Benguella 创建了一个拉取请求，试图撤消 iframe 并实施 Tom Nowell 在讨论期间提出的建议：

与其在设置页面上加载 Gutenberg，不如将其加载到主经典编辑器页面中，在其原生环境中加载元框，然后通过 JS 将其容器 DOM 节点提升到组件中。

然后我们使用不同类型的切换来确保仍然可以使用经典编辑器。 这条路：

– 我们避免 iframe 废话
- 就注册而言，元框的工作方式与以往一样
– 现有的 JS 按预期工作，无需 hack 就可以在 PHP 端工作

新方法的优点是链接、模式、重复样式表没有问题，以及使用 iframe 的其他缺点。

古腾堡团队需要一种新的沟通策略

关于将 iframe 用于元框的长期可行性的讨论强调了古腾堡领导之间缺乏统一的信息或沟通策略。 该项目的合作者已经对社区没有把握愿景变得不耐烦了，但沟通分散在各种博客、评论、Slack 频道和 GitHub 讨论中。

Morten Rand-Hendriksen 开设了一个新问题，要求提供一个可以作为古腾堡范围、方向和目标的简明语言大纲的集中资源。

Rand-Hendriksen 说：“我的观察是，由于缺乏包含这些信息的单一权威明语资源，社区正在努力看到古腾堡项目的更广泛范围。” “这造成了各方高度的猜测、沟通不畅和挫败感，项目因此受到影响。”

Gutenberg 确实有一个文档中心，但到目前为止，这些文档更具技术性，并且缺乏团队如何实现其目标的实用路线图。 当前文档的 FAQ 部分最接近 Rand-Hendriksen 在他的工单中要求的明语资源。 Gutenberg 的 GitHub 存储库和 WordPress.org 插件的 readme.txt 文件给人的印象是，该项目只是将当前编辑器更新为基于块的，而不是彻底检查整个编辑器屏幕。

“由于这些信息的分散性，任何人都很难清楚地了解整个项目，尽管马蒂亚斯和马特的帖子很好地解释了项目的宏伟愿景，但他们缺乏具体的通俗语言分解社区需要了解这个项目是什么以及它的发展方向所需要的基本要素，”Rand-Hendriksen 说。 “它们也作为独立的信息卫星存在于项目周围，而不是项目本身的核心部分。”

社区正在关注 GitHub 问题，他们希望看到以更透明的通俗语言产品路线图得到解答的问题。 像这样的文档可能会帮助 Gutenberg 团队更好地传达项目的目标，并避免发送导致不必要的混乱的混合信息。