Gutenberg: iframe是元框的可行的长期解决方案吗？

1. ...古腾堡目前在主栏和侧边栏使用两个独立的iframe。 如果我们支持在“标题”之后出现的元框，则理论上会导致第三个iframe。 这是否会带来有关插件如何排队必须影响所有iframed元框的资产的任何问题？

今晚我进行了一些性能测试，并且在“网络”选项卡中发现了此发现，这令人震惊。 似乎所有在父窗口中排队的CSS和JS资产也都在主列iframe和侧边栏iframe中排队了-这意味着每项资产总共请求了3次，有效地使使用时资产请求的数量增加了三倍古腾堡。

启用浏览器缓存后，页面权重的损失得以减轻，但是资产请求的数量仍然增加了两倍。 我认为这样做是为了使每个iframe拥有允许meta框正常工作所需的资产，但是可以肯定的是，这并不是解决未来资产入队的解决方案。

感谢您提出问题，并感谢您提供@kevinwhoffman的见解。 最好能想一想，今天我们在古腾堡中使用的元框是一个实验，在许多方面，随着项目确定了前进的方向，这是一种等待模式。 说这是“暂时”有效的，但不是我们会附带的。

综上所述，我认为重要的是要查看将来的元框将用于什么。 在哪些情况下（如果有）不会转换为块？ 所有metabox都必须在移动设备上工作吗？ 甚至还有我们未曾探索过的替代界面吗？ 我敢打赌现在，这是关于考虑这些可能性，并为当前州和未来州发展的道路。

现在，需要修复古腾堡元版本当前版本中存在的错误，这是我们的重点。 性能需要进行这种修复。 在移动方面，元框长期以来一直是一个问题，我们在这里并没有使它变得更糟。 也就是说，我们应该在将来寻求更好的解决方案。 循环回去并记住这只是一个“今天”的解决方案非常重要，因为我们会不断迭代并继续自由考虑更好的选择。

最好能想一想，今天我们在古腾堡中使用的元框是一个实验，在许多方面，随着项目确定了前进的方向，这是一种等待模式。 说这是“暂时”有效的，但不是我们会附带的。

iframe方法行不通，甚至不行。 上面列出的相关问题提供了不能以主要方式工作的元框示例。 此外，即使这些问题已解决，在任何情况下也不应将页面重量和请求数量增加两倍。

综上所述，我认为重要的是要查看将来的元框将用于什么。

相应地，每次出现元框问题时，都会发生这种情况。 请不要将对话转移到未来的元数据块上，而是将讨论围绕现有元数据盒所面临的问题进行框架将非常有帮助。 再来一次：

是否可以解决这些问题而无需修改生成meta框的主题或插件？

迄今为止，我还没有任何证据表明meta box将继续与Gutenberg一起使用。 如果答案是否定的，那么我们应该停止假装5.0将是另一个WordPress版本，并开始诚实地打破向后兼容性。

嗨，凯文，

感谢您提供详细的报告。 我认为可以在一定程度上解决很多问题。 这也是对iframe方法是否行得通，以及可以采取多远的探索，因此进行此类对话并记录这种方法的缺点是一件好事。

是否可以从超出iframe的元框启动内容窗口？

您是说像模态灯箱那样占据整个页面吗？

您是说像模态灯箱那样占据整个页面吗？

那将是一个例子，但是我更要提到任何需要显示内容的场景，这些场景不在iframe的范围之内。

例如，我可以单击侧边栏中的一个按钮来触发页面中心的内容框吗？ 如果该内容框位于iframe的内部，则在侧边栏中的iframe尺寸之外将看不到它。

合理的下一步是从iframe调用父文档中的函数。 但是，插件当前并未像这样编写，并且需要对其进行修改将无法支持_legacy_元框的全部目的。 我无法强调的是，在不修改现有主题或插件的情况下，可以决定需要使用的解决方案。

知道iFrame实施对插件/主题资产的负面影响后，我认为这应该使项目暂停。 真正的答案是WordPress提供了Fields API https://github.com/sc0ttkclark/wordpress-fields-api-如果没有的话，如果我们根本不关心性能的话，用Gutenberg有效地实现元框几乎是不可能的。

如果我们真的不打算在其“就绪”之前就交付Gutenberg，那么我说我们应该同样重视Fields API，以便metbox可以在Gutenberg中与React正确且无缝地协同工作。

合理的下一步是从iframe调用父文档中的函数。 但是插件目前还没有像这样编写，并且需要对其进行修改将无法支持支持旧版元框的全部目的。 我无法强调的是，在不修改现有主题或插件的情况下，可以决定需要使用的解决方案。

是的，绝对是我在执行此操作时遇到的一个问题。 iframe之间的交叉交流听起来不太好。 还有其他可供选择的探索方式。

但是，肯定会有某些情况，某些主题插件将被破坏，并且不可能容纳所有可能的用例，我认为也许更好的目标是为绝大多数用户和用例创造良好的体验。 当前的iframe解决方案完全有可能无法实现该目标。

可能值得注意的是，在最近的《 Core Customizer开发说明帖子》中，已经引起了人们对删除使用iframe作为_improvement_的关注。 在这里实施iframe作为解决方案似乎倒退了一步。

嗨，马西多斯，

如果我们真的不打算在其“就绪”之前就交付Gutenberg，那么我说我们应该同样重视Fields API，以便metbox可以在Gutenberg中与React正确且无缝地协同工作。

我同意Fields API会有些不错。 但是，这还需要人们采用字段API。 如果没有很多人愿意为古腾堡重写其插件/主题，我认为他们不愿意为Fields API重写。 我也认为这是在上一期杂志中提到的，因此我建议在GitHub历史中寻找它，并添加您对Fields API如何使Gutenberg受益的想法。

...不可能容纳所有可能的用例，我认为也许更好的目标是为绝大多数用户和用例创造良好的体验。

我同意，而且我认为，如果古腾堡（Gutenberg）坚持彻底检查编辑器而不是接管整个页面，那么该目标将可以实现。 然后，我们可以将现有的挂钩保留在原处，并且meta框可以像现在一样继续彼此通信。 而且，资产排队不会成为问题，因为它可以像今天一样工作。

我与Yoast提出的这个概念非常吻合，在我看来，Yoast可以保留已经完成的许多工作，同时缩小项目范围以专注于编辑器组件。

资料来源： https :

我也非常同意Yoast提出的建议。 它提供了一个良好的过渡阶段，为插件作者提供了将元框转换为新块的时间。 然后，作为最终替换整个编辑器体验的计划的一部分，WP作为一个项目可以说诸如“在x版本中，将不赞成使用metaboxs”之类的内容，因此我们准备了一个_plan_，以朝着更好的最终目标迈进。

只是要注意，由于没有中央TinyMCE实例可以与之通信，因此该概念破坏了现有的元框。 而不是支持80％的metabox，它将支持90％（我由这些数字组成）。

这个概念并不能解决向后兼容的问题，而只是将其解决方案推迟到以后出现相同的问题。 古腾堡是迈向WP中JS接口的第一步，它不会随着古腾堡而停止。

重用Gutenberg片段来构建此概念相对可行，但这不是我们要优化的UX，我们希望首先构建最佳的编辑器，并使其对没有向后兼容性问题（新安装，无metabox的人）可用。 ）。

当我们认为古腾堡的理想愿景已经准备就绪时，我们将有时间讨论升级路径策略。像这样的概念是升级路径的一种选择，但绝对不是最终产品。 其他升级路径也是可能的。

让我们现在构建最好的编辑器。

当我们认为古腾堡的理想愿景已准备就绪时，我们将有时间讨论升级路径策略...

我不能再不同意这个。 如果理想的编辑器无法与现有站点兼容，为什么还要花费数千小时来开发它呢？ 如果第一印象是它破坏了他们依赖的UI，那么用户将永远不会体验到理想的编辑器。

如果理想的编辑器无法与现有站点兼容，为什么还要花费数千小时来开发它呢？

只是要清楚一点，

• 无论您为编辑器选择什么选项，都不可能与现有网站100％兼容，因为插件具有对DOM的完全访问权限，您在dom中进行的任何修改都会破坏向后兼容性
• 只有一种方法可以确保100％向后兼容任何更改：不要进行更改。 禁用Gutenberg的插件已经可用。
• 该编辑器已经与大量网站兼容。 但是，就像其他所有内容一样，当它崩溃时，它总是更加可见。

不可能与现有网站100％兼容

现在已经很清楚了，请构建我们认为最适合WordPress未来的编辑器。

所有metabox都必须在移动设备上工作吗？

是的，为什么不呢？

在哪些情况下（如果有）不会转换为块？

对于博客文章，我理解为什么“万物无阻”可能有意义，但这可能会忽略元数据的一般用例：看不见的数据。 像，我可以使用一个metabox来公开UI，以将分析数据添加到帖子中。

对于诸如“自定义帖子类型”之类的可能仅由元框组成的事情，我很难理解新的UI。 由于WordPress缺少用于数据的全面的CRUD API，因此许多开发人员使用WP_Query及其相关API套件作为替代，并且他们在CPT编辑屏幕上使用元框来隔离用于添加特定数据的UI或协会。 很多（大多数）自定义帖子类型在野外都不再强调或忽略“内容”的传统用法-因此，对于博客帖子，是的，内容是最重要的，但对于许多CMS用例，所见即所得并不能很有意义。

在当前的迭代中，Meta Box支持是一个附加组件，而在许多人的现实中，Meta Boxes是UI，API和他们用来组成CMS的机制。 <iframe> s是古拉格。

而且我们忘记了WP永远建立的价值：我应该能够更新到WP的最新版本，而不必重写任何内容。 我在WP上有很多项目，我再也不会碰。 我是否可以相信其中的某些内容不会因这种变化而疯狂打破？

我将以这个示例结束：如果我的“旧”元框之一触发了媒体用户界面的打开，那么在这种“新”场景中，如何在iframe中没有人（我不再与之合作的客户）工作）重写代码？

正如我在这些对话中所跟踪的那样，我不禁感到，正在发展和拍摄有关古腾堡的力量本身并没有使用或处理元框。 感觉就像是一种“端到端意味着手段”之类的论点，其中之所以容易说是因为这种手段一开始就没有被重视。

请理解，对于我们许多人来说，我们有数十个网站在更新到WordPress 5.0时会立即中断，该产品在历史上一直告诉人们可以安全升级，因为它具有向后兼容性的狂热。 这里所讨论的并不是小事（例如样式）的中断，而是潜在的节目停止器，它将使成千上万（或更多）站点的管理员端立即无法使用。 那是可怕的东西。 作为一个行业，我们以WordPress坚如磐石的可靠性向人们推销。

就像上面的@staylor指出的那样，在我们的大多数网站（中高端复杂性公司网站）上，元框都是UI。 编辑器（如果使用的话）只是其中的一部分。

当我们认为古腾堡的理想愿景已经准备就绪时，我们将有时间讨论升级路径策略。像这样的概念是升级路径的一种选择，但绝对不是最终产品。 其他升级路径也是可能的。

我认为将其推迟到很晚是错误的。 特别是因为许多组织将需要至少1-2个季度来准备。

我从WordPress的多个主要开发人员那里听到了一句格言，我想在这里记住这一点很重要：当有人在其网站上采用WordPress时，他们并没有采用WordPress 3.7或WordPress 4.8，而是采用了WordPress。 绝对有必要使此路径尽可能无缝。 这会破坏一切，这没关系（几乎每个WordPress版本都有向后兼容性破坏），但是需要将其最小化，记录和交流。

不可能与现有网站100％兼容

如果您不打算兼容，那一定要去破坏它。 调用第一个发行版WP ++或WPNG。 最好事先声明事情很可能会破裂并让人们为之做好准备。 当前的“欺骗”似乎会像往常一样对所有人都不利。

iframe在可用性方面是死胡同。 在一个meta框中打开了一个基于jquery的日期选择小部件，当在窗口上的其他随机位置单击并没有关闭它时，感到惊讶。 花了我几分钟时间才意识到click事件在父窗口上，并且没有传播到iframe中。 所以我很惊讶，但最终还是明白了，但是您将如何向用户解释这样的事情？ 您是否希望每个插件都能回答每个用户对如此琐碎的UX期望的问题。
您希望外部链接如何工作？

人们将iframe仅用作最后的手段是有很大原因的。

我的有效建议是，只要yo seo无法在其中正确工作，就不要声明meta box就绪。 就交互而言，它既有点复杂，又安装在站点的大量负载上。 如果gutenberg无法使用它，可能没有人会使用它。

我的生产建议是不要声明meta box就绪

正如上面@karmatosed所指出的：“我们可以稍微想一下，今天我们在古腾堡中使用的元盒是一个实验，从很多方面来看，这是项目制定方向时的一种保留方式。 “现在”有效，但不是我们将附带的产品。”

为了提供一些真实的数据，我想与我过去合作过的WordPress网站共享此界面。 内容字段是此自定义帖子类型的一小部分，虽然某些自定义metabox字段可以转换为块，但大多数包含管理员使用的数据，第三方服务通过REST API使用的数据，或用于将元数据添加到条目。 尽管看起来有些混乱，但此设置是专门为与客户端的工作流一起使用而设计的，并使用基于清晰分隔的严格内容模型来确保站点的未来版本可以独立处理每种类型的内容。

将该网站重构为在古腾堡现实环境中工作将需要很长时间，并且需要大量资源，因此，除非以与现有内容非常匹配的方式来处理元框，否则该网站所有者可能会还原到WP的古腾堡版本并保留下来在那里无限长的时间。

作为参考，虽然它看起来很广泛，但它既不是我构建的最复杂的metabox设置，也不是我所看到的最复杂的设置。 该示例显示的是通过元框实现的现实解决方法，以满足对内容Blob以外的内容进行正确建模和分离的需求，古腾堡（Gutenberg）必须从功能和功能上妥善处理。

绝对有必要使此路径尽可能无缝。

同意

这会破坏一切，这没关系（几乎每个WordPress版本都有向后兼容性破坏），但是需要将其最小化，记录和交流。

同意

无论您为编辑器选择什么选项，都不可能与现有网站100％兼容，因为插件具有对DOM的完全访问权限，您在dom中进行的任何修改都会破坏向后兼容性

同意，我认为这里不会有人反对您。 但是，我认为仍然存在讨论发生故障以及何时中断的空间。 这些决定也会影响开发人员必须采取哪些工作来修复已损坏的内容。 由于调整了dom选择器，与必须重写自定义内容模型以适应新的Gutenberg范式（其中元框只能排序）的调整之间，存在很大的区别：)元框周围的争论向我表明，这可能不是以突破古腾堡的核心版本为目标的好事。

我知道所有这些都是实验，我想@kevinwhoffman也

我也认为在合并提案到位之前，我们不会看到大量开发人员将其现有工作转换为Gutenberg的想法，因此请记住，Gutenberg最初发行版的实质是什么。

tldr; 我们期望与古腾堡一起破裂吗？ 是! 但是我们仍然应该选择要破坏的东西，以及在古腾堡的初始迭代中该破坏走到了多远的程度。

是的，我们对WordPress的开发一直都足够期待某些事情会从一个版本发布到另一个版本。 在某种程度上，这正是我的观点。 只要我们将Gutenberg作为另一个WordPress更新提供，那么它应该不会破坏任何其他更新。 如果我们打破了这种信任，那么编辑器在一天之内的表现如何都无关紧要。

这是过去几个月来我一直在开发的插件的当前屏幕截图。 在这种情况下，可视化编辑器毫无价值，并且试图将所需的那种接口塞进设计用于内容可视化编辑的接口中是没有意义的。

我实际上正在认真考虑是否应该继续为WordPress开发它，因为我的所有工作都可能在下一版本中被撤消。

如您所见，我需要访问我的元字段中的媒体上载器，将大部分页面放到iframe中会使该界面非常笨拙。

在WordPress上构建的插件，工具和自定义网站中有数百万种这样的界面。 将这些用户像二等公民一样对待，而倾向于使用“新热点”块，这是不可接受的。 元框需要在编辑页面中保持其当前的集成度和突出性。

我非常支持Yoast对古腾堡的看法。 我尚不清楚古腾堡团队如何将“升级可视编辑器”重新解释为“替换整个后期编辑界面”，但似乎与所谓的“ These修斯之船”不符。

在这种情况下，缺乏明确的方向和对现有标准工作流程的支持正在严重损害开发人员。 在没有我可以依赖的一套可靠的钩子和工具的情况下，我该如何继续构建项目？ 认为这么大的软件项目会在一次更新中完全颠覆开发人员的标准工作流程，这是不合理的。 这些对话才刚刚在11月进行，这是疯狂的，当时计划在年初批准合并。

@aaronjorbin好吧，似乎在这里出现通信问题，如https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/中明确指出

此版本包括期待已久的meta-box支持（需要测试！），

它不是一个“想法”，它不是一个“实验”，就像每一个软件可能仍然包含错误一样。 如果在该帖子中将其称为“实验”，我将不会对其进行测试。

回到主题，我发现这里的主要问题是试图避免声明损坏。 根据我对JS framewoks的有限了解，很难“半生半熟”，一旦您决定对它们进行主屏幕控制，就需要对它们进行所有操作，因此，唯一的方法就是在gutenberg编辑屏幕中将meta框设为头等公民。
由于“旧版”插件不太可能适应，因此这意味着gutenberg需要成为现有网站的明确选择加入选项。 我讨厌UX fork的想法，但是至少以这种方式，会有一条前进的道路将起作用，而且如果现在宣布，人们将能够进行准备。

在阅读了讨论并思考了我使用WordPress构建的项目以及我看到的人们使用WordPress所做的事情之后，我得出结论，古腾堡（Gutenberg）应该加入自定义帖子类型。 这将允许使用CPT处理结构化数据的当前网站继续工作，并允许使用WordPress作为CMS的新网站进行构建。 我只想提醒您，注册帖子类型时，我们可以显式声明对editor字段的支持以及其他功能。 那么，为什么不在那里添加对Gutenberg的明确支持呢？ 当然，这不能解决在帖子和页面上添加元框的问题，但将来可以将WordPress用作CMS。

可以为这些iframe添加一个新问题。 当用户会话退出时，古登堡上方和iframe内会两次显示WP登录屏幕。

只是让开发人员意识到这一点。

我相信，只有更多可能的方式像Microsoft那样，我会更多地遵循所有这些。

Windows XP =不含Gutenberg的WordPress
Windows 10 =带有Gutenberg的Wordpress。

那些2不能与其他软件包混合和更新。

Joomla和Drupal做到了。 为什么不。 我一点都不喜欢什么，但是替代品是什么。

在阅读了讨论并思考了我使用WordPress构建的项目以及我看到的人们使用WordPress所做的事情之后，我得出结论，古腾堡（Gutenberg）应该加入自定义帖子类型。

分开的管理员将是古腾堡最糟糕的结果之一。 我在https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490中概述了原因。

这次讨论真是让人发疯。 看来，无论有多少人对当前的痛点提出务实的解决方案，都有一些关键人物似乎完全不受批评。 不幸的是，这些人拥有最终决定权，因为到目前为止的讨论表明，一些关键人物可能会遇到数百名担心开发人员的人。 我担心这会对WordPress生态系统造成所有损害。 将Gutenberg设为编辑器，而不是编辑屏幕。 不要破坏WordPress。

凯文·霍夫曼：

我与Yoast提出的这个概念非常吻合，在我看来，Yoast可以保留已经完成的许多工作，同时缩小项目范围以专注于编辑器组件。 资料来源： https :

我相信Yoast提出的前进道路将是对WordPress Core的巨大改进。 一个新的编辑器来创建内容，许多用户将其作为对当前内容的改进。 对于WordPress来说，这是一个较小的步骤，但对用户来说却是一个很大的进步。

这是一个热门话题。 我承认有时我们（至少我）会在我的评论中不屑一顾，对此我深表歉意。 我们收到了很多反馈，好，坏，客观，无用，有时很难区分它们。 我们是人类。 试着站在等式的另一端，成为构建这个事物并接收所有这些反馈的人。 IT可以感觉到接近“人身攻击”，大脑倾向于通过不屑一顾做出反应，而我们不应该这样做。

人们评论和阅读博客文章经常认为我们正在发现meta box问题以及所有相关问题。 不是。 我们在古腾堡工作了一年。 也许您只是发现/尝试过古腾堡（Gutenberg），但我们没有，我们已经花了足够的时间研究大多数向后兼容性问题，并且我们为大多数问题提供了答案。

请放心，我们先回答一些问题：

古腾堡的目标是什么？

不是，而且从来没有，Gutenberg的主要目标是为WordPress Core的未来铺平道路。 从技术上讲，通过利用REST API，客户端UI并统一核心概念：小部件，短代码，块，内容元框（在一个独特的概念“块”下），并通过回答以下问题获得明智的体验：如何简化网站建设（自定义思维）并在WordPress中发布内容（思维编辑器）。

古腾堡编辑器的目标是什么？

与您在这里和那里读到的内容不同，重点始终放在重新设计整个页面上。在第二个或第三个每周的Gutenberg会议中显示了Gutenberg编辑器页面的第一个模型。 我们仍处于原型开发阶段。 第一个alpha版本之前的几个月。 该设计接近我们现在所拥有的。

那Metaboxes对WordPress重要吗？

他们是。 像简码，自定义TinyMCE按钮一样，它们被大量使用和滥用以扩展WordPress的编辑器页面。

简码，TinyMCE按钮和元框之间有什么区别？

主要区别在于“元框”没有“目的”，这只是扩展编辑器页面而不保持一致性的一种方式，而“简码”和“ TinyMCE”按钮只有一个。

简码是在渲染阶段转换为内容的字符串，TinyMCE按钮是添加到TinyMCE工具栏的自定义按钮，并使用TinyMCE API与编辑器的内容进行通信。 元框？ 我不知道，它们可以是任何东西，您只需添加一堆HTML，Javascript和PHP来扩展编辑器的页面以及保存时的行为。

缺乏“目的”是问题还是优势？

好！ 可以将其视为“专业版”，因为插件可以使用编辑器完成他们想要的任何事情，包括：

• 替换任何按钮，文本区域，输入，div，任何东西。 完全访问DOM
• 使用任何全局javascript变量，包括TinyMCE的全局实例

灵活吧！ 但是WordPress更新呢？ 对编辑器屏幕的任何更新。 任何TinyMCE更新，任何类更改，任何新的div ，任何按钮被删除/移动，任何更改都破坏了与插件的兼容性，因为作为WordPress核心开发人员，您不知道使用Metaboxes的插件是什么。

我们能否得出结论，就WordPress的长期而言，Metaboxs会锁定其发展（不管古腾堡如何）？

对，他们是。 互联网的历史证明了无数次，以至于不发展的技术消失了。 （请不要对👎做出反应，如果您不喜欢这个答案，那是事实而不是观点）

好的，但是如果我们被Metabox卡住了，那么如何使WordPress向前发展呢？

这是一个很好的问题，在回答之前，我们需要了解WordPress插件中Metabox的当前用法。

当前的插件将Metaboxes用于什么？

我想说“ Metaboxes”插件有两类：

• 将元框作为内容（通常存储在帖子元中，但并不总是存储）
• Metaboxes作为对编辑器体验的增强（SEO，拼写检查等）

好吧，知道了，我们如何前进？

我们需要三件事：

• 提供在古腾堡（或WordPress的任何更新）出厂时构建或升级这些插件的方法。
• 为使用这些插件的人们提供最佳的升级途径。 这包括：看看这些插件是否仍然可以适应未来的发展，以及如何最大程度地减少破损。

好的，但是您不是说对编辑器页面所做的任何更改都会破坏插件（包括仅替换内容区域）吗？

对！ 因此，如果我们希望不破坏任何插件，我们将获得一个独特的选择。 提供一种无需更改即可保留当前编辑页面的方法。 这正是禁用Gutenberg的插件的用途。

我个人不会将其称为良好的升级途径，它甚至不是升级，还有更好的选择吗？

此升级路径（禁用Gutenberg）是必须的，但是可以，我们可以做得更好。 如果您看一下使用Metabox的插件，则其中90％的插件与内容区域没有任何交互，因此，如果仅替换内容区域（最简单的方法），我们将仅破坏10％的插件。

因此，唯一没有破损的方法就是禁用古腾堡。

最佳的Gutenberg用户体验包括将metaboxes插件替换为与新的Gutenberg可扩展性API具有相同功能的插件。

就是说，我们注意到大多数使用Metaboxes的插件都将它们用作保存要发布的内容的内容，并且我们可以在Gutenberg屏幕上进行这些工作，从而在插件作者升级其插件时享受整个体验。

这是每个人都在谈论的iframe解决方案吗？

是的。 我们在iframe中展示了具有其缺点（链接，模式，重载资产）的元框，但同时它允许80％的插件在享受整个古腾堡体验的同时工作。 该解决方案刚刚落地，我们仍在尝试中。 可以肯定的是，没有办法使所有的metabox都可以工作并对编辑器进行更改。

我知道，您能概述一下升级的可能性吗？

当然。

1-禁用古腾堡：不要破坏100％的插件
2-古腾堡（Gutenberg）仅替换内容区域：90％的插件正常工作，用户体验受到影响
3-古腾堡取代了整个屏幕：80％的插件都能正常工作，用户体验更好
4-古腾堡与兼容的插件：最好的用户体验

那么，我们需要做什么？

我们的目标是建立第四个选项，因为它是WordPress未来的最佳选择。 我们的目标也是以某种方式构建古腾堡，以便在需要时可以重用其部件来实现第二和第三选择。

如何选择加入另一个选项？

这尚未决定。 有一个插件可以选择所需的升级路径。 通过检测某些Metabox自动降级是一种选择...

这就是我解释这些问题背后的原因的方式，如果您想用“荒谬”，“管理不善”，“执行不佳”之类的词来回答……我是一个简单的开发人员，花了整整一年的时间思考整个WordPress（核心和社区）的最佳可行方法已接近极限。 我个人可能不会就此问题作进一步的答复，但我正在听取反馈，如果得到反馈的信服，我将调整我的推理。

我们都在同一条船上，我们想要最好的WordPress。

里亚德，非常详尽的解释。 感谢您抽出宝贵的时间来编写它们。 让我帮助您避免使用💪和🤗限制该限制。 希望能帮助到你。

关于metabox，我很自然地将Fields API作为核心。 将重写我们的插件只是为了摆脱一段时间后可能会收集到的所有混乱的自定义元框解决方案。

现在，对于具有复杂的metabox设置的人来说，只要将Fields API构建在ACF或CMB之类的框架之上，它们就是他们的救星。 这些框架的开发人员只需要切换到新的API，一切都会好起来的。 这不是一件容易的事，但对每个人都有好处。 现在对于那些带有“硬编码”内容的人来说，现在是时候以一种更干净，更可靠的方式来重组事物了。 无论您身在何处，古腾堡（Gutenberg）的状况都不错。

我们是人类。 试着站在等式的另一端，成为构建这个事物并接收所有这些反馈的人。 IT可以感觉到接近“人身攻击”，大脑倾向于通过不屑一顾做出反应，而我们不应该这样做。

有很多人在古腾堡努力工作。 有些人的生计（他们的主题和插件）将受到古腾堡的影响。 有些人会使用受古腾堡（Gutenberg）影响的主题和插件来做自己的工作。 我们都在互相寻找对方，并希望在一天结束时能为WordPress提供最好的服务。 尽管我们可能在“最佳”的含义上存在激烈的分歧。

与您在这里和那里读到的内容不同，重点始终是重新设计整个页面。在第二个或第三个每周的Gutenberg会议中显示了Gutenberg编辑器页面的第一个模型...

单独的模型并不能表示整个编辑页面的代码库都将在React中重写。 没有人知道在看一个样机时会删除关键的钩子或破坏元框。 但是，当我发现整页收购将对meta box造成问题时，我在6月15日（ 0.1.0被标记为释放）的前一天表达了担忧。 四个月又15个版本发布之后，这是我们第一次真正看到在iframe中界面中出现元框。

自从古腾堡（Gutenberg）进入预测试阶段以来，我一直在密切关注和测试其经验，因此我创建了此问题。 这只是与正在进行的meta box挑战有关的最新问题，但重要的是，它是第一个基于对Gutenberg的meta box实现进行具体测试的问题。

主要区别在于“元框”没有“目的”，这只是扩展编辑器页面而不保持一致性的一种方式，而“简码”和“ TinyMCE”按钮只有一个。

这再次标志着对插件和主题开发人员如何使用元框的根本误解。 我们希望短代码和TinyMCE按钮需要进行修改，因为它们实际上是在内容编辑器中使用的。 元框不是。

暗示元框（即自定义WordPress开发的基础构建块）没有任何目的再告诉社区，古腾堡（Jutenberg）优先考虑“全新安装”的核心体验，而以插件和主题开发人员为代价。

对编辑器屏幕的任何更新。 任何TinyMCE更新，任何类更改，任何新的div，任何按钮的移除/移动，任何更改都破坏了与插件的兼容性，因为作为WordPress核心开发人员，您不知道哪些插件在使用Metaboxes。

我们可能不知道中继盒的用途，但是我们知道注册中继盒的基本要求及其使用的钩子。 我们知道，它们都不是为在iframe中工作而开发的。 多年以来，我们一直了解如何扩展和增强WordPress而又不破坏它们。 同样，如果5.0只是另一个WordPress版本，那么破损的数量应该与任何其他版本没有什么不同。

我们在iframe中展示了具有其缺点（链接，模式，重载资产）的元框，但同时它允许80％的插件在享受整个古腾堡体验的同时工作。

如果您有关于不断被引用的80％/ 90％数字的任何证据，请分享。 否则，当要求社区做出如此大的决定时，请不要使用假设的统计数据。

请立即停止并重新评估

经过所有讨论之后，我认为证明iframe并不是可行的长期解决方案，我遇到了https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059，它似乎增加了第三个iframe到古登堡。

现在是时候停止寻求理想的编辑器了，好像没有限制一样，并开始考虑一种不会破坏WordPress的方法。

从第一天起，就一直在关注和讨论Gutenberg编辑器的开发人员的讲话中，我很遗憾地说Riad的论点有很大的漏洞。

首先，从第一天开始，人们就一直在谈论metabox的问题，以及尚待解决的其他一些问题。 在样机阶段，我们被告知“一切都是视觉上最好的情况，稍后我们将介绍元框”。 然后，在原型阶段是“这是所有概念证明代码，稍后将处理元框”。 然后，当功能插件的第一个迭代发布时（这令所有人感到意外，这不是从头开始重写所有内容，而只是重新包装了当前的概念证明代码），该论点突然变成了“像metaboxs这样的旧界面现在将获得一些支持”。 然后，当公众的强烈抗议变得震耳欲聋时，那是“我们误会，元框不是遗留的”。 但是现在，这种说法只是再次推动了“遗产”议程。

元框不是遗留代码，因为当前没有可行的替代方法。

在metabox中，我可以使用wp_editor轻松添加功能齐全的嵌套编辑器。 Gutenberg当前没有用于嵌套块的UI，并且不打算在5.0版本中发布，因此，如果没有大量的自定义UI代码，它就不能做到等效。

那只是一个例子，但是在古腾堡超越平价之前，降低元框的体验是不可接受的解决方案。 WP 5.0不会发生这种情况

这是实际可行的古腾堡“统一管理”计划的路线图：

• 将初始版本限制为wp_editor当前填充的区域，但在该空间内提供完整的Block UI
• 通过发布一个字段api来提高和扩展块ui允许的灵活性和功能，该API使在该空间中进行设计变得微不足道
• 随着受欢迎程度的提高，请用类似的沙盒式古腾堡实例替换用户界面的其他部分。 菜单，小部件，定制程序和媒体库都是相对于开发人员而言相对停滞的界面，并且可以受益于通用的UI结构。
• 随着通用UI变得更加灵活和强大，人们将选择在元框上使用它，因为它提供了一组通用的工具和更多选项
• 随着这些空间的发展停滞，逐渐将孤立的古腾堡实例之间的孔合并。

这样，开发人员可以开始在生产工具上使用Gutenberg，而不会失去现有功能。 古腾堡将受益于为这些开发人员开发的所有边缘用例，从而创建一种灵活的解决方案，从而真正满足当前使用元框的用户的需求。

到不推荐使用元框时，插件作者将有足够的时间在野外学习和使用Gutenberg的好处，这将是显而易见的选择。

古腾堡就像一辆概念车。 立即缩小，并将迭代的改进交付给编辑器（而不是编辑器页面）。 然后，在接下来的一两年中，您可以将项目推向100％的管理员覆盖率。

我只想从客户服务提供商的角度跳进来，该客户服务提供商引用了WordPress对向后兼容性的明确承诺，以减轻客户对破坏其网站的更新的担忧。 因此，我认识到我对WordPress的使用可能会使我对编辑屏幕的看法偏向/偏见。

迄今为止，自定义帖子类型变得易于广泛使用以来，当在我的世界中，元数据框已成为WordPress的主要卖点时，感觉这个问题已被删除/淡化/淡化了。 我很高兴这次讨论正在进行。

古腾堡（Gutenberg）是一个令人印象深刻的项目，是的，但是我所工作的客户对他们所提供的基于meta box的解决方案感到非常满意。 可以选择禁用Gutenberg很好，但是我担心它会通过插件退出。 尽管我尽了最大的努力来指导客户，但我不认为他们会愿意自己安装一个新插件，即使升级欢迎屏幕上公然显示了Gutenberg，他们也不知道它是什么。

我在客户端站点上使用的meta box插件有可能（也许甚至有可能）更新为“与Gutenberg兼容”，但是即使那样，整个工作流程将在一夜之间改变那些客户端。 自从他们的站点交付很久以来，这似乎在问很多这样的客户，他们的现有工作流程对他们而言是否很好。

我完全支持古腾堡（Gutenberg）改善用户体验的目标，但我认为我们无法避免使用元框进行内容编辑的先例（有意或无意）。 我认为Yoast的方法很棒，它为许多潜在的解决方案打了勾号。

只是我的两分钱，期待在这里观察结果。

在我们的测试中，与Gutenberg一起使用的插件数量可能是80％，90％或0％，应避免的是成千上万的站点所有者必须自己找出其配置是否可能起作用或不起作用与古腾堡。 那将是巨大的时间浪费（金钱），会引起很多混乱并失去很多信任。

我希望看到标记为与古腾堡兼容（或“不相关”）的兼容/不兼容的插件/主题，以便站点所有者可以在该问题在其站点上变得活跃之前被告知潜在的问题，并可以采取相应的行动。 数据不仅可能来自插件所有者，还可能来自Beta测试期间的社区测试（真正的beta ...，而且时间跨度应该很长，而不是几周。）甚至更远。

我知道这永远不会是完整的或100％准确的，但是对于最杰出的插件应该是可行的。

PS。
对于我自己的项目（一个为拥有30.000多名员工的客户提供的Intranet微网站平台，以及一堆小型企业/非营利性网站），我们决定禁用Gutenberg，直到成功至少成功使用了一年。

百分比仍然无法说明全部情况。 关于Gutenberg影响的任何讨论都需要考虑其metabox实施影响了多少个网站，而不是影响了多少个插件。 Gutenberg仅会影响少数几个插件，并且仍然会影响数百万个用户，因为一些使用最广泛的插件依赖于metabox和自定义字段-ACF和Yoast SEO是两个明显的例子。

我已经从远处追踪了古腾堡（Gutenberg）的发展，已经有很多月了，我知道元盒的问题已经存在了很长时间。 我支持古腾堡（Gutenberg）背后的理念，并且我认为古腾堡（Gutenberg）最终将成为WordPress核心的一个非常强大的部分，这将使WordPress在未来很多年成为可行且具有竞争力的软件。 我非常关注Gutenberg的整个概念及其目标。

我不明白的是，希望一次过从0变到100。 为什么在这里不采取迭代发布方式？ 为什么这两个选项“不中断”或“不中断”？

Metabox是WordPress如此强大的原因。 其目的是扩展编辑屏幕。

我认为古腾堡（Gutenberg）希望对整个屏幕进行大修非常好，但我只是认为一次性做到这一点并不现实，特别是如果这意味着要处理WordPress最重要的组件之一（就定制开发而言）。一方面，它是WordPress成功的重要组成部分）。

2-古腾堡（Gutenberg）仅替换内容区域：90％的插件正常工作，用户体验受到影响

UX不受影响。 随着编辑器部分的改进，用户将看到它。 这将为他们提供一种创建内容的新方法-他们中的大多数人在调整之后都会获得授权，并且这种方法不会破坏他们现有的任何工作流程，也不会使他们想知道如何完成以前完成的工作编辑。

4-古腾堡与兼容的插件：最好的用户体验

这是一个出色的目标，但这是长期目标。 最终，是的，绝对如此，应该是Gutenberg，其插件可以与Guteneberg体验一起使用或在其内部使用。

我们的目标也是以某种方式构建古腾堡，以便在需要时可以重用其部件来实现第二和第三选择。

我不太确定这是什么意思。 您是否要假设所有插件都可以使用它来构建Gutenberg，并使用该解决方案跳回到选项2和3？ 首先建立到2，然后迭代到3，这不是要使我们达到4的原因吗？

我喜欢@gschoppe提出的路线图，作为构建自定义WordPress网站的开发人员，这是我可以落后的一种方法，不会对开发人员或他们的客户或普通WordPress用户产生负面影响，并且仍然可以使我们走到最后古腾堡（Gutenberg）的目标-尽管步伐更容易吞下。

除了Kevin对iframe的关注之外，我还要指出一些可访问性方面的关注。 首先，虽然视觉体验网站的用户会与整个页面的其余部分一起体验框架集和iframe的凝聚力，但屏幕阅读器用户却不会。 屏幕阅读器用户可以体验框架集中的每个框架，并且每个iframe与页面的其余部分是一个独立的部分，因为网页是以线性方式进行体验的。 一些屏幕阅读器（尤其是Jaws for Windows，根据WEBAIM的年度屏幕阅读器使用情况调查显示，这是市场份额最大的屏幕阅读器）具有忽略帧（包括嵌入式框架）的配置设置，因为它们可能会对某些屏幕造成伤害读者用户。 调用忽略框架设置时，框架和iframe中的内容会消失。 即使涉及到iframe的古腾堡（Gutenberg）遵循了所有可访问性最佳实践，为使用户能够完全编辑内容而要求用户禁用此设置，也会使他们暴露于iframe的每个实例以及网络上最糟糕的实践。 这些用户的唯一其他选择是要求他们创建一个单独的配置文件以仅使用Gutenberg，这不是一个简单的过程，因为这意味着他们需要重新配置每个浏览器设置和语音设置。 这也意味着他们需要至少跟上两个单独的浏览器配置文件。 由于某些原因，我将是第一个告诉Jaws Windows用户全职迁移到NVDA的人。 古腾堡使用iframe来支持metabox并不是这些原因之一。

..作为一个简单的开发人员，我花了整整一年时间思考整个WordPress（核心和社区）的最佳可行方式，我的耐心已接近极限。

我发誓我不喜欢粗鲁，但在这种情况下，您可能需要变厚皮肤。 面对“整整一年”的思考，您会感到沮丧，并感谢您这样做，但是这些决定将影响他人所做的多年工作。

就我而言，从我阅读的内容来看，过去三年中我建立的几乎每个网站都可能会立即崩溃。 我不再负责这些站点，但是当几十个客户一次打电话给损坏的站点时，我曾经工作的代理机构将发生什么。 这对小机构，他们的日常工作和底线有何影响？ 这将如何影响他们的客户？ 这些是我的关注点，在这个相对较大的生态系统中，我只是一个（象征性的）开发人员。

我承认有时我们（至少我）会在我的评论中不屑一顾，对此我深表歉意。

人们感到担心并感到沮丧，在我看来，他们有这样做的一切权利，因为人们认为，从事古腾堡研究的团队几乎不了解元数据框的使用方式，也很少担心会产生什么影响，并且无论如何都将继续他们的愿景。

这让我伤心写这一点，但我不会在一万年建议任何人现在就开始用WordPress的一个重大项目。

2-古腾堡（Gutenberg）仅替换内容区域：90％的插件正常工作，用户体验受到影响

@youknowriad ，您如何说古腾堡和TinyMCE不会让UX受苦？ 我是在问这个问题，不是在偷偷摸摸。 我可以告诉你，与TinyMCE和meta box相比，Gutenberg的UX确实遭受了很大的损失。 我鼓励您通过以下方式自己找到答案：

（1）拔下鼠标。
（2）如果您使用Mack，请按Command + F5，然后尝试使用VoiceOver完成任何有效的工作。
（3）如果您使用的是PC，请下载NVDA，进行安装，拔下鼠标，然后执行相同的测试。 在这种情况下，尝试与古腾堡做一些富有成效的事情。

我认为您会发现UX绝对是噩梦。 这并不是说它不可能变得更好。 古腾堡（Gutenberg）为WordPress提供了一个清除可访问性方面的技术难题的机会，如果谨慎而正确地完成这项工作，那么可以取得一些巨大的成就。 但是，如果这样做有误或粗心大意，WordPress可访问性团队和其他核心贡献者自2012年以来所做的许多工作将需要重新开始。 我想将WordPress作为一个项目，不会像开始时一样犯同样的错误：从一开始就不考虑Web可访问性，这意味着可访问性团队和其他有关贡献者在发现事实之后就开始对可访问性产生兴趣，这是一项任务由于WordPress并非停滞不前的代码库，因此永远无法实现。

我知道你们已经在古腾堡工作了一年。 我还知道，对此进行工作本身并不容易，并且负面反馈对这种情况没有帮助。 最后，我明白了，像我们这样批判的人似乎在丑陋地称呼您的孩子，或者只是对改变的恐惧做出反应，作为一个创造者，充其量是令人沮丧的，最坏的是伤害。 但为我自己说话，婴儿并不丑陋。 成为街区上最酷的孩子，或者使每个人的生活变得痛苦的小混蛋，都有很大的潜在潜力。 我希望看到它是前者而不是后者。 特别是对于元框，它们是WordPress定制开发的字面意思，可能更是如此，简码或TinyMCE按钮。 在我们弄清楚如何摆脱它们之前，不应该轻轻地擦掉它们或将其推入iframe中。

我关于WordPress的简单故事是，十多年来，它一直是我为个人，小型企业和企业客户创建网站的首选网站引擎。 那时，有三件事使WordPress成为首选工具：

1. 开源。 我认为这个听众可以同意这是多么强大和有利。
2. 使用方便。 WordPress使非开发人员可以轻松地创建和更新内容。 在我为个人和企业创建网站的初期，这是巨大的。
3. 定义内容。 自定义帖子类型，自定义分类法和自定义元框。 当导致这些问题的一切都变得单一时，我不认为我说这是WordPress可“出售”给商业社区而不仅仅是博客软件的时候。 （WordCamp Phoenix 2012-CMB。贾斯汀·塔德洛克（Justin Tadlock）关于定义帖子类型，分类法和元框的出色著作。）

我要说的是自定义元框-这种创建自定义管理界面，为人们创造良好用户体验的能力非常强大。 打破这一点，你就打破了WordPress 。

古腾堡（Gutenberg）背后的想法，使内容编辑器体验更加强大，是一个好主意。 这是值得做的，但必须做得正确，谨慎，不要仓促。 现在，感觉很匆忙，还差得远。

@jchristopher说得很好：

我完全支持古腾堡（Gutenberg）改善用户体验的目标，但我认为我们无法避免使用元框进行内容编辑的先例（有意或无意）。 我认为Yoast的方法很棒，它为许多潜在的解决方案打了勾号。

@jnicol和@aurooba提出了很好的观点并提出了很好的问题。 为什么它看起来是全部还是什么，而不是更多的迭代路线图？ Yoast的替代方案比已见的更为明智，我认为“ iframe实验”证明了这一点。 谢谢@amandarush指出可访问性问题。 我挑战所有人，以她概述的方式尝试与Gutenberg合作。 它可能会改变一些观点。

@aaronjorbin之前说过，当有人采用WordPress时，他们没有采用WordPress（此处为版本号），而是整体采用了WordPress。

还有另一个版本，客户端服务中的任何人都可能经常听到。 当有人到您那里说他们需要一个新网站（我们不是在谈论博客）时，他们通常不会说“我需要一个新的Wordpress网站”或“我想要一个新的Drupal网站”等。他们只想要一个新网站，这个网站可以正常运行。

WordPress已成为数百万个网站的最佳解决方案：易用性和开源是关键。 急于实施新的编辑器界面会破坏自定义元框（忘记插件号，所有具有自定义admin UI的现有网站如何？）会损害易用性。

作为一个简单的开发人员，我花了整整一年的时间思考WordPress整体（核心和社区）的最佳可行方式，我的耐心已接近极限。

我要直言不讳，在这里：

这和其他类似的评论使我认为，你们中的一些人应该远离该项目的决策角色。 坦率地说，如果您不能对产品提出诚实，经过深思熟虑但重要的反馈，那么您不应在产品团队中担任决策角色。 我去过您的鞋子多次，通常是面对面开会，并且在成功的案例中，会议室中的每个人都意识到，无论辩论如何激烈，这都是关于为客户提供最好的产品。 对产品的想法和方向提出批评是成为产品团队决策者的一部分，并且应该导致产品更好，因为没人会想到做任何事情的最佳方法。 团队也是如此。

我毫不怀疑，核心团队中的每个人都希望发布一个很棒的WordPress版本，但是您不可避免地要接近一个项目； 您知道发生了什么辩论，考虑，拒绝等等，并且很难从外部角度审视和观察事物。 但是，您不是WP社区的全部成员。 你不能。 您所听到的是有关产品方向的正当担忧。 如果您无法接受，请考虑一下您所说的话以及为什么这样说，请远离决策古腾堡方向的决定。

另一种选择（这将使FAR更好），请接受这些想法。 真正考虑人们在说什么。 了解作为经营使用WordPress的企业的人的担忧，并了解我们不仅关心我们自己，也关心我们的客户。

自2008年初以来，我一直在使用WP，但我想不出一个新功能或新决定在任何时候都像以当前形式引入古腾堡一样造成了很大的分歧。

尽管WordPress是针对用户的，但它只是一个工具，如果没有WP专业人员来帮助他们实现目标，则用户将根本无法使用该工具。

我看到有人希望满足全新安装的用户的需求（每年增加约1％的网络吗？），但这似乎是以现有用户群（约28％）为代价的，其中大多数可能正在运行具有至少一个元框的插件。 无论从哪个角度看，这似乎都是糟糕的商业意识。

我得到了意识形态：创建一个最佳情况的编辑器，然后使用适配器模式使旧的与新的交谈。 麻烦在于，PHP和JS是不同的技术，并且由于前面提到的所有原因，将这一问题传递到HTML iframe领域并不可行。

这是第一次通过，这是一个实验，但是这项努力没有成功。 确认得越快，我们就可以越快地提出下一个建议。

但是，对于满足各方需求的元框而言，没有人能找到合适的解决方案。

这意味着一方需要让步-不管是10-50名支持古腾堡的开发人员，还是成千上万的被吓到的开发人员，或者变更将对他们产生的影响，更不用说他们的用户了。

一旦所有变通办法的建议都用尽了，那么也许会有一个让步，即覆盖所有页面对于所有各方都不可行。 至少不在当前尝试的单次点击中。

回到最初的问题-iframe是meta盒的长期解决方案吗？ 多个开发人员（让我们不要忘记，他们也是用户）已经解释了为什么答案是否定的。

我们在这里进行了富有建设性的讨论。 记得：

我们批评想法，代码和像素，而不是背后的人类。 对于最佳的前进道路，我们可能有不同的看法，但我们不质疑证书。 当我们与个人打交道时，就是要提拔他们，并为他们的出色工作给予称赞。 世界上发生了这么多事情，我们必须互相注意。 这是一个巨大的挑战，但我们会团结一致的。

让我提醒大家，古腾堡（Gutenberg）中的元框是@ BE-Webdesign提升并完成此操作的结果，它与其他人无关，几乎没有帮助，却无处不在。 如果不是@ BE-Webdesign，那么古腾堡（Gutenberg）中就不会有任何metabox。 在这里留下的47条评论中，也许只有2个人实际触摸了metabox代码以进行审核和UX。

但是，这里的根本问题是，如何在不构建不安全代码的情况下以头等公民身份安全地将metabox放置到页面上，从而导致权宜之计或获取麻烦。

• 第一次迭代涉及一个陷阱，使WP假装它在edit.php页面上，并以此方式生成元框。 最初的报告表明它存在兼容性问题，而且超级hacky，不是可行的解决方案。 这是因为许多插件仅在满足特定情况时才注册元框，并且不信任WP知道何时渲染它们
• 合并后的第二次迭代使用了iframe，因此，尽管删除了元框，但所有内容都显示在经典编辑器中。 这有点麻烦，但尽管有问题，但它使metabox正常工作
• 还有一种解决方案，我们先获取HTML代码，然后将其批发插入组件中，尽管这是非常明显的解决方案，但这将是安全灾难。 因此，为什么还没有这样做呢。

我的建议是：

与其在设置页面上加载古腾堡，不如将其加载到主要的经典编辑器页面上，在其本机环境中加载元框，然后通过JS将其容器DOM节点提升到一个组件中

然后，我们使用另一种切换方式来确保仍可以使用经典编辑器。 这条路：

• 我们避免使用iframe废话
• 就注册而言，元框始终如一
• 现有的JS可以按预期工作，并且无需黑客就可以使事情在PHP端正常工作

而且，酵母菌的设计很漂亮，但是块元数据又去了哪里呢？

不幸的是，我对将实际代码贡献给Gutenberg所需的js经验很少。 我只是开始全神贯注于开发WordPress的世界，而不是在此之上发展。 因此，我能做的最好的事情就是提供反馈，测试编辑器（我在个人博客上积极使用Gutenberg）并提供建议/想法。 如果我能提供代码，我绝对会的。 如果有其他方法可以帮助您，我很想知道。 因为我很在乎这个。 :)

贡献有多种形式。 尽管为开发此尝试付出了时间和精力，但防止未来沉没成本的测试和讨论也同样有价值。 例如，存在许多与iframe实施相关的新开放问题。 我们可以花更多的时间来尝试解决这些问题，或者我们可以使用此线程中的测试和原理来确定需要另一个方向。 我希望这是我们作为一个团体达成的认识。

让我提醒大家，古腾堡（Gutenberg）中的元框是@ BE-Webdesign提升并完成此操作的结果，它与其他人无关，几乎没有帮助，却无处不在。 如果不是@ BE-Webdesign，那么古腾堡（Gutenberg）中就不会有任何metabox。

尽管赞美和崇拜是美好的😄，但我绝对有帮助，这在很大程度上是许多人的团队努力。

我的建议是：

与其在设置页面上加载古腾堡，不如将其加载到主要的经典编辑器页面中，在其本机环境中加载> metabox，然后通过JS将其容器DOM节点提升到一个组件中

是的，这很可能是下一次迭代，我认为这是一个很好的建议，也是一个建设性的想法。 尚不能100％地确定如何干净地执行此操作，但是完全可以不使用iframe，并且具有古腾堡已经提供的改进的用户体验。 将会有一些更新来改善元框的体验，这可能涉及消除iframe。 iframe方法已成为了解如何实现元框支持的一种方法，现在将进行更好的改进。 几个月前，当第一次使用meta框探索事物时（不是一个新话题），由于当时的Gutenberg的状态，现在应该将iframe方法向前推进，因为现在它已被合并，并且其他许多部分都已移动从技术的角度来看，可能不再需要使用iframe。 还需要做更多的工作。

@ BE-Webdesign感谢您的努力和在这里的输入。 让我们结束这一点，并在准备讨论该方法时开始一个新的问题。

请立即停止并重新评估

并非每个人都习惯这种方法进行项目设计，但这是一个每天对几乎所有事物进行连续重新评估的项目。 将原始模型与当前编辑器进行比较。 事情会改变的。 大多数作品不是一成不变的。 真正评估某项工作是否可行的唯一方法是实际进行工作。 并非每个人都以相同的方式来进行产品设计，但是我认为古腾堡的快速迭代一直很好地服务于它，而不是试图提前哈希未知数。

感谢大家的讨论。 我很高兴这次对话最终重新讨论了该主题的问题：_ iframe中元框的当前方法是否可行_？ 答案是否定的。 iframe是一个实现细节，我认为我们可以相对轻松地实现。 因此，让我们集中精力。

作为总结，我想补充一点，不更改编辑屏幕是我们最简单的方法。 这对于项目的目标和WordPress的长期用户来说也不公平。 有人称其为务实的方法与该项目从一开始就朝着全站点定制迈进的设计方向不符，而到目前为止，决定了我们的决定的是什么。 这里没有什么是最终解决方案，我们正在探索设计场所中的可能并将其用于测试。 这不是我们一个人就能建立的，我们真诚地欢迎大家提供的所有帮助，因为有许多难题需要克服。

WordPress总是与用户同在，我们承担了开发路径的负担，以简化现有代码的过渡。 作为一个项目，我们之前曾说过，我们不会放弃对WordPress的元框的支持，而且还必须探索在新范式中必须做出哪些接口决定，包括在加载新版本时加载经典编辑器的可能性。我们检测到我们无法处理的元框，或者与试图更清楚地描述内容和元数据的编辑器直接冲突的元盒。 现在有些人可以从默认的古腾堡体验中受益。 作为开发人员，我们有幸能够制造解决方案，但有责任不遗漏我们必须进行的更改，以允许那些本来会很挣扎的人们在开放的Web上露面。

@mtias我真的很感谢您的明智评论，尤其是有关“ WordPress总是与用户同在”的部分。

不幸的是，这与@youknowriad在该线程中进行的通信完全不符，并且由于你们俩都在Automattic工作，我敦促您与他谈谈产品方向，因为现在我们收到的信号不一。

不幸的是，您没有解决建议的Yoast草图，该草图可以为我们提供古腾堡（Gutenberg）的所有灵活性，同时与现有的元框兼容。 为什么有人不能承认您为什么不考虑这种方法？

不幸的是，这与@youknowriad在该线程中进行的通信完全不符

我想您只是误解了我的意思，我只是在列举事实，我分享@mtias的想法100％

@mtias

有人称实用主义的方法与该项目从一开始就具有的设计方向不符，即朝着全站点定制方向发展

我真的不同意这种观点。 进行仅限于编辑器本身的迭代增强功能，但具有替换元框以及释放和提升字段API的功能，将是通过简单易用将插件数量转变为块范例的一种平滑方法。 ，与我们现在的破碎景观相比。

通过顺利进行这种中间过渡，您将可以更轻松地在post_edit屏幕上弃用直接DOM生成/操作，因为到那时，标准的实际解决方案将不再涉及这种操作。 我不相信有人会说“直接DOM操作永远需要成为主要经验”。 他们说“这是目前的主要解决方案”。

如果您可以通过全屏解决方案保持dom操作的完全灵活性，那就去做吧……但这似乎是一个非常崇高的目标，我怀疑经典编辑屏幕中的任何形式的吊装实际上都能够交付在任何合理的兼容性水平上。 也许我是错的，但是当迭代的方法可以完成相同的工作时，尝试转换用户似乎是一个极其复杂的黑客。

通过保留当前范例的首要地位，同时发布新范例，您可以在不损害任何人当前经验的情况下鼓励采用。 然后，一旦大多数工作流程过渡到块范式，就可以弃用直接dom控制，而采用全屏解决方案。

这并不是在背叛项目的目标，只是解决发布时间表，以使成千上万的代理商和开发人员更容易管理更改。

@youknowriad让我发布一些您所写内容的摘要，以支持我在说的话：

通过利用REST API，客户端UI并统一核心概念：小部件，短代码，块，内容元框（在唯一的概念“块”下）

没有人要求将“内容元框”转换为块，直到古腾堡发布其初始版本后才进行通信。 实际上，这就是论点的核心所在。 我不会再重复别人所说的更好的内容，只是metabox通常不是页面内容。

与您在这里和那里读到的内容不同，重点始终放在重新设计整个页面上。在第二个或第三个每周的Gutenberg会议中显示了Gutenberg编辑器页面的第一个模型。 我们仍处于原型开发阶段。

古腾堡（Gutenberg）团队一直说草图只是为了展示，而不是最终设计。 此外，草图无法显示整个编辑屏幕是否已转换为React或只是样式不同。 整个页面都将被重新设计的事实使与我交谈过的每个人大为惊讶。

简码，TinyMCE按钮和元框之间有什么区别？
主要区别在于“元框”没有“目的”，这只是扩展编辑器页面而不保持一致性的一种方式，而“简码”和“ TinyMCE”按钮只有一个。

这是一个巨大的误解，应该引起Automattic的关注。 （我希望@mtias和@m在听）。 这根本不是真的，我对这句话之后的判断真的提出了质疑。

我们能否得出结论，就WordPress的长期而言，Metaboxs会锁定其发展（不管古腾堡如何）？
对，他们是。

我想说的是，在这里几乎没有人同意您的看法，我认为Automattic需要将其付诸表决，以确定产品方向。

我也质疑@mtias说诸如人们需要贡献之类的事情。 显然，与Automattic相关的古腾堡团队并没有动弹，正在转移所有批评。

我几乎不相信，如果我要进行PR来减少Gutenberg只是编辑部分，由于Automattic内一些人的陈述，Gutenberg团队将考虑使用它。

@mtias ，

作为总结，我想补充一点，不更改编辑屏幕是我们最简单的方法。 这对于项目的目标和WordPress的长期用户来说也不公平。

一次执行任何步骤都不会损害项目的目标。 如果这是您的目标，您仍然可以进行全尺寸定制，但是通过分步进行，可以将其余的开发人员社区带到您身边。

定制程序就是一个很好的例子。 是的，它有其批评者，但最终概念将随着时间的流逝而实现，它是允许某些用户组有效地利用WP作为管理其站点的工具的功能。

现在有些人可以从默认的古腾堡体验中受益。

绝对。 但是现在还有更多的人会对默认的古腾堡产生不利的经历。

我希望我们所有人都能继续前进，并在我们的回应中将人们与产品区分开。 激情是伟大的，但重要的是，我们要考虑这样的人与之互动。 参与该项目的每个人都在乎，如果他们不这样做，他们就不会进入这些线程并进行交互。 现在，让我们喘口气，所有人都记得我们都在乎WordPress多少，并希望我们的评论的核心内容可以使该社区安全，对每个人都有效。

@khromov作为该项目的设计负责人，就像Matias是技术负责人一样，我100％落后于@youknowriad。 我了解您充满激情，但您没有受到尊重。 请召集一个人来调整您采用的方法。 让我们停止个人化。

同样重要的是，还要记住许多在古腾堡工作的人以前是WordPress社区的成员，以前（仍然）是核心贡献者。 是的，包括我自己。 我会在这里说超级个性，一旦您进行公关，请通知我，我将检查并确保所有评论都具有相同的尊重，无论它们来自何处。 拜托，让我们继续将这个项目视为“我们与他们”。 并非如此，我们这里有一些惊人的非Automattic贡献者，该声明对他们不利。

@khromov

通常，我被视为削弱古腾堡（Gutenberg）的理由，因为我的帖子和评论强调了我在方法和实施方面遇到的问题，但是我觉得古腾堡的目标和进步有时会在评论中被误解，这是由于沟通不畅或缺乏理解项目的总体目标。

块不是表示和编辑帖子内容的视觉方式，它们也不必成为内容选择器菜单或可拖放的一部分。 当然，它们可以用于那些事情，这就是古腾堡许多可见部分所强调的工作流程。 但是，暂时忽略您对该范例所了解的内容，而以这种方式查看它：

块是站点的基本控制结构，而与接口或存储无关。

• 小部件将成为块。 这并不意味着它们将存在于编辑器中并保存在post_content中。 这只是意味着它们将由一个内置有JavaScript框架且具有单个通用API的系统控制。
• 该定制器将被替换为块。 该接口可能会（大致）保持不变，但是Customizer的各个部分将由相同的API控制。
• 插件页面，主题编辑器，仪表板本身都计划最终成为块。 如果这些部分的想法完全按原样无法想象是使用通用API重新创建的，那么用WordPress的话来说，您可能对块是什么有一些误解。

问题不在于不能在块范式内部重新创建元框，实际上，非前端块以编程方式添加到帖子类型中，锁定在适当位置并存储到后元而不是post_content中WordPress 5.0版本（如果我输入错误，请纠正我）。

从本质上讲，它涵盖了诸如文本框和选择之类的琐碎元字段的所有需求。 如果需要，您可以完全按块复制该接口，也可以根据新的可视化语言来简化某些接口，这完全是您的要求。

问题不是metabox永远不可能是块。 问题是，现在，有一些在元框中创建的界面，尚未在块中支持（WordPress或第三方），并且重新实现该工作对开发人员而言是一项艰巨的任务，尤其是因为这些工具尚未构建可以从常见的API（例如建议的Fields API）中获取数据，而是以直接修改页面DOM并以即席非托管方式使资源入队的大杂烩的方式进行。

这种当前状态也给开发人员带来了问题。 例如，如果您将Visual Composer和Piklist一起用于字段，则Piklist将覆盖许多管理样式，从而使VC很难导航。

或者，如果您将WooCommerce与任何使Select2 Library的新版本入队的插件一起使用，则一个或另一个将破坏您的管理界面，并出现严重的JS错误。

如果两个不同的插件依赖于CMB2框架的不同版本，则可能发生同一件事。

区块旨在通过围绕各种页面添加一个通用框架来解决这些问题。 该框架中的某些框架将重点放在为编辑器提供wiz-bang拖放式可视化内容上，但是实际上并没有约束力。 只是确保以通用方式管理出现在admin中的内容。

现在，有一些有效的论据表明WordPress已经以Wild West开发者的态度发展起来了，这种通用框架为不知道如何反应的开发人员增加了进入门槛。 并且有有效的论据认为，在发布之前，Block接口不会达到广泛采用开发的程度。 甚至有有效的论据表明，当前的块API有点天真，并且没有考虑许多常见的工作流程，因此在创建和记录这些功能之前，无法适配插件。

但是，认为Metabox完全免费是终极解决方案，必须永久保存，这对于任何人来说都不是一条很好的前进之路。 为了使WordPress能够为所有用户（包括开发人员）提供更好的选择，需要存在某种通用系统。

如果该系统是几年前的通用Fields API，那就太好了，因此所有这些更改将大多只是该API呈现步骤的替代，但就目前而言，需要找到一条前进的道路。

综上所述，我仍然强烈支持Yoast提出的临时解决方案，因为它是最终实现通用UI的最佳现实方法。 我当然很批评，但是我想确保我们批评事实，而不是误会。

不幸的是，这与@youknowriad在该线程中进行的通信完全不符，并且由于你们俩都在Automattic工作，我敦促您与他谈谈产品方向，因为现在我们收到的信号不一。

我想说的是，在这里几乎没有人同意您的看法，我认为Automattic需要将其付诸表决，以确定产品方向。

显然，与Automattic相关的古腾堡团队并没有动弹，正在转移所有批评。

我几乎不相信，如果我要进行PR来减少Gutenberg只是编辑部分，由于Automattic内一些人的陈述，Gutenberg团队将考虑使用它。

我只想说明一下显而易见的内容，但Gutenberg是WordPress社区项目，而不是Automattic产品。 我本人可能是Automattician的人，但是我在这个项目上的权限没有比其他任何人更高，无论他们是自由职业者，代理公司首席执行官还是履行公司5％承诺的专职开发人员，都不像某些人建议的那样。 同样，WordPress本身是社区项目，而不是Automattic项目。

Automattic不会“发布”或“构建” WordPress，而Gutenberg不是Automattic产品

此外，在这种对话变得更加激动人心，人们看不见树木的森林之前，我想花时间体会一下分配给古腾堡团队的任务的难度以及他们的处理水平一般来说。 他们的任务是创建一个范式，该范式将成为WordPress整个管理员经验的基础，并且只能在界面的一个小角落内显示它们的有效性。

由“编辑正在接管”这一想法引起的误解之多是巨大的，并且必须非常难以处理。 他们的职责是为WordPress管理员创建通用的构建基块，并通过重建编辑器对其进行测试。 尽管我相信如果公众只是重建wp_editor()接口并从那里扩展，此任务对公众来说将是更加可口和灵活的，但可以理解的是，为什么“编辑体验”的所有相关部分都构成了对提议的新范例进行更完整的试用。

我理解，也感谢为此付出的努力。 我仍然对做出的某些决定持批评态度，并相信有时间进行一些修改，这些修改将极大地改善最初的采用率，但是我完全同意最终为WordPress管理员体验提供更结构化框架的总体目标。 ，适用于开发人员和用户。

@karmatosed

我提到@youknowriad的原因是他是唯一参与讨论的人。 尽管开发人员方面已达成明确共识，但涉及数百名开发人员和数千小时的讨论并未取得任何进展。 我认为质疑由一小群开发人员制定的决策的合法性并不无礼，即使这涉及召集特定人员。

无论如何，我都与@youknowriad进行了私人聊天，他向我解释了即将到来的路线图，在我看来，该路线图听起来比向外传播更明智。

@tomjn

我谨不同意。 重要的决定是由Automatticians做出的，在与@youknowriad交谈之后，我了解到产品方向已经设定了很长的时间，因此，除了修正bug和一些较小的视觉效果外，我们的常规贡献者没有其他工作要做。调整。

@gschoppe我只是希望对这种“范式转换”进行公开讨论，并与开发人员社区合作进行。 也许这是目的，但在这种情况下，通信方面无法很好地工作。

为什么有人不能承认您为什么不考虑这种方法？

@khromov我们已经有了，在编辑器聊天的其他地方，等等。这个问题尤其与iframe实现有关。

我几乎不相信，如果我要进行PR来减少Gutenberg只是编辑部分，由于Automattic内一些人的陈述，Gutenberg团队将考虑使用它。

一点也不。 我们很早就自己考虑了这一点，认为它过于局限，不适合实现我们的愿景。 对于许多人来说，这仍然可能是一个合理的折衷方案，并且可能是一个不错的插件。 但是，实现此目标所需的工作将通过使Gutenberg更具可重用性来总体上改善Gutenberg，所以我不会反对从事此工作的人们。 如果有人从事这种PR，我可能建议在“写作”部分添加一个设置来切换行为，而不是将其设置为默认行为。

我们具有围绕嵌套块，全局块，声明块模板，列等的重要功能，这些功能真正受益于整个页面的内容，否则感觉会很差，从而限制了开发人员可以做什么以及用户可以体验到什么。 还有一些不错的工具，例如文档大纲，可在全屏编辑器中无缝实时地集成，而这仅是TinyMCE的替代品。

一次执行任何步骤都不会以任何方式损害项目的目标。

绝对！ 我们从Matt最初的新焦点文章中提出了一种分阶段的方法，它只是以不同的方式考虑了步骤。 古腾堡项目通常分为三个阶段：从帖子编辑器到页面模板，再到网站建设。 原始的是，范式是其中内容是单个区域，以_block_作为主要概念的范式，并且可以清晰直观地显示结果而无需过多的抽象。

绝对。 但是现在还有更多的人会对默认的古腾堡产生不利的经历。

当然，这就是为什么两个插件都可以随意返回到当前体验的原因，并且我们将提供处理不兼容问题的机制，从而允许选择加入更多内容（例如，如果您对元框感到满意）在古腾堡展示您可以宣布对此表示支持，反之亦然）。

@gschoppe我知道我们过去曾有很多分歧，但我感谢您在这里的评论，并愿意通过不同的观点参与。 您对块的凝集因子提出了一些意见。 也许有一天，我们将在一次WC会议上见面，并且我们可以就These修斯悖论进行一场有趣的哲学讨论。 谁知道。 😉

来自Automattic的您应该不要抱怨我们不能尊重您的工作，并且我们正在将您推向前进。
不为您获得7000-10.000€专业月的薪水。 愚蠢。 就像人们向开发人员志愿者抱怨WP Trac一样。
如果古腾堡让您头疼，请与老板交谈。 他给了你不可能完成的任务。

其次，您比大多数在这里发表评论的人都更好。 您为什么尝试通过“ iframe”解决方案？
我告诉过你，你像对待孩子一样对待人。 让我们尝试一下iframe，看看人们是否会尖叫得太多，情绪会更多。 如果噪音很大，我们就会远离iframe。

您为什么尝试通过“ iframe”解决方案？
我告诉过你，你像对待孩子一样对待人。 让我们尝试一下iframe，看看人们是否会尖叫得太多，情绪会更多。 如果噪音很大，我们就会远离iframe。

首次实现对meta box的支持时，新的编辑器存在于全新的管理页面上，而不是post.php，该编辑器的加载方式有所不同，并且总体上存在许多限制，这是使用iframe解决meta box问题的一部分，这些约束中不再存在的约束，因此，元框最有可能不再需要使用iframe。

该项目倾向于在单个发行版中跨发行版进行增量改进而不是完善。 没有人试图看看人们是否会尖叫。 现实情况是，尽管人们已经采用了iframe方法，但它对于大多数meta框仍然有效。 现在它将进一步改进，并且😱会越来越少。

@StaggerLeee无论在哪里工作，请尊重该项目中的每个人。 就像您希望某人对您很好一样，对其他人也是如此。

作为该项目的设计负责人，我不会看到您对任何人所说的个人陈述。 我不在乎有人在哪里工作或他们的背景如何，那是您无权要求的个人详细信息。 请放下个人资料，然后重新专注于产品。

现在，让我们继续前进，集中精力制造我们能做到的最好的产品。 我完全理解您的观点通常来自激情所在。 您可以尊重他人并充满激情，请回到原来的样子。

来自Automattic的您应该不要抱怨我们不能尊重您的工作，并且我们正在将您推向前进。
不为您获得7000-10.000€专业月的薪水。 愚蠢。 就像人们向开发人员志愿者抱怨WP Trac一样。
如果古腾堡让您头疼，请与老板交谈。 他给了你不可能完成的任务。

@StaggerLeee我希望我能得到这么多的提示hint，但Automattic不是Google，并且我可以在WP世界中的其他地方赚到更多。 我自己在这里的存在纯粹是靠我自己的力量，我在这里没有得到报酬，从事此工作的其他人也很少。 实际上，我有报酬进行代码审查并帮助启动企业客户！

因此，请相信已收到消息，证明位于顶部的“拉取请求”选项卡中，这不是Automattic的阴谋来破坏您的代码并欺骗您的客户（_别忘了，Automattic已向付费的客户也使用metaboxs）

对于仍受iframe困扰的人，我建议在此处查看此Pull请求（https://github.com/WordPress/gutenberg/pull/3345），该请求正试图撤消iframe并实施我之前提出的建议。

随着metabox实施的下一次迭代，测试和确定兼容性问题将是一件好事，向A8C投掷烂果可能会感觉很好，但这无济于事。