FWIW当我与Web开发人员交谈时，他们都使用metabox来显示内容，以便他们拥有最大的控制权。 我不确定对于很多人而言，元框是否会被视为“旧版”，而是未来的一部分。 可能值得与WordPress VIP人士取得联系。

我不确定对于很多人而言，元框是否会被视为“旧版”，而是未来的一部分。 可能值得与WordPress VIP人士取得联系。

抱歉，措辞不好。 元框将保留下来。 这就是为什么metabox侧栏以新的“ Post Settings”侧栏形式进行升级的原因。

我的意思是说，新的元框应使用JS编写，并将出现在库存设置旁边的“帖子设置”边栏中。 理想情况下，用PHP编写的元框应升级为JS，但也应继续以其PHP形式工作。 这就是“扩展设置”面板的用途，它位于底部，不是因为我们不希望它们成为侧边栏的一部分，而是在侧边栏中混合PHP和JS元框非常困难。

通过JS和Ajax提交由PHP管理的metabox时存在一些大挑战，特别是在如何处理metabox渲染以反映新保存的状态方面： https :

我想知道是否可以通过iframe嵌入旧版metabox是这里的解决方案，其中iframe src类似于/wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings并且仅将一个metabox输出到文档中。

我的意思是说，新的元框应使用JS编写，并将出现在库存设置旁边的“帖子设置”边栏中。

这是否意味着JavaScript元框只能进入侧边栏，而不能成为“扩展设置”部分的一部分？ 在我脑海中，我可以想到很多插件，其中侧边栏不能真正提供足够的空间并可能使侧边栏混乱。 仅有一些插件可能与此方法有关：

• Yoast SEO：提供了大量字段，可能不适合侧边栏-可能有一个侧边栏元框，该框打开了更多选项的模态，但这听起来像是在解决不必要的限制

• 自定义字段插件/拖放页面生成器-这些替换或部分替换主要内容区域，因此需要大量屏幕空间。 全页构建者有可能保证他们将自己的完全自定义界面构建为单独的视图，但是在某些情况下，除了主要内容区域之外还需要一些额外的结构化字段（我很欣赏Guttenburg应该减少对这些类型的需求插件，但同样不能涵盖所有用例）

• WooCommerce-在删除主编辑器的同时添加用于订单和订单项数据的元框（Woo计划最终构建自己的自定义界面，但我怀疑这还有很长的路要走，其他插件也会处于类似情况）

（我假设Guttenburg计划最终替换当前的post-new / post-edit.php视图，而不是简单地替代它？）

哈谢谢@braders -Yoast UX-er在这里以相同的问题进行检查:)

我们的metabox确实确实很大并且很广泛，因为它可以做很多事情。 我们不介意将这些功能更多地用于侧边栏中的不同metabox中以提供更紧密的集成，但是我想知道是否有可能？ 例如，是否可以像我们目前一样将SEO分数添加到“发布”框中？ 如果不是，即使我们的metabox是用JS编码的，我们仍然可以进入扩展设置框吗？

我们绝对应该考虑使新的“帖子设置”可插入，以便您可以将JavaScript metabox添加到侧边栏中。 也许是时候为此开票了。 该票证主要用于用PHP编写的metabox，它们需要以过渡方式工作。

与扩展部分中的metabox相同，是否有关于如何显示不支持帖子内容编辑的帖子类型的讨论或模型制作？ 在这种情况下，主要区域的编辑依赖中间区域的元框。 古腾堡是否应该呈现“仅标题”模式？ 还是应该在没有编辑者的情况下以不同的方式处理帖子标题。

与扩展部分中的metabox相同，是否有关于如何显示不支持帖子内容编辑的帖子类型的讨论或模型制作？ 在这种情况下，主要区域的编辑依赖中间区域的元框。 古腾堡是否应该呈现“仅标题”模式？ 还是应该在没有编辑者的情况下以不同的方式处理帖子标题。

为创建一个单独的票证会很好！ 如果有，请提供现有帖子类型的屏幕截图！ ✨

我还要强调一点，许多插件使用的自定义帖子类型完全依赖于元框，而根本没有内容编辑器。 如果在不支持editor情况下注册了帖子类型，则应该有一个仅标题模式，该模式将打开完整的画布以供meta框使用。

+1以联系WordPress VIP。 这也是Calypso线程上的问题： https :

对于顶级市场而言，确实是非常重要的功能！

我想知道是否可以通过iframe嵌入旧版metabox是这里的解决方案，其中iframe src类似于/wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings并且仅将一个metabox输出到文档中。

我也有同样的想法。 由于沙箱和会话管理的原因，这也是一个好主意。 然后，我们可以确定此功能的常见用例，并实现一个API来处理它们。

我想以插件开发人员的身份以及主要将WordPress用作电子商务工具的人参与进来。 也因为@kevinwhoffman告诉我。

今天让古腾堡（Jutenberg）感到很累，并且在没有看到metabox和编辑器按钮（通过media_buttons钩添加）如何成为其中的一部分的情况下，我真的无法将其作为WordPress处理。

我也不是WordPress编辑器和metabox-palooza当前状态的忠实拥护者。 我只计算了一次，在下载（Easy Digital Download的产品发布类型）单次发布视图中，我有14个由Yoast添加的自定义元框，Easy Digital Downloads和我自己的使用CMB2的自定义代码。 很多，但我需要这些。 没有该界面及其暴露的内容，WordPress毫无意义。

我担心，从一开始就没有考虑到这一点，因为我已经在很多站点上工作，其中添加了ACF，Pods，CMB2等的自定义字段界面是整个编辑体验。

这是我的技术问题：
1）通过media_buttons添加的按钮。 在我的插件Caldera Forms（活跃安装量超过8万）中，我们使用此操作添加一个表单插入按钮，该按钮会弹出一个模式，以将简码插入到帖子编辑器中。 也许我们会转到古腾堡的一个自定义街区。
2）save_post操作如何保持向后兼容？ 如此众多的插件，主题和自定义代码会在save_action上挂接并访问$ _POST super global。 这不是一个好的设计，但它的技术债务影响了数百万个站点。
3）有建议在iFrame中呈现旧版元框。 这让我担心，因为无法通过JavaScript访问iFrame的内容。

@ Shelob9嗨！

有人建议在iFrame中呈现旧版元框。 这让我担心，因为无法通过JavaScript访问iFrame的内容。

只要是在同一个域中，就可以通过JavaScript访问iframe的内容，就像在这种情况下一样。

save_post操作如何保持向后兼容？ 如此众多的插件，主题和自定义代码会在save_action上挂接并访问$ _POST super global。 这不是一个好的设计，但它的技术债务影响了数百万个站点。

我们只能做很多事情来简化传统元框到古腾堡的过渡。 与当前的后期编辑屏幕相比，古腾堡（Gutenberg）中的数据建模方式存在根本差异。 也就是说，现在实际上是第一次对数据建模。 通过数据建模，我们最终可以使用JavaScript接口以$_POST和save_post操作无法实现的方式来处理帖子和postmeta的状态，更不用说能够_preview_更改postmeta了。 通过在模型中路由后期元更改，这将允许首次预览后期元。 因此，即使古腾堡（Gutenberg）可以在任何可能的情况下都包括旧版元框，它们在使用新界面的能力方面始终受到固有的限制。 我认为这与我们拥有技术债务的现实一样多。

我认为这是Matt的有意和有意识的决定，如果WordPress以未来保持相关的方式发展，则必须取消技术债务。 我们越多地更新ACF，Pods和CMB2以使用Gutenberg引入的数据模型，这种转换就越容易。 毫无疑问，未来将有许多挑战和艰辛的工作！

@westonruter谢谢，这使“扩展设置”区域的用途更加清晰。

我怀疑这里的某些讨论也部分是关于可用屏幕空间的。

看起来Gutenberg JS metabox可以访问可切换的侧栏（对我来说很好），而旧版PHP metabox可以访问屏幕底部更大的可用区域（我也可以）。

不幸的是，我希望这种对可用屏幕空间的渴望可能会干扰有关如何有效处理旧版PHP元框的预期讨论。

我同意，插件制造商应该重新考虑他们的元框以及如何更好地与新布局集成，而不是支持所有旧方法。 同时，我也同意在新的编辑器中也应该提供类似的集成可能性（并且我相信它们会）。 我认为＃1352是目前讨论该问题的主要场所。 该问题用于讨论在发布时我们将如何为未更新的PHP metabox提供向后兼容性。

我想知道是否可以通过iframe嵌入旧版metabox成为解决方案

对于屏幕阅读器用户而言，访问iframe并不是一个令人兴奋的体验。 还有其他选择吗？

只是想在这里提示一下，对于我们在插件和主题中看到的大多数meta框，侧边栏根本不够大。 我认为强迫我们将事物塞进这个狭小的空间是一个挫折。 我认为这个新的编辑器很棒，但是如果这意味着牺牲我们今天使用元框的方式，那不是很好。

我非常同意@kevinpmiller 。 元框需要大量资源，并且不能隐藏在侧边栏中。 metabox的当前状态是脱节的和不良的设计，但它们也反映了WordPress是什么-高度可扩展的CMS。

回复@westonruter，感谢您澄清向后兼容性。 我认为需要非常明确地指出WordPress 5.0或该版本不向后兼容，因为这一直是用户的期望。

我还担心如何处理元框，尤其是在某些“自定义帖子类型”中，内容编辑器可能不是CPT的主要关注点。 我将在这里选择WooCommerce，因为它是一个著名的插件，但是还有许多其他插件和主题也存在类似的问题。

例如，WooCommerce订单没有内容编辑器-根本不需要它。 有关订单的详细信息很重要，而不是内容编辑，而正确应该是该页面的主要重点。

这样的CPT是否可以删除不需要的编辑器？ 该插件似乎并未与CPT中的自定义元框完全集成在一起，因此很难判断是否已考虑了这一点。

WooCommerce产品还提出了另一个问题，其中涉及两个内容区域–一个用于产品描述，另一个用于产品简短描述。 一个人是否需要在“主”编辑器区域中优先于另一个，而另一个人则被卡在边栏中？ 对于侧边栏中的内容，这似乎不是最佳的编辑体验。

是否可以有选择地在编辑器下方（或上方）注册这些设置，而不是将所有设置都塞在侧边栏中？ 这可能类似于当前的add_meta_box上下文和优先级参数。 也许，甚至可以在页面较宽部分中的多个内容编辑器（或其他元框）之间切换。

也许我在这里遗漏了一些东西（如果我错了，请纠正我），但实际上，似乎正在大力推动一个更好的编辑器，并不是所有的WordPress使用都需要与当今使用的有所不同的东西。

问题我们如何定义CPT以不使用Gutenberg（等效于没有编辑器），并且仅显示我们业务所依赖的全角元框。
我依靠元框。 我的CPT通常看起来像这样
'supports' => array( 'title' )
并从那里延伸。 请考虑我们中那些为带有约束力的表格数据输入使用带有元框的CPT的客户（而不是文章撰写）构建业务工具的客户。
我的工作主要是与客户端系统接口的CMB2的自定义扩展。 EG房地产清单，需要第三方系统。

我不想听起来很戏剧化，但是在解决此问题之前，我将坚持使用WP4.9，并且我对未来非常关注。 我了解到古腾堡正在“取消过去的债务”！ 但是债务却落在像我这样的人身上。

这里的主题似乎是问题不在于古腾堡，而在于缺乏向后兼容性。

有一些实际的古腾堡问题，应该提出单独的票证（允许元框使用全角，不带编辑器的模拟古腾堡模型），但是古腾堡不能完全复制当前屏幕，也不能尝试恕我直言。

但是，我确实想知道是否应该做更多的工作来使Guttenburg选择加入/退出。 一些想法：

• 我想大多数当前的CPT都会在主编辑器上大量使用元框。 因此，也许插件作者应该使用'supports' => array( 'gutenburg' )或类似

• 对于帖子和页面，Guttenburg作为站点设置可能应该是可选的。 甚至可以在5.0更新后询问用户是否要使用Guttenburg，并将此选择存储在数据库中。

• 或者，主题可以通过post_type_supports（）声明支持，但是这可能严重损害使用率-或选择退出主题将对不再更新的旧主题，未维护主题的用户无济于事。 （不过，对于具有旧主题的用户来说，一个remove-guttenburn插件就足够了吗？）

但是，无论采用哪种实现方式，我都认为，即使大多数用户越来越看不到当前视图，也应该保留当前视图。

我喜欢CPT的理论思想，即在未定义“ gutenberg”支持标志的情况下，明确要求'supports' => array( 'gutenberg' )来维护现有功能。 这将为我节省许多工作，为那些更新到WP5的愤怒客户修复旧站点。

我注意到现有的'supports'=>功能（标题，编辑器，作者等）具有非常可描述的名称，古腾堡在这里是_project_名称。 我想知道是否会考虑使用更具描述性的功能名称； 也许是“块编辑器”？ 'supports' => array( 'block-editor' )

当然，需要有一种策略来捕获诸如'supports' => array( 'title','editor',thumbnail', 'block-editor' ) 。 我假设“块编辑器”标志将简单地覆盖较早的“编辑器”模式。

另一个关心这个问题的插件开发者。

如果侧边栏meta仅可通过JS访问，这对于上下文为side PHP注册的metabox意味着什么？ 将其移至提议的“扩展设置”部分将取消以下想法：这些元框是上下文的。

众所周知，侧边栏不仅是一个美观的设计决定，而且还包括一些其他方面。 它们经常以帮助用户理解其内容的优先级以及与主要内容的关系的方式来保存关系内容。 由于技术障碍，为side框分配不同的上下文似乎有些误导。

考虑到管理区域的渐进式JS标准化，这些“旧式”元框还为插件和主题开发人员提供了自然的安装点，供独立的React / Vue /其他应用程序提供编辑页面的其他功能。

编辑器看起来很棒，但是请不要忘记页面的其余部分。

我有机会再多考虑一下，在这里其他人也有共同的背景下，我认为还有另一个问题。 这个新的编辑器迫使我们进入单一的布局和工作流程； 我们为什么要删除自定义？ 能够基于每个客户端雕刻数据条目的能力使WordPress和大多数其他解决方案真正出色。 我越玩这个编辑器，感觉就越像是Customizer的肿版本，其中预览区域已被编辑器取代，并且侧边栏只是切换了两边。

还提到我们可以使用它来编写帖子，但允许CPT添加对此的支持。 我认为那也不行。 新闻机构会喜欢这种类型的编辑器，但也需要围绕其他内容，日程安排，嵌入，信息图表和其他所需数据的自定义工作流。

如何使此编辑器的行为像全屏/无干扰的编辑器一样？ 这样，我们可以在不牺牲功能和“旧版”代码的情况下，两全其美。 （顺便说一句，我认为在我们的项目中将当前构建元框的方式现在称为“旧版...”是荒谬的）。

感谢您的宝贵时间，不胜感激。

如何使此编辑器的行为像全屏/无干扰的编辑器一样？

+1

我要重申我的主要关注点：CPT通常不需要“编辑器”，因为该帖子是由大型的动态分组的元框构建的，该元框位于指导用户的工作流程中（例如WooCommerce产品数据）。

这样的元框不适合建议的“扩展设置”抽屉，因为它们形成了主要的内容输入元素，并且需要在帖子编辑器中突出显示，全角和开放。 考虑到这一点，＃952似乎让步太小，因为它将重要的数据输入放到一个封闭的抽屉中。

如果期望我们的开发人员将所有旧的元框解决方案重构为块，那么Automaticc的某个人需要在锤子降到5.0之前清楚地公开声明这一点。 我看不出有任何迹象表明该团队已经考虑了这一部分市场及其对业务的影响。

这里已经添加了很多好主意，因此我将提出以下简单的主意：

当元框处于正常和高级上下文中时，为什么不为底部的每个元框都制作一个扩展器，而不是在底部为所有旧版东西添加一个“扩展设置”扩展器，然后使用侧面上下文的侧面设置？

似乎我们离解决方案还差得远。 如果帖子类型不支持编辑器，则只需隐藏编辑器，其他所有内容都以相同的方式显示。 这是一个合理的布局。 只需提供诸如设置默认的扩展元框之类的选项即可。

我当然不介意考虑当前呈现元框的方法，并提供一种新的，由js驱动和首选的方法来构建字段的想法。 然后，我们可以逐渐切换，而不必担心5.0中立即中断的事情。

希望这些想法有所帮助。 如果其他人已经为此说了些话，只需将此作为协议即可。 😄

我想在讨论中添加两个其他有价值的钩子： edit_form_after_title和edit_form_after_editor ，它们目前提供对后期编辑UI的完全控制。 显然，古腾堡不仅仅是“ wp_editor”的替代品，它还是UI的另一种完全不同的方式（从目前的情况来看，它还具有未来的模块化可扩展性）。

我看到类似这样的问题试图解决问题，但我觉得这与“我们的元框发生了什么”无关，而更多地与WordPress成为“产品”的问题有关。

找出建立这种解决方案的中期目标很容易：将其转移到前端（可能会更接近某些竞争对手）非常容易。

从开发人员/业务/规划的角度来看，了解“古腾堡”的（未来）意图会有所帮助，或者有人可以指出我的使命宣言或类似内容吗？

我还有更多意见...

我注意到现有的'supports'=>功能（标题，编辑器，作者等）具有非常可描述的名称，Gutenberg在这里是项目名称。 我想知道是否会考虑使用更具描述性的功能名称； 也许是“块编辑器”？ '支持'=> array（'块编辑器'）

我同意-这听起来像是一个细节，但一旦达成协议，就可以对它进行排序😄

当然，将需要一种策略来捕获错误，例如'supports'=> array（'title'，'editor'，thumbnail'，'block-editor'）。 我假设“块编辑器”标志将简单地覆盖较早的“编辑器”模式。

我会看到古腾堡扩展了当前的文章类型支持-因此，如果没有editor支持，那么古腾堡只会显示标题/侧边栏/扩展选项。 因此，也许将Gutenburg支持作为单独的CPT注册参数而不是支持数组的一部分来处理会更好？

当元框处于正常和高级上下文中时，为什么不为底部的每个元框都制作一个扩展器，而不是在底部为所有旧版东西添加一个“扩展设置”扩展器，然后使用侧面上下文的侧面设置？

我个人很喜欢这个主意-如果可以重新排列这些面板并在目前可能的情况下将其隐藏起来，那可能是一个主意解决方案...

可能还应该有一种方法可以将一个（或多个？）或这些设置为在页面加载时打开-特别是在帖子类型不支持主编辑器的情况下。

还提到我们可以使用它来编写帖子，但允许CPT添加对此的支持。 我认为那也不行。 新闻机构会喜欢这种类型的编辑器，但也需要围绕其他内容，日程安排，嵌入，信息图表和其他所需数据的自定义工作流。

如果新的基于反应的屏幕与旧的编辑屏幕一样可插入，则没有理由不能将这些自定义工作流程添加到页面顶部/侧边栏/编辑器下方或页面其他位置。 （免责声明：我对React没有深入的了解，因此有待观察PHP之外还会有多少个复杂的钩子）。 也＃1352

我认为这里的困惑是由于古腾堡（Gutenberg）在重新构想编辑器首先要成为

定义自定义帖子类型时，这可能包括所需的块以及仅允许使用的块。 对于不支持editor的自定义帖子类型，古腾堡中仍会显示“编辑器”，但实际上可以禁用_inserter_。 根据帖子类型的要求，出现在编辑器中的块将被锁定在适当的位置。 如果尚未填充块，则它们将显示为_placeholders_。 请注意，这些块然后可以像元框当前一样将它们的属性存储在postmeta中，但是它们将以规范化的方式进行存储，而不是通过save_post操作和$_POST global临时存储。

因此，我认为这里的最终结果将基本相同。 插件作者将继续获得一个“框”，可将自定义字段放入其中。 只是它们将出现在块而不是元框中。

我认为这里的困惑是由于古腾堡（Gutenberg）在重新构想编辑器首先是块时的方式上存在根本差异。 换句话说，我们应该远离考虑添加元框的考虑，而不再考虑添加块。 您原先将其放入元框的字段现在将向前移动，而不是放入块中。

@westonruter对于包含内容的metabox来说，这似乎足够明智，但是许多metabox服务于特定的post meta，这对于post内容没有意义。

感谢@westonruter的澄清，但这给我提出了两个新问题。

将数据存储为post_meta的块看起来与我到目前为止在演示中看到的完全不同。 这些数据还会冗余存储在帖子内容流中吗？

有什么阻止作者向帖子中添加超过可接受数量的块的吗？ （当只有一个有意义时，添加多个post_meta字段）

我倾向于同意@westonruter关于将块作为元数据网关的探索。 不过，我的建议是将块的想法与post_content分离。 自定义帖子类型上的块不一定是前端post_content的成员。 这是一个使用现代部落的事件日历（我的解释）插件的示例。

在这种情况下，主要内容是事件详细信息，而不是自由格式内容区域。 该插件将使用其自定义帖子类型中的元数据来组装其自己的标记，而post_content只是打印在页面底部的描述性文本。 因此，事件详细信息块根本不可移动，不可删除，或者根本不应该是内容输出的一部分。 但是，它应该首先出现，因为它代表了该帖子类型的主要内容。

WooCommerce将是另一个示例，在该示例中，一个或多个产品信息块应优先于Product帖子类型上的描述性文本，但它们不应是希望用户插入自己的可选块。

我认为，块的基本概念应该是为帖子组装适当的用户界面，而不一定意味着在前端存储或呈现数据的位置。

...我们应该不再考虑添加元框，而应该考虑添加块。

这对内容有意义，但是许多插件将自定义帖子类型用于表格或付款等非内容。 这些帖子类型与博客帖子完全不同，它们的抽象元字段也不会从块编辑器中受益。 强制所有配置由块完成将删除插件开发人员所依赖的开放式画布，而相同的开放式画布使插件生态系统变得如今如此。

当前的方法似乎是块优先的，其中元框仅限于辅助角色。 尽管块将使许多以内容为中心的插件受益，但定义抽象设置的需求仍将受益于元框提供的显而易见的标签和熟悉的输入。 在这种情况下，开发人员应该可以自由使用整个画布。

@westonruter能否请您澄清一下，这是什么意思，如果我的自定义帖子类型需要某些额外的字段，那么我将在块中输入该数据？

如果是这样，我有几个后续问题：

1）我可以将其设为默认值吗？ IE总是显示在该帖子类型上，无法删除。 例如，如果我的插件创建了事件，并且每个事件都有开始和结束日期，那么在默认情况下，编辑事件自定义帖子类型时，是否需要在发布内容中包含开始和结束日期的块？

2）如何从该块中保存数据？ 据我了解，现在，来自块的数据将作为HTML注释存储在post_content中。 我们如何从这些块中获取数据以发布元数据？ 例如，对于我的假设事件插件，我如何将开始和结束日期记入post meta中，以便我可以通过它们查询？

3）这样做的原理是什么，一切都朝着主要的内容编辑器方向发展，并将其应用于自定义帖子类型？ 是否有任何用户测试可以支持该设计方向，尤其是关于不代表博客文章/文章的自定义文章类型？

@kevinwhoffman我仍然看不到块的根本冲突。 抽象设置仍然可以被认为是内容，但是种类却不同：都是数据。 每个块都不需要在“内容”中有视觉表示。 我认为也很可能存在“元区块”，将数据存储在postmeta中，而不是post_content 。 可以对正在编辑的块进行样式设置，使其标题/标签类似于今天的元框显示方式。

@ Shelob9是的，如果您的自定义帖子类型需要额外的字段，那么我认为它们将以块显示。 如果您具有“产品”自定义帖子类型，则可能有一个product-details块，其中包含价格，变化等字段。

1. 我可以将其设为默认设置吗？ IE总是显示在该帖子类型上，无法删除。 例如，如果我的插件创建了事件，并且每个事件都有开始和结束日期，那么在默认情况下，编辑事件自定义帖子类型时，是否需要在发布内容中包含开始和结束日期的块？

对，就是这样。 自定义帖子类型，帖子格式和页面模板都可以简单地涉及“锁定”，无法删除或重新排序的所需块的概念。 这样的一个示例是帖子摘录的一个块： https :

1. 如何从该块中保存数据？ 据我了解，现在，来自块的数据将作为HTML注释存储在post_content中。 我们如何从这些块中获取数据以发布元数据？ 例如，对于我的假设事件插件，我如何将开始和结束日期记入post meta中，以便我可以通过它们查询？

如今，大多数块都将数据存储在post_content内的HTML中，但并非必须如此。 例如，在https://github.com/WordPress/gutenberg/issues/1288中，您可以看到有关在post_excerpt存储其内容的摘录块和在postmeta中存储其内容的Featured Image块的讨论。 因此，您绝对应该能够有一个event-details块，该块的开始和结束日期存储在postmeta中。

1. 这样做的基本原理是什么，一切都朝着主要内容编辑器的方向发展，并将其应用于自定义帖子类型？ 是否有任何用户测试可以支持该设计方向，尤其是关于不代表博客文章/文章的自定义文章类型？

上面的数据可以从post_content获取并保存到

@westonruter-谢谢您的澄清。 这非常有用，因为关于该编辑器与非博客文章/文章等文章类型的关系没有很多信息。

我希望我们很快会看到有关如何编写“元区块”的文档。

我们应该考虑我们通过帖子编辑体验教给用户的内容，以及它们如何映射到自定义帖子类型。

在块编辑器中编辑默认Post时，用户了解到每个块都代表内容。 与内容相关的设置位于块编辑器外部的面板/元框中。 内容生活在块中。 设置位于面板中。 在其他地方已经说过，用户在块编辑器中看到的应该是发布时页面的预览。

然后在自定义帖子类型的块编辑器中组合设置和内容，打破了块编辑器为预览的想法。 我认为我们应该让块编辑器做最擅长的事情，即编辑内容，并授权开发人员构建与内容块没有相同要求的设置界面。

我一直在研究一个广泛的插件，该插件添加了像WooCommerce和EDD这样的meta框。 大多数时候，由于不需要屏幕编辑器，因此我将其从屏幕上删除了。 我有点担心它不应该与古腾堡合并。
否则，这一切将何去何从。

我同意@kevinwhoffman的观点，即如果块将要表示元，则它们需要向用户提供视觉提示，即这些块与帖子内容有所不同，不应在输出中出现。 解决这个问题的一种方法是使用分频器。 从本质上讲，这只是对现在将内容与元框分离的方式的重新解释。

这并不能为我解决所有问题，但是我认为这是使metabox改头换面的一种有趣的方式，并且可能与现有插件完全向后兼容，但这对于用户而言并不是一流的体验。

这是一种尝试通知用户，何时元数据块是主要内容，帖子内容用作描述，以及其他元数据块。

@brentjett感谢您的样机。 正如您指出的那样，将设置与内容分开是很重要的，但是我不认为要求像Yoast这样的设置框首先成为块是没有好处的。

• 它不会代表页面上的内容，因此打破了块编辑器是页面内容预览的想法。
• 它确实不需要多个实例。
• 它确实没有从重新定位在其他内容块的中间受益。
• 默认情况下，它应_显示在页面上。

这些特征中的每一个都与块的默认行为背道而驰。 当然，有各种各样的讨论可以制作一次性使用的块，这些块可以锁定在默认位置并默认显示。 但是，当我们可以专注于改进已经实现此目的的元盒实现时，为什么要将一个块变成元盒呢？

我没有看到要求像Yoast这样的设置框首先成为块的好处。

让我们回到这里一分钟。 两件事情。 一种是支持使用PHP编写的旧元框，为此，我们在本文中模拟了“扩展设置”抽屉。

另一件事是回答这个问题：如果我们想从头开始进行重新设计，那么今天会是什么样？

这是我们提出的_blocks_的地方，它是可以统一许多不同接口的新接口。 我们已经建议，块可以优于短代码，自定义HTML，小部件和嵌入功能。 取决于metabox的功能，没有理由它也不能包含该接口。

同意对于Yoast，我们计划将其整合到新编辑器周围的许多地方，以增强gutenberg所针对的体验，而不是构建一个大的块来模仿我们的旧元盒，但是上面提到的其他示例将我想也可以作为一个障碍。 是的，这需要一些工作，但是如果事实证明该编辑器一旦获得更多关注，便会吸引wordpress用户，这是重新思考我们如何与之集成的令人兴奋的机会，我认为我们的产品将因此变得更好。

因此，我们有两个_legacy_功能案例：
处理元数据的MetaBox（例如Yoast），我们有用于提供输入内容的结构化界面的MetaBox（例如WooCommerce）。

为未来发展
如果我们从空白开始（“消除过去的债务”），那么将元数据放入提议的“高级”抽屉中确实会奏效。 同样，结构化的内容输入可能适合于古腾堡内部的锁定块顺序界面。 这两个都是完全假设的，但有可能将它们用作将来WP CMS开发的实现。

遗留业务CMS问题
我99％的工作是直接向客户公司提供定制的业务解决方案。 因此，我关心的不是我将来可能会创造的伟大事物，而是客户站点功能和业务关系的冷酷事实。 有什么建议将现有的基于CMS解决方案的业务迁移到Gutenberg？ 在我的情况下，每个客户端都有一个基于已建立的WP框架的不同的定制CMS解决方案。 对我来说，短语“取消过去的债务” =“用洗澡水把婴儿扔出去”。

顾虑
如果Gutenberg作为WP5.0的核心产品交付，我预计我的客户将拥有无法运行的站点。 然后，将需要重新制作每个站点，并减轻每个客户的负担。 那一周大概有40个客户希望我修理他们的CMS。

• 对CMS团队而言，旧版CMS Meta-box依赖站点及其用户群似乎不是必需的
• “优先”抽奖提议＃952已被取消优先级，表明整个地区都没有兴趣。
• 没有解决“过去的债务” / CMS问题的建议方法

这是我们提议的块，作为可以统一许多不同块的新接口。 我们已经建议，块可以优于短代码，自定义HTML，小部件和嵌入功能。

块对于所有这些东西都是有意义的-短代码，自定义HTML，小部件，嵌入。 它们都是页面上显示的所有形式的内容。 我同意，将它们全部屏蔽。

设置不是这些东西。 设置具有与块的基本行为不重叠的独特要求。 在许多情况下，这些设置框存储的帖子元与帖子的前端表示无关。 每次显示帖子时，都需要在内容旁边解析非内容似乎没有必要。

另一件事要考虑的是，当用户切换到文本模式时会发生什么。 他们会在帖子内容旁边看到一堆代表设置框的HTML注释吗？ 用户会删除这些陌生的东西吗？

通过将块作为内容和设置视为单独的UI组件，可以简化所有这些操作。 即使我们不必考虑传统的元框（ @steveangstrom指出这是一个巨大的问题），用户体验仍将受益于内容和设置的清晰区分。

@steveangstrom关注部分是对尚未解决的关注的总结。

这是对将来可能发生的事情的很好的讨论，听起来很不错，WordPress确实需要它。 对我来说，作为插件开发人员，没什么大不了的，我会做一两个步骤，然后做个好人。 但是，史蒂夫（Steve）的客户以及那里向后出售给客户的数百万个网站发生了什么变化呢？

我了解这些问题，因为我还有很多客户的网站可能会因更新而中断。 我的一些想法：

我们将ACF广泛用于内容管理。 例如，每个帖子或转发器中可能有多个tinymce编辑器。 如果目标是替换tinymce，我们将如何使用多个“块容器”？ 我现在正确地理解只有一个“块容器”，对吗？

选项页面是另一个不适合后期编辑流程的ACF功能。 我真的看不到如何在选项页面上。

对于那些想要向后兼容的人-如果没有时间/资源更新到gutenberg（有人打算使用此功能），有人可能会制作一个插件来恢复当前的编辑体验。 另外，5.0将是主要版本，这意味着可以进行重大更改（至少根据semver标准）。

WordPress不遵循semver。

@westonruter我认为这很有意义：

您原先将其放入元框的字段现在将向前移动，而不是放入块中。

但是，我们如何从那里（元框）到这里（块）？ 无论是针对代码的反向兼容（针对古腾堡尚未更新的插件），还是针对数据的反向兼容（一旦为其更新了插件，我们如何在新的内容块中显示现有的metabox数据；这是插件-范围问题？）。

但是，我们如何从那里（元框）到这里（块）？ 无论是针对代码的反向兼容（针对古腾堡尚未更新的插件），还是针对数据的反向兼容（一旦为其更新了插件，我们如何在新的内容块中显示现有的metabox数据；这是插件-范围问题？）。

这些是很好的问题。 实施这些功能时，我们将探索答案。

如果我不得不猜测我们将在这里结束的地方：当前的metabox将被移至“旧版”区域，并且我们将提供API，文档和示例来注册“新型” metabox-block-thingies。

@nylen当前元框的_rendering_怎么样？

好消息是，优先考虑元盒，但我们需要考虑的解决方案不仅仅是将旧的元盒放在抽屉中或将其限制在“旧版”区域。

如今，存在着无数个网站，这些网站主要是通过诸如高级自定义字段之类的插件通过元框构建的。 我们在这里讨论的是全屏界面，而不仅仅是帖子底部的一两个框。 我确定ACF将更新为与Gutenberg一起使用，但是这些站点将不会重建。

因此问题仍然存在，没有编辑器并且完全由元框组成的接口会发生什么情况？

因此问题仍然存在，没有编辑器并且完全由元框组成的接口会发生什么情况？

这里的想法是，如果我错了@mtias ，请纠正我的想法是，您只是用插件隐藏了内容区域，而您看到的只是内容所在的元框。

如何使此编辑器的行为像全屏/无干扰的编辑器一样？

+1。 这是一个好主意，因为它完全不会影响带有元框的当前编辑器。 尽管无干扰的编辑器已经存在很长时间了，但使用起来并不多。 古腾堡（Gutenberg）编辑器可以采用此功能并加以改进，而不必重写编辑器屏幕。

同样，最好在register_post_type时使用supports参数注册对Gutenberg编辑器的支持。

最后，作为meta框开发人员，我很想看到新的API，以使meta框适用于新的编辑器。 如您在此处看到的，许多开发人员使用元框作为为帖子提供附加内容的一种方式。 这些内容可以分类，以后再搜索。 不仅仅是简单的内容块（如发布内容）。 因此，如果有add_meta_box()函数的新替代品，我很乐意重构我的Meta Box插件来使用它。

同意所有关于re的说法：使标准metabox仍然有效/有位置。 作为CMB2的首席开发人员，我可以保证，如果在WordPress 5.0发布时CMB2以某种方式被破坏，将会有相当大的抗议。 我当然不是说这是威胁，而只是现实。

我们越多地更新ACF，Pods和CMB2以使用Gutenberg引入的数据模型，这种转换就越容易。

我肯定会长期考虑这样做，但是我不确定在gutenberg发布之时metabox库是否会适当地实现这一点。 （当然，这可能不是预期的结果）

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

即使已更新，旧的安装也将被破坏。

另请注意，ACF中的字段组不必位于元框内，但标题和编辑器之间还可以使用样式“ Seamless（no metabox）”（无边（无元框））以及“边”，“内容后正常”和“高”选项（!!!）'。 最后一个对于创建有意义的编辑流程很重要。

请记住，那里有很多关键的个人开发项目，永远不会更新，因为没人会为此付费。 打破这些实现将成为企业环境中WP的最终杀手。

@ wsydney76另请注意，ACF中的字段组不必位于元框内，但也有“无缝（无元框）”样式，其标题之间有“边”，“正常（内容后）”和“高”选项和编辑（!!!）”。 最后一个对于创建有意义的编辑流程很重要。

值得注意的是，这并不是在WordPress中“正常工作”，而是需要自定义插件代码来删除常用的metabox UI-因此可以合理地假设，这需要ACF进行额外的工作才能与Gutenburg一起使用。

简单点。 如果自定义帖子类型不支持声明的编辑器（Gutenberg），请使用您的想象力，CSS技能和最有才华的核心设计师将整个编辑器转换为其他内容。 使它显示为（本机）后期编辑屏幕中客户/用户看不到的东西。 这只是关于外观。 客户不在乎Gutenberg是否在后台工作，即使Web开发人员告诉他们，他们也不会在乎。 他们是人的视觉类型。

关于向后兼容性，我早在二月发布古腾堡宣布5.0之前就提出了WordPress的长期支持版本。

在那时，这似乎是一项不可能的任务，但是现在它正在发生，讨论将4.9设为LTS版本，切断4.9之前的支持并专注于5.0甚至变得更加重要。

该帖子可以在这里找到：
https://khromov.se/wordpress-needs-another-long-term-support-version/

10年以上的WordPress开发人员。 正如许多人士指出，这种发展是非常适合的内容。 对于带有自定义标记的动态内容块，这是真正需要的标准解决方案。 话虽这么说，但这确实限制了帖子类型的使用，这种方式会从内容中引出并使WordPress更接近框架。

例如：我构建了一套插件，不仅可以为帖子类型（如许多其他类型）创建字段，还可以在它们之间创建关系（即一对一，一对多等等）。 这（加上更多功能）将帖子类型转变为与Laravel或Rails等框架中的模型非常接近的内容，然后我使用DSL处理这些帖子，它们的数据及其关系。

这种用法绝非罕见，WordPress本身通过允许开发人员将帖子类型声明为非公开，鼓励了帖子类型的创造性使用。 诸如“ public”，“ publicly_queryable”和“ show_ui”之类的标志都是为了允许开发人员将帖子类型用于除网站上与公共页面的简单1：1镜像关系以外的目的。

古腾堡如何符合这一愿景？

除了使该编辑器保持可选状态外，我没有其他解决方案，即仍应替换TinyMCE，但该编辑器应保持可选状态，就像TinyMCE现在是可选的一样。

如果我们可以继续创建不支持编辑器的帖子类型，并且可以继续在这些帖子类型中使用元框，那么我相信可以更快地达成共识。

通过这种方式，主题和插件开发人员采用新编辑器的速度可能会变慢，但是老实说，我看不出有别的方法，这并不意味着要走4.9 LTS之路，这将允许启动新项目与WP 5.0和旧项目一起使用4.9 LTS。

更新：当我写这篇评论时，线程的标题是不同的，正在讨论弃用元框的可能性（即，核心团队尚未像在下面的评论中那样明确地用“否”来明确回答这个问题）。 在这种情况下，古腾堡将只支持动态块，而忽略了元框的许多其他用例，因此我在上面发表了评论。

花了一些时间阅读每个人的评论后，在我看来，编辑屏幕这种演变的可能结果是提供了一个新的metaboxes api，它可以在基于js的编辑屏幕中使用。 也就是说，我们实际上并没有像我上面提到的那样失去以创造性方式使用帖子的能力，但是我们只是获得了一个新的api来执行此操作，并且UI将基于js。

我们计划使用Pods 2.7通过WordPress REST API和GatsbyJS构建由React驱动的应用程序。
古腾堡会与Pods兼容吗？

我看到这个重要问题已从任何里程碑中删除。 _again_被取消了优先级，而博客编辑的繁琐工作又被添加到beta中。 这对于Wordpress作为CMS的未来非常令人担忧。

我使我自己的代码生成器受到GenerateWP的启发。 供我自己和私有使用，而不是公共使用。
无论如何，我想知道切换完成后它在古腾堡的外观如何。 ACF字段，许多用于预览的自定义PHP代码。

我们没有忘记这个问题。 而是，这是一个极其复杂的问题，我们只是为了让编辑器正常工作才开始研究许多其他优先事项。

阅读＃2251后，我们可能会在连接metabox时遇到一些困难，从技术的角度来看，它也包含有关下一步的信息。

在这里，我要强调的重点是，我们需要社区的帮助来计划和测试此实现。

这是查看插件列表的起点：

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

未出现在上方的插件，很可能是因为它们不在WP.org插件目录中：

• 现场经理

如果您知道其他广泛使用的插件可以完成类似的任务，请在本期中告知我们。

如果您是这些插件之一的开发人员，并且/或者可以提供有关这些插件使用WordPress钩子添加其元框并加入任何相关脚本或样式表的详细信息，请在本期中让我们知道或创建一个新插件上面列表中每个特定插件的问题。 收集这些信息非常耗时，对于将其全部集中在一个地方的进一步开发工作将非常有帮助。 例如：

Advanced Custom Fields通过注册与admin_enqueue_scripts的钩子来添加其元框。 该钩子验证当前页面加载是post.php还是post-new.php ，如果是，则添加一个admin_head动作，调用add_meta_box 。 WP核心在该操作之后不久在edit-form-advanced.php执行其do_meta_boxes调用。

最后，如果您是熟悉WordPress当前呈现和保存元框的方式的开发人员，则感谢您在此处和/或＃2251上的输入。

嗨，大家好，
Elliot在这里-ACF开发人员。

ACF使用admin_enqueue_scripts操作执行“字段组匹配逻辑”，然后使用admin_head操作添加元框（通过add_meta_box() ）。 它不使用add_meta_boxes操作。

我可以在这里问一个明显的问题吗？ 我们为什么要讨论元框的“难点”？ 这些是每个WP网站的组成部分。 当然，元框逻辑可以保持原样，并与新的Gutenberg编辑器区域一起使用。

请确保也标记@woocommerce 。 它们很可能是最大的metabox插件。

谢谢
Ë

嗨，大家好-

我仍在提出一些想法和想法，但我想提出一个简短的问题，因为似乎讨论太集中了。

为什么我们只谈论将字段添加到元框？ 当前的系统允许我们添加任何内容。 数据，使用JavaScript击中第三方API的工具，使用注释或帮助信息的快速显示，甚至是可爱的小猫的图片都会给人们带来高分的五分（好吧，也许不是，但是谁知道吗？！）。

我在这里要说明的是，元框是通用容器，可以容纳各种东西，包括但不限于字段。 现在使用PHP可以很容易地做到这一点，但是我们当前是否正在要求人们知道如何编写一个React Component来表达一些文字？

就像我说的，只是想增加对话的内容。

谢谢，

Kevin-Piklist首席开发人员

上面的许多评论都提到了这个问题，但据我所知尚未得到回答：

是否可以用Gutenberg替换现有的TinyMCE帖子编辑器，同时保持其余界面（包括元框和现有的挂钩）不变？

通过缩小范围，可以通过在注册帖子类型时定义editor支持，从而将Gutenberg包含在自定义帖子类型中或从中排除。

• 如果注册了editor支持，那么Gutenberg将出现在编辑屏幕上，现有的元框将继续像今天在当前编辑器中一样起作用。
• 如果未注册editor支持，则不会加载Gutenberg，并且空白画布可用于今天的元框。

这种方法似乎避免了与现有元框实现向后兼容的巨大挑战，同时释放了资源以使最佳编辑器成为可能。

我可以在这里问一个明显的问题吗？ 我们为什么要讨论元框的“难点”？

@elliotcondon-如果开发人员的问题难以解决，那么解决方案的唯一方法就是解决这些困难。 我从＃2251开始执行此操作，但是如此处所述，这将不是一项快速的任务或简单的修复。

感谢您确认我收集的有关ACF如何注册其元框的信息。 为了在有关ACF的实现方面取得更多进展，以下是一些有助于您了解的事情：

• 哪些脚本和样式表已排队以控制ACF元框的功能
• 哪些动作导致他们入队
• 控制它们是否入队的任何条件。

为什么我们只谈论将字段添加到元框？

我想到达一个地方，古腾堡（Gutenberg）代码不必太在意metabox实际在做什么。

为了达到这个目标， @kevinpmiller ，以下是对Piklist有用的了解：

• 什么操作负责调用add_meta_box注册元框
• 控制它们是否已注册的任何条件（例如，当前屏幕为post.php或post-new.php ）

在本期中，让我们继续关注于使现有的PHP metabox与Gutenberg接口一起工作。

现在使用PHP可以很容易地做到这一点，但是我们当前是否正在要求人们知道如何编写一个React Component来表达一些文字？

是的，我们需要制定一套用于创建“新型”元框的API。 这就是我们今天要使用的块-我希望它会非常相似，元框被注册为“块”，可以保存post_content ： http :

有关新型元框的讨论应在＃1684或另一个提出技术API的问题上进行。

如果未注册editor支持，则不会加载Gutenberg，并且空白画布可用于今天的元框。

@kevinwhoffman-今天写的古腾堡打算成为post_content编辑器。 因此，有理由断定，如果未启用editor支持，那么至少到目前为止，我们将其禁用。 从代码角度来看，这也是一项非常容易的任务。 您可以为此创建新的问题，我将其标记为Good First Task吗？

今天写的古腾堡打算成为post_content编辑器。

@nylen如果Gutenberg确实打算成为post_content编辑器，则meta框应单独放置，因为它们与post_content无关。

此外，需要一个API将PHP meta框转换为React meta框是一个人为问题。 这不一定是问题，但已经成为问题，因为在此过程中，某处决定重写post_content编辑器也应该完全改变元框的工作方式。

您已经概述了在＃2251中编写此类API所面临的巨大挑战。 将PHP meta框转换为React以便使用ACF等流行的自定义字段解决方案具有挑战性，更不用说尝试针对当今存在的每个meta box实现（不管是否流行）这样做。 它不缩放。

@kevinwhoffman-说得很好。 这反映了我的确切想法以及与我交谈过的许多其他开发人员。

我不希望这个问题脱离话题，但是我不明白为什么在引入新的JS页面构建器时需要有“元框”困难。 这就是我说的意思：

我们为什么要讨论元框的“难点”

我很高兴读到：

如果未注册编辑器支持，则不会加载Gutenberg，并且空白画布可用于今天的元框。

如果上述是正确的，则对于帖子的编辑屏幕，所有wp-admin逻辑（动作，功能等）都应保持相同。 因此，应该没有理由不能解释多年以来仍无法呈现metabox HTML的原因。

@nylen
ACF排队一些JS和CSS文件以设置样式并与ACF metabox HTML元素进行交互。
ACF使用'admin_enqueue_scripts'操作添加这些资产
还有许多其他插件和主题加入样式/脚本的行列-为什么会出现问题？
ACF不使用JS保存元数据。 它使用save_post操作来保存任何$_POST数据-相当正常的东西。

此外，需要一个API将PHP meta框转换为React meta框是一个人为问题。

这不是我们正在做的事情。 这更像是：由于我们不再使用传统的post.php加载过程，因此我们需要从中选择所需的东西。

如果未注册编辑器支持，则不会加载Gutenberg，并且空白画布可用于今天的元框。

需要说明的是：目前还不是这种情况，但是在PR中探索是合理的。 如果您有兴趣今天看到此功能，请提供帮助，它会更快地进行。

@kevinwhoffman @elliotcondon @nylen或者更好的是，怎么样：

• 如果已注册block-editor支持，请使用Gutenberg。
• 如果已注册editor支持，请使用TinyMCE。
• 如果未注册任何支持，则不会加载Gutenberg或TinyMCE。

我不赞成根据存在或不存在古腾堡（Gutenberg）来区分WP Admin的经验。

如果Gutenberg = New React Meta Boxes，而No Gutenberg = Old PHP Meta Boxes，那么一个零散的管理员将是我们前进的方向。

无论是否存在编辑器，元框都应在任何地方都相同。

示例：假设我有一个插件，该插件添加了一个meta框来对5颗星进行评分。 该插件经过构建，因此可以对任何帖子类型进行评分。 为什么根据帖子类型是否使用编辑器来更改该meta框的内部结构？

@kevinwhoffman

我不赞成根据存在或不存在古腾堡（Gutenberg）来区分WP Admin的经验。

这是对我有关block-editor建议的回应吗？

顺便说一句，我不认为我的建议会破坏经验，我认为这是基于您的建议，如果WordPress配置中包含现有元框，则将其包括在内。

@mikeschinkel启用或禁用Gutenberg的能力是必需的，但是Gutenberg确定元框行为的想法是我所反对的。 这些是单独的问题。

@kevinwhoffman我同意你的

在Pods中，我们使用与ACF和CMB2相同的操作来进行正常的，有文档的标准操作。 我们几乎都按照建议立即执行的方式进行操作。

+1继续与Gutenberg一起使用元框的能力，最终人们将能够使用Gutenberg处理直接属于内容的事物，而对于其他所有内容，仍然有他们喜欢的meta框用于属性和有关“帖子”的其他信息（任何类型）。

-1关于必须重写React中的所有内容，至少在很长一段时间内都支持两者，直到每个人都有时间熟悉React方法，并且它支持更多/使元盒实现得以解决。 我认为没有时间淘汰PHP meta框，保留它们以进行反向编译，并随着React meta框文档和开发人员技能的提高而让插件迁移。

在此票证中的讨论以及由此产生的公共和私人对话之后，我认为有一个关键问题必须在这里回答：

WordPress是否打算正式弃用Metabox API？

如果答案为“否”，那么整个“让事物四处移动并使其稍稍残废”将是无用的。 如果该API仍受WordPress核心的向后兼容标准支持，则完全希望所有现有的metabox实现都可以正常工作。 就像WordPress一样。

如果答案是肯定的，那么这将是巨大的向后兼容性策略更改，并且整个WordPress开发的时代将结束。 它不仅需要“解决”古腾堡中的元框。 这将需要进行大量的再教育和澄清工作，以某种方式完成多年的WordPress核心开发并提供一定水平的向后兼容性期望已经结束。

不幸的是，当前答案似乎不会说是，而是打算打破事实，却装作是“否” 。 就我个人而言，我发现它对于主要的核心功能来说是非常不典型的方法，并且以这种方式完成它是非常令人不安的。

“发布编辑”屏幕是除准博客之外的每个项目上最自定义的屏幕。

这些自定义不限于注册元框。 编辑管理员屏幕提供的任何钩子都在同一项目中使用。 对于没有钩子的情况，开发人员使用jQuery将UI元素注入页面。

因此，对于这些定制，需要有前进的道路。

对于metabox，Fieldmanager是VIP认可的工具，因此是首选。 Fieldmanager功能强大，但专注于有限的一组字段。 传统代码库通常无法改装为使用Fieldmanager或其他实用程序库。

因此，仍然使用自定义代码来构建许多元框。 定制代码表示PHP和JavaScript的结合，通常与Ajax驱动的交互有关。

将所有这些精心制作的元框从其预期位置填充到编辑器下方的区域的建议是荒谬的。

现在无法使用“发布后编辑”屏幕上的自定义选项进行的任何回归都是不可接受的。

如果需要更新现有代码，则可以在所有新API最终确定之后的12到18个月内完成这些升级，以在客户端项目上进行。 这意味着需要有一个双重运行期，在此期间，旧版API和新版API会共存。

我不明白为什么Metaboxes必须与Gutenberg做任何事情？ 它只是一个后端页面，即屏幕。 可以数百种方式安排。
您说目前的实现破坏了React。

让开发人员选择是将他们的Metabox绑定到Gutenberg，还是将其保留在外面。
所有这些问题是因为您假设每个人都必须以某种方式制作古腾堡积木。 如果他们不想要它，怎么办？

我个人的第二大问题。 我一直都在用javascript挣扎，我对这种语言很反感。
好吧，不是所有事情都围绕着我旋转，而是说。 与以前相比，添加Metabox并不容易。

我认为@Rarst很好地总结了这个问题。 社区需要一个明确的答案，感觉开发团队似乎倾向于遵循弃用的方向，但是由于它首先尝试找到解决方案而无法明确说明，我完全尊重。 我们不需要一个月来陷入恐慌的社区，但与此同时，同一个社区也需要有足够的头脑和明确的道路。 老实说，这是很难找到的折衷方案。

@ fklein-lu我强烈不同意Fieldmanager应该是“首选工具”。 我什至没有在十大领域插件列表中看到它。
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

就像许多其他人所说的那样，虽然我理解使元框和古腾堡成为一个连贯的，相互连接的界面的愿望，但改变元框的工作方式却引入了令人难以置信的复杂性，最终可能对人们产生巨大的威慑作用。 历史向我们表明，在版本之间引入主要的不兼容性会严重破坏社区。

如何将Metaboxes添加到Dashboard后端屏幕？
它与古腾堡无关。

@khromov阅读我实际写的内容，而不是错误地引用我的话。 另外，如果您阅读了所引用

@ fklein-lu不确定您为什么认为我给您报价错误，这里是全文：“对于metaboxs，Fieldmanager是首选工具，因为它已获得VIP批准。” 我不认识使用Fieldmanager的人，因此我很难理解该报价。

我知道Fieldmanager不在WPorg上。 我的意思是说我们没有使用数据。 我非常怀疑它是否可以与某些顶级插件相媲美，并且除了将其用于VIP之外，它在社区中的支持也很少，而后者仅占开发人员总数的一小部分。

在我们的机构中​​，我们认为WordPress在3.x的某个地方已从Blogging-System迈向Content Management System。 现在，我们能够按照项目的需要来调整内容的形状，并且使用自定义帖子类型和元框来创建各种不同的内容，而不仅仅是文本。

如果在5.0中强制使用块编辑器，我们坚信这将是从CMS向博客系统倒退的意识形态步骤。 有大量的企业应用程序，它们将WordPress作为酒店预订解决方案，作业平台，用于应用程序的Headless CMS，位置服务等运行，并且其中许多用例甚至都没有激活编辑器。

绝对必须与当前metabox实现完全向后兼容。 打破这种局面将打破未来几年对客户和用户的信任。 我最喜欢的解决方案是基于“ theme_supports”和无干扰的可用性。

TL; DR：不要期望企业客户在未来12个月内会更新其代码，而不进行维护。 添加带有适当时间表的弃用政策/警告。 当您在后端和代码可用性方面进行更改（甚至更好）时，期望对WordPress的信任度会大大下降。

它以某种方式成为政治或投票/选举，而不是编码。 一些人认为旧的元框是“旧的”，“后退的”，“限制的”，并且不再有放置它们的地方。 没有任何真正的论点和反对他们的理由我没有看到它们，除了React和其他脚本是涡轮现代的。

我仍然支持您找到抛弃旧的Metabox的解决方案，并按照您想像的古腾堡方式来做。 但是似乎您不知道如何解决它。

当很多事情对我来说仍然是个黑洞时，我很难讨论所有这一切。 我不是唯一的一个。

为了说明我在这件事上的客观性，请尝试：

• 我仍然认为TinyMce和旧的帖子屏幕（带有Metabox）是我在CMS世界中看到的最美丽的东西。 功能，过滤器，扩展和精美的设计。 是的，纯净的美丽和愉悦。
• 尽管如此，我从第一天开始接受古腾堡。 是的，抛弃所有这些“旧”的东西，切换，再也不回头。

他们知道我不知道的东西。 他们拥有代码。 但是我不确定。

第二件事，忘了它，在这种情况下非常重要。 这里已经被提及过几次了。
我做的事情与其他人有所不同。 从第一天起我接受古腾堡（无论如何就是其中之一）的原因是，我个人毫无疑问可以说服我创建网站的人使用古腾堡。 当您强加给他们与TinyMce有所不同的东西时，这是很大的嘲笑。
我免费为所有插件和WP核心更新。 因此，在这个难题中，当他们不得不在古腾堡和其他任何更新停止之间进行选择时，会剩下一些时间。 我认为他们的选择是显而易见的，

许多其他开发人员（公司）负责更新。 因此，这个难题将不会那么轻松。

@khromov我在Alley工作，该公司负责Fieldmanager。 在确定产品方向的同时，我们正在积极监控螺纹。 可以说WordPress.org用户群通常不使用Fieldmanager，但是该插件确实已被广泛用作库和自定义/企业框架。

我也想+1 @Rarst和@kevinwhoffman。 维持对现有metabox的完全支持仍然可以使我们有一个未来，在这种情况下，我们用TBD Gutenberg等效项替换“ legacy” metabox。 但是现在必须尽快解决向后兼容性方面的不确定性。

从WordPress.org安装的插件数量不能成为包含或排除插件或库的唯一指标。 我知道有一个广泛使用Fieldmanager的_single_网站，并且该网站每月为接近2400万唯一身份访问者提供服务。

因此，即使只有少数开发人员可能会使用特定的插件，但他们仍负责开发和维护流量不成比例且可见度很高的网站。

因此，不能将它们排除在讨论之外。 我认为Automattic的Gutenberg团队应该与VIP团队合作，以深入了解这些用例。

这些企业项目的运行速度较慢。 升级元框和其他不是实际编码工作的UI元素的工作量很大。 在5.0时间内，甚至没有足够的企业开发人员来升级所有这些站点。

正如该线程中的其他人所指出的那样，需要有一条将这种步伐考虑在内的升级途径。 这样，作为主动维护工作的一部分，更改可能会逐渐发生。

@ fklein-lu见上文，我们正在倾听，如果您想在代码上进行协作，可以随时与我们联系！

至于VIP和企业市场，我希望下周在丹佛的WordCamp for Publishers上有更多关于此主题的对话。 就是说，我们与Gutenberg devs＆@ m取得了联系，但AFAIK没有人可以参加。

关于“ 5.0”时间轴，目前，我采访的企业工程师都假定存在使用现有TinyMCE编辑器和元框的足够简单的退出路径。 相信古腾堡（Gutenberg）团队也对此假设给予了肯定。

我有一个使用Jetpack的网站，每天只有2个唯一身份访问者。
别那么容易得罪蜜蜂。 它是WordPress，而不是有关新Joomla版本的讨论。 :)

@ fklein-lu绝对同意。 但是，如果有什么要成为metabox字段的“选择工具”，我认为这应该是提议的Fields API 。

@davisshaver我认为这是明智的选择。 如果WordPress试图在不向后兼容的情况下强力使用弃用方法，那么我可以很容易地看到有人将旧代码块移植到“并行”，基于旧版的替代帖子和元框系统中，并将其打包为插件或类似的东西。 就我个人而言，那是我希望看到的一切。 再次重申，这绝对是艰苦的工作，因此，我希望所有参与将WordPress社区运送到这片未开发的新土地的人们都好运。

感谢大家在这里表示赞赏，并表达关注和想法。 这将成为一个漫长的话题，但我将尝试澄清几点。

WordPress是否打算正式弃用Metabox API？

没有。

尚未完全解决的问题是_元框如何在gutenberg编辑器的上下文中工作_。 它们应该保持不变还是进化？ 我们如何在尽可能减少破坏的情况下实现设计目标？

这个问题之所以存在，不是因为缺乏欲望，而是由于缺乏资源。 该项目的主要重点是提供丰富的内容编辑界面，该界面针对通过块的概念直接操作用户内容进行了优化。 （我已经将meta-box广泛用于各种项目，我相信block可以为满足许多这些需求提供更好的进步，同时提供更好的用户体验。）

但是，可以通过多种方式来处理元框和可扩展性：

• 如果我们检测到已注册一个元框，则可以回退到旧界面，没有任何变化。
• 我们可以将内容编辑和修改元信息分为两个屏幕或两个阶段。
• 我们可以尝试查看在内容＃2251下面按原样呈现这些内容（PHP）是多么可行。
• 主题/插件/ CPT可以根据需要注销新界面。
• 可以将依赖于元框的各种项目转换为UI块（仍单独存储数据）。
• 我们可以像Fields API一样实现基于API的元框可扩展性。

或这些的任何组合。

我们绝对希望社区提供任何帮助，以在此处建立最佳解决方案，因为再次，缺乏确定性不是缺乏意志。 只是需要在实践中探索可能的解决方案，并清楚地权衡取舍（明智的设计和开发）。

没有。

谢谢，我想很多人都在呼气。

尚未完全解决的问题是元盒在gutenberg编辑器的上下文中如何工作。

为什么在古腾堡（Gutenberg）编辑器上下文中使用元框？

答案似乎是Gutenberg打算用JS驱动的实现代替整个帖子编辑器_screen_。 我没有关注开发原因。

但是我仍然认为这是非常正确的观点-如果古腾堡的范围要成为编辑器组件，那么替换_screen_范围似乎过于雄心勃勃。 _如果_古腾堡的范围是（至少部分地）替代了WordPress _admin_整个范围，那么它的范围将更广且要求更高。 并不是说替换“ just”编辑器很容易。

但是，可以通过多种方式来处理元框和可扩展性

古腾堡的目标是替换主要的_editor_组件，而现有的管理UI仍然可以正常工作？ 是否正在考虑_this_，如果不是，为什么呢？

我只能代表我构建的Field Manager插件，目前我们目前在60多个不同的项目中使用。 我将简要地提到这种变化对它意味着什么，希望它可以帮助任何人考虑自己的情况。

因为我经历了使用通用抽象类和接口构建高度分离的体系结构的麻烦，所以我要做的就是添加一个新的“位置”。 以下是与我的观点相关的架构组件：

• 位置：附加字段组的位置（例如，帖子，页面，分类术语等），每个位置都有一个变体（例如，“帖子和设置”位置适用于元框）。 此类实例化了下面提到的所有运动部件
• 位置数据存储区：负责检索和保留数据的层，每个位置都有一个变体（例如post DataStore用于post meta，Settings用于选项等）
• 位置视图：在需要时（与设置页面一样），它是一个View类，其中包含模板和任何帮助程序功能

现在，在古腾堡的背景下，如果我要支持这位新编辑，我个人要做的就是添加一个名为古腾堡的新位置，该位置将具有：

• 它自己的初始化方法会将其挂接到Gutenberg编辑器。 我想这将主要基于javascript，因此我的库将注册并加载为此目的所需的通用脚本。

• 它自己的视图/模板：我将不得不为每种字段类型创建一个react组件。 这没什么大不了的，当所有其他部分都正确设置时，视图层非常简单。 然后将这些组件嵌套到metabox react组件中。 这都非常类似于我对基于php的metaboxes html所做的工作，即html字段> html字段组>位置（设置页面html，metabox等）。

• 它自己的数据存储类。 我不认为此类与发布位置数据存储区会有很大不同，因为这将基于发布元（我想没人会很快想到弃用发布元）。

• 新作品：端点。 这些新的基于React的组件将需要能够与数据存储进行通信以检索和保留值。 由于这些组件完全驻留在客户端，因此它们将需要端点作为与位置数据存储区进行对话的桥梁，而元存储区则需要检索将在任何上下文等环境中加载的组件。

如果我没有错过任何重要的事情（我承认我还没有时间检查古腾堡），那么这或多或少就是我想为本地支持这个新“位置”而必须做的要旨。 我还对每个位置及其过滤器进行了内置检查，以确保开发人员正在询问的内容是可能的，例如，如果我尝试将字段组添加到“项目”帖子类型中，则该帖子类型为“视频”时的格式”，但该CPT不支持帖子格式，则该库将引发异常。 我希望我可以在这个新位置提供相同的反馈，例如，如果我将一个字段组添加到帖子类型为“评论”的古腾堡位置，那么我希望我能够知道该帖子类型注册支持古腾堡。

结果比我预想的要长一点，我的糟糕。 我很乐意听取任何与古腾堡（Gutenberg）开发有关的人员或任何有类似关注的图书馆作者的反馈，这些反馈可以分享。

谢谢。

古腾堡的目的是取代主要的编辑器组件，现有的管理用户界面仍然可以正常工作吗？ 是否正在考虑这一点，如果不是，为什么呢？

古腾堡确实从编辑器框开始。 开始的目标是在一个统一的块接口下统一多个不同的接口。 显而易见，为了使我们能够围绕统一的块界面创建引人入胜的体验，我们必须考虑整个写作流程，包括设置和发布。

如果WordPress的主要优势是使任何人都可以轻松创建丰富的帖子，那么我们不能仅仅为已经知道如何使用编辑器的人设计。 我们必须考虑以前从未使用过WordPress的用户，以及他们在现代发布界面中的期望。 否则，我们只会在已经很重的界面上增加认知负担。

我们还没有完成，这并不容易，但是我们每天都在努力。

☝️我已更新票证标题和说明，以期解决一些误解。

古登堡新任编辑和ButterBean的未来

按照上面的

回购： https :

出于测试目的，该插件中包含该框架： https :

ButterBean是使用Backbone.js和Underscore.js构建的嵌入式框架。 它很大程度上是基于核心WP中的定制程序建模的。

这是一个年轻的框架，但是我已经计划今年将其引入多个插件。 现在，由于古腾堡（Gutenberg）的指示，我和其他人都不愿这样做。 而且，我什至不确定我是否应该从头开始在React中还是从头开始，或者最终决定将任何JS框架添加到核心WP中。

挂钩使用

以下是所使用的主要核心WP挂钩（我想像，这是大多数meta box框架的相当标准）：

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

创建＃2265来记录CMB2的相关挂钩。

添加了“设计”标签，以鼓励人们添加其他模型。

通常，我认为不属于所显示内容的数据不应属于主编辑器区域。 不是所有的东西都是障碍。

1）我的大多数自定义元盒都是由Fieldmanager制成的。 在我看来，这些应该“只是工作”，除了更新之外，我不需要其他工作。 cc / @mboynes和@bcampeau，因为它们可能为这次讨论提供价值。

2）我们的一些自定义元框是jQuery和PHP的混合。 例如，我们有一个“一个或一个”元框，它是一个带有“清除”按钮的单选框。 假设这将中断，我希望会有示例说明如何在Gutenberg中创建此示例，并且在我的代码中断之前，我将有大量时间升级到要求Gutenberg的WordPress版本。

3）我还有另一个metabox，结合了一些jQuery和PHP代码，这些代码会禁用发布按钮，直到做出选择为止。 与我的第二个示例类似，假设此操作将失败，我希望会有示例说明如何在Gutenberg中创建此示例，并且我将花费大量时间升级到要求Gutenberg的WordPress版本。我的代码坏了。

4）我过去已经删除了类别meta框，并将其替换为：1）单选2）一个无法添加新类别的版本（这很愚蠢）。

5）我使用post_submitbox_misc_actions向发布metabox添加不需要在自己的metabox中的选项。

就我所说的相当长的时间而言，我要说距Gutenberg API被冻结大约2年。

在此过程中，我想提醒这里的每个人，并非每个人都仅使用元框来扩展帖子屏幕。 我们中的一些人还使用以下钩子：

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

我只想赞同@mikeschinkel关于edit_form_[POSITION]钩子的内容。 Piklist大量用于meta-box，工作流和其他事物。

再次感谢您的宝贵时间。

无论是对向后兼容性的关注者，还是对开发古腾堡的人来说，古腾堡是替代编辑器还是替换屏幕的问题都必须尽快回答。 这个问题的答案会影响每天做出的有关古腾堡（Gutenberg）工作方式和控制装置位置的许多决定。

自从第一个测试版以来，我们已经很清楚地准备好更换屏幕，但是大修屏幕的决定也是造成meta box支持和缺少钩子的问题的原因。 如果对这些问题的回答是“不更换整个屏幕”，那么我担心在更换屏幕的假设下已经进行了太多工作，将很难返回。

首先，很高兴看到这方面的实际进展。

一种观察是，编辑屏幕扩展很少单独运行。 例如，ACF根据后父选择框上的JS更改事件来更改可见字段。

鉴于DOM在古腾堡环境中会有所不同，而且React可能不太适合外部事件侦听器，我们如何继续使此数据可用于元框和其他插件代码。 一种可能性是Redux存储可供metabox使用，但我不知道这是否可行，是否需要或是否具有足够的灵活性。

当将metabox加载到iframe中或合并到页面中时，这甚至会变得更加棘手。

自从第一个测试版以来，我们已经很清楚地准备好更换屏幕，但是大修屏幕的决定也是造成meta box支持和缺少钩子的问题的原因。 如果对这些问题的回答是“不更换整个屏幕”，那么我担心在更换屏幕的假设下已经进行了太多工作，将很难返回。

我完全了解了“屏幕”更换方法的工作量。 但是，以替换“后期内容编辑器”为目标的项目，在单方面决定替换整个编辑器屏幕之前，不应该回到社区吗？

我并不是要消除已经完成的巨大工作（编辑器看起来确实很棒），但是太多的WordPress依赖于并非严格意义上的“内容”的元字段，并且其中许多内容根本不适合相同的古腾堡容器（除非完全被迫）。 对我来说，似乎更像是“我们有解决方案，需要为此解决问题”，而不是反过来，这就是古腾堡（Gutenberg）的原始声明（内容编辑器很乱，短代码是所有易于使用的东西-尽管使用了Shortcake-等方法）。

从7月4日开始的@brentjett样机似乎可以同时处理不适合内容（“设置区域”）的“重新配置的元框”和可以轻松转换为Gutenberg块的元框（事件信息）。

@rilwis我认为您应该在插件中提到Metaboxes的广泛使用。 由于我在大多数产品中都使用了它，因此我发现它是一个广泛的框架。 它如何适合整个古腾堡的事情？ -某人的业务是出售插件来构建metabox（这将受到最大影响），这在这里很有用。

为了获得设计灵感，您可以检查免费和商业（屏幕截图）后端Admin主题。 或任何其他平台。

仪表板，但想想古腾堡：

提议的Fields API也许可以解决新编辑器中支持元框的一些问题。

我们应该考虑的场景是当用Gutenberg更新WordPress而没有实现元框的插件时发生的情况。

这是“最坏情况”，对打破管理员体验构成最大威胁，但考虑到由元框插件提供支持的站点数量众多，包括知名企业和定制的一次性解决方案，这种情况并不少见。

除非我们愿意承认大规模的重大变化，否则依靠这些meta box插件进行更新不应成为方程式的一部分。 Fields API是一个好主意，但是我们不应该假设将来改进自定义字段的处理方式将对这种API存在之前编写的代码产生任何影响。

很清楚：

• 我们不会大规模破坏向后兼容性。
• 我们不会使用某些检测机制来对编辑器页面进行分叉。
• 我们将拥有单一的编辑和编辑经验。
• 上面有许多用例，当前的Gutenberg实现无法适应。

因此：

前进的道路是以一种包含新旧内容的方式重新思考帖子编辑屏幕。 这很可能意味着以某种方式回溯当前的Gutenberg实现。 这是设计挑战，而不是世界末日。

@dmccan不，这些语句不是“明确的”，因为到目前为止提出的每个解决方案都是：

• 在新旧之间分配管理经验。
• 依靠插件更新来阻止其元框。
• 依赖于不存在的Fields API。
• 要求注销新界面，以完全避免该问题，否则将再次分裂管理员体验。

我没有强调最坏的情况是戏剧性的。 我这样做是为了定义应该解决问题的约束条件。

因此，看来古腾堡（Gutenberg）应该很长一段时间都可以保留一个功能插件，人们可以选择是否喜欢或不选择退出，甚至可以作为核心插件包含在内。

解决它需要具有单一编辑者经验才能解决的所有问题将花费大量的日历时间。 只要看看微软最初的ASP.NET以及它解决一般Web问题的严重程度。 最终，AJAX出现了，剩下的就是历史了。

强迫更改太快可能导致WordPress成为真正的仅旧版平台。

PS“单一编辑器”要求似乎是不现实的。 如果用户可以选择使用旧版本或新版本，则可以允许新版本随着时间的推移而发展，直到使用旧版本不再有任何好处为止。 但是，只要有使用现有挂钩_（我相信）_的安装，使用单个编辑器解决方案是不负责任的。 #jmtcw

@kevinwhoffman-我认为我们同意，但也许我不够详细。

我认为我的要点很明确，最终解决方案将包括这些内容。 例如，尽管人们正在寻找解决方案，但我认为WordPress不会大规模破坏向后兼容性。

到目前为止，尚缺乏建议的解决方案，这是我得出的结论，我们需要重新考虑当前的古腾堡实施方案，以适应新旧问题。我认为这样做确实是唯一的方法。

@mikeschinkel-我不认为Gutenberg将在2017年成为Core中唯一的编辑器选项。它很可能是从用户选择开始的，并发展到涵盖所有基本基础的地步，或者是时候做对了。

无论如何，我的建议是回溯，将古腾堡纳入当前编辑器屏幕的某些升级版本中，而不是丢弃所有内容，然后想知道我们如何处理所有基本功能。 我认为这是可行的，而且一旦人们对此感到满意，那么回溯幅度就不那么大了。 这样的过程可能会更快，并提供更好的最终用户体验。

也许他们（核心编码员）应该和Matt谈谈。 他开始了所有这一切，现在他们没有答案。

@dmccan我认为至关重要的一件事是，无论实现什么，都具有易于扩展的模型。 WordPress以其具有插件操作和过滤器挂钩的易扩展性模型而闻名，没有它，古腾堡（Gutenberg）对WordPress的危害与当前很难扩展的当前媒体管理系统一样。

附带说明一下，尽管我从未使用过React或Vue _（我是PHP开发人员）_关于React的讨论需要构建系统，而且很多人发现Vue比React更易于使用，这使我变得对以下问题感到非常焦虑Gutenburg是否将具有易于学习和使用的可扩展性模型，以及是否意味着我们可以继续将WordPress用于客户项目。

只需我的反馈即可表示我的关注，而无需直接回复。

我想我知道这是怎么回事。
它从不与内容编辑器有关，从不与“编写流程”，“与旧的....向后破坏”等有关。

它是关于全功能的前端视觉主题编辑器。

很抱歉向所有人发送电子邮件。 我对这个特定问题的最后评论。

@Rarst @kevinwhoffman ：我完全编辑器替换还是屏幕替换。 这是一个深思熟虑的观点。 我希望开发团队可以回到古腾堡（Gutenberg）的起点和本质-编辑，并保留其他一切。 它们是2个不同的部分，可以相互使用或不相互使用。 因此，最好将它们分开存放。

另外，我创建了＃2308以列出Meta Box插件中的相关挂钩。

@ahmadawais感谢您的提及。

@nylen值得将Posts 2 Posts添加到要考虑的插件列表中。 尽管不再支持它，但我希望它仍被广泛使用。

@nylen我维护我的插件开发人员的自定义字段，但不再积极开发（这几天我使用CMB2）。 只有1000多个活跃安装，但也许值得添加到列表中。

我同意有关Gutenberg Editor的评论，即内容编辑部分。 不知道为什么或为什么它成为完整的屏幕替代品。 所有流行的页面构建器都可以正确地执行此操作，只需将TinyMCE替换为其他内容即可，使内容的编写更加容易。

同样，元框通常也不是内容的一部分，即使它们与内容相关，它们通常还是没有意义。

以职员目录为例。 我为什么要将人员信息的字段设为空白？ 当他们只应该输入名字，姓氏等时，您不希望他们添加其他块...

tldr; 对于需要内容撰写的帖子类型，古腾堡只应替换TinyMCE编辑器。

只需在这里加两分钱。

为什么不就这样保留它呢？ 我的意思是这个。

• 将鼠标悬停在现在的标题上时，请保留两个编辑选项，但是要对其进行更改，因此默认情况下单击标题将带您进入古腾堡。 然后，将Edit链接转到Gutenberg，将另一个链接转到class编辑屏幕。 也许称其为Classic Edit 。
• 为Post和Page帖子类型添加某种类型的支持标志，因此如果开发人员想要这样做，可以禁用Gutenberg。 如果未启用古腾堡，则将标题链接转到“经典”编辑页面，删除指向古腾堡的Edit链接，然后将Classic Edit链接的文本更改为Edit
• 然后，具有自定义帖子类型的Gutenberg支持如Editor，Featured Image等。这样CPT不必支持Gutenberg。
• 然后更新经典编辑页面的样式。 更新了meta框和侧边栏样式以匹配Gutenberg样式。 甚至像Gutenberg一样，将摘录和评论元框移动到侧边栏。

我认为这会让每个人都开心。 默认情况下，Gutenberg将启用Post和Page帖子类型。 如果开发人员需要使用元框而不是Gutengerg，他们可以使用。 这将使插件和主题开发人员有时间转换到古腾堡，并且使最终用户能够适应古腾堡，而不会因编辑器的更改而干扰他们的工作流程。

这将使开发人员有时间开始将使用古腾堡的想法推销给最终用户。 人们倾向于不喜欢变化。 让他们习惯于新的编辑器将比仅是艰难的改变要好得多。

这也将两者分开，这将允许两种不同的保存方法。 古腾堡可以使用JS，而经典可以继续使用PHP。

我会添加某种类型的警告，例如，如果某个用户使用Gutenberg保存了一篇帖子，然后尝试使用classic对其进行编辑，以使他们知道，如果他们保存了该帖子，它将覆盖其他编辑者对该帖子的先前保存。 可能会有类似post meta的内容来指示最后使用哪个编辑器。

是个主意这可能是一个愚蠢的主意，但我认为这可以减轻许多开发人员所担心的一切。

我完全同意许多人今天对古腾堡的范围提出的观点。 该项目首先作为对内容编辑器的（非常需要的）改进而开始。 通读该线程，我不禁感到我们正在创建不需要存在的问题。 如果我们坚持将古腾堡添加到编辑器中的原始计划（而不是替换全屏显示），那么这将解决很多问题，而不仅仅是与Meta Boxes有关。

通过完全改造屏幕，我担心这会对非技术人员的内容编辑器造成很多问题。 普通的博客作者/作者将看到完全不同的屏幕和恐慌。 如果更新仅针对编辑器，则可以更好地控制入门体验。

解决此问题的另一种方法可能是使用与Beaver Builder相同的工作流。 即保持正常的帖子编辑页面（具有常用的Meta Box部分等），然后可以通过按钮启动Gutenberg。 然后，您可以进入新屏幕。 就像关于以分散注意力的自由写作模式为目标的评论一样。

我也同意建议保留现有元框UI并仅更改内容编辑器的人。

我认为我们大多数人确实认识到推动平台向前发展的主要因素是创新。 显然，WordPress正在缓慢地尝试朝着基于JS的方法发展，以提供可以与他人所做的（并且超越！）相匹配的更丰富的体验。 老实说，整个metaboxes系统和当前的编辑屏幕UI可能都有些过时，但是作为开发人员，我们已经习惯了它，这对我们来说是第二天性，因此我们无法考虑那里的学习曲线是它。

阅读整个线程可以为我澄清两件事：

• 显然，核心团队确实希望推动完全基于js的编辑屏幕，恕我直言，这没关系
• 也许我们都可以接受以上观点，那么我们可以将对话转向传统的支持和迁移策略以继续

一旦我们了解了metaboxs的js版本最终将如何工作（是否存在提议的API？），我们就可以开始考虑如何创建一个使现有技术（插件，字段管理器等）成为桥梁的桥梁。使用这种新方法。

如果已经进行了以API为中心的讨论，那么有人可以指出我以及其他不知道正确方向发生了什么的人吗？ 谢谢！

是否有理由不将编辑器分成两个通过选项卡导航的屏幕？

我认为古腾堡是

• 尝试整理编辑器屏幕
• 尝试向核心添加页面构建器/布局功能
• 通过使开发人员更容易创建新的内容块来最大程度地减少对元框的需求。

如上所述，我们大多数开发人员和最终用户都可以感受到和预见到的问题是，古腾堡（Gutenberg），

• 从作者删除编辑器样式格式选择
• 强迫作者使用非直观的工作流程，该工作流程需要多次单击鼠标才能添加块
• 破坏了许多较旧的插件，其中一些已维护，而有些则未维护。
• 将WordPress转换为Tweet平台。

使用Guttenberg创建内容与在Mautic或MailChimp中设计电子邮件模板具有相同的尴尬之处。 Guttenberg的UI适用于模板设计，但不适用于长篇文章创建。

我们应该专注于增加工作流程的流畅性，而不是引入停止启动内容创建UI。

Guttenberg的UI看起来很棒，但是期望最终用户对它感到满意是不现实的，因为它已经接近当前形式。 它妨碍了内容的创建。

文本块几乎没有用。 文本小部件不应将作者限制为仅使用几种字体格式。 这会惹恼许多作者。

这是我的建议：

• 将Tabify编辑屏幕引入页面编辑器。
• 将metabox移到编辑器屏幕中其自己的页面标签中。
• 将非基于React的页面用于元框（隐藏在编辑器标签后面的页面）
• 使用基于默认TinyMCE（或功能相似的丰富编辑器）的默认画布，该画布适用于长格式，并且不要求作者使用块。
• 将Guttenberg Blocks作为TinyMCE的插件或类似的TinyMCE引入。
• 将Shortcake引入基于TinyMCE的编辑器中，以便作者可以直观地看到块的内容，从而使作者可以直接在页面流中编辑内容，而无需单击每个块的编辑按钮。
• 通过将add_shortcode（）绑定到块创建中，使开发人员可以轻松地向Guttenberg添加新块，例如add_shortcode（'tag'，'function'，'guttenberg true / false'）。 修改add_shortcode，使其自动使该短代码与Guttenberg兼容； 这将使开发人员可以轻松地将他们的一些/许多元框转换为在Guttenberg中可用的短代码。

我真正要说的是Guttenberg需要分解为3个任务：

• 编辑器屏幕清理
• 改进的编辑器用户界面
• 改进的编辑器扩展框架。

我想说大多数人都使用WordPress创建长格式内容，并且不希望被迫使用块来创建其内容。 块非常适合页面布局的创建，但是每次撰写帖子时使用时都很烦人。

我有一个80多岁的顾客。 她只想创建内容。 她不想被迫重新学习如何使用编辑器屏幕。 她花了一年多的时间习惯了Visual Composer，这是一个易于使用的页面生成器。

我已经脱离了原来的主题，但这需要说：古腾堡将杀死WordPress。

如果以目前的形式介绍古腾堡，那么WordPress将被派生，古腾堡版本将消失。

如果您将WordPress用于博客站点并为其创建PHP主题，那么新的编辑器可能更有意义，但是如今，许多人将WordPress作为CMS来使用React，PODS / ACF和WordPress REST API构建Web应用程序。 因此，需要支持元框和“关系”字段以实现CPT之间的高级链接。

首先，我认为古腾堡将会很棒。

话虽如此，我认为我们都可以同意，破坏网站/功能会破坏信任，这并不酷。 我们都希望能够相互信任，而我们的客户/客户希望/需要信任我们。

我认为我们能做的最好的事情是包括一个过滤器，开发人员可以使用该过滤器还原到“旧版”编辑器屏幕。

这样，我们可以运用自己的逻辑来确定我们是否已为古腾堡做好准备。 如果用户使用的元框将在Gutenberg中完全损坏，我们可以选择恢复为旧版模式。

然后，我们可以按照自己的步调来迁移元数据框或想法以适合Gutenberg，同时保持依赖于我们“旧式”元数据框的旧帖子正常运行。

为什么无法将旧版metabox呈现在它们所注册的位置（上下文）并保持其当前的功能？

因此，首先呈现（可选）Gutenberg编辑器部分，然后呈现任何已注册的（旧版）正常/高级上下文元框（具有已注册的标题），然后呈现带有新的“帖子设置”列的侧边栏，并在其下方显示任何已注册的（旧版）面上下文元框（带有其注册标题）。

当然，旧版meta框的样式将与新的Post Settings框一样，所有内容看起来都很好地集成在一起。

也许它将需要legacy-meta-box.php脚本，该脚本将在需要时加载，例如，在调用add_meta_box时。

如果我们仅将当前的元框解决方案视为“旧版”，并要求他们使用旧的编辑器，而无需首先考虑使用它们的原因，然后研究在新的编辑器中提供该功能的更好方法，那么当前的站点将保持原有状态，并且永远不会升级。 对于那些管理客户端站点的用户来说，这将是一个巨大的问题。

我们几乎在所有项目中都使用ACF字段的原因是为了控制数据，使其始终显示在网站上。 这是我们目前正在研究的两个示例； 一个大型活动站点和一个带有作品/装置的节日，需要与艺术家链接但单独显示。 在这两种情况下，古腾堡将要替换的“内容”部分仅占编辑屏幕上内容的10％，实际上是最不重要的部分。 对于事件站点，重要数据是事件类型，事件类别，日期，时间，位置，组织者等。您可以发布有意义的事件条目，而无需在编辑器中输入任何内容。 对于节日网站，我们需要能够选择一个艺术家并将其链接到作品，在节日网站上选择作品位置并上传特色图片，同样，内容不是必需的。 对于这些网站上的所有“常规”页面内容，古腾堡都不足够灵活（我也不相信默认情况下也不应该是默认的），我们将继续使用功能更全的页面构建器（Beaver Builder），以取得更好的效果设计选项。

所有这一切中的另一个关键因素是内容在编辑屏幕上的顺序。 对于事件，您需要这样设置标题，但是在理想的编辑流程中，您需要在输入“编辑器”中的任何“内容”之前输入一些关键信息，例如日期，时间等。 我们必须能够控制内容在编辑页面中“内容”之前或之后的位置。

仅创建带有所有“旧版”元框的另一个选项卡的想法将是可怕的。 对于CPT的许多用途，这将完全打破编辑流程，以一种我认为他们很难发现的方式向用户隐藏内容。

该项目需要对此更加明智。 如果可以选择（在某种页面模板中）哪个选项卡上的哪些位，则选项卡式过程可能会很好用。 您还需要一种机制来使用户逐步浏览每个标签。 但是，我也认为，对于较短的CPT项，您必须能够将其全部保留在一页上，且某些关键元素要高于编辑器内容（如果需要，则为必填项）。

人们正在谈论的所有大多数解决方案似乎都没有当前编辑屏幕的灵活性。

这就是为什么我为此担心5.0的时间表，感觉时间可能很棒，但是如果匆忙解决，碎片化将破坏开发人员和客户的所有善意。 WordPress是以其灵活性，向后兼容性和一般用户友好性为代价的。 我们不能为新的闪亮玩具而牺牲它。 看一下WordPress的PHP要求，实际上是在要求PHP 5.6或7之前的几年。 社区已经认识到，无论多么漫长的时间长短令人沮丧，都必须不要破坏网站。 这不是完全一样的问题吗？

像这样的更改，尽管最终它们对于平台将非常有用，但必须进行周密的考虑和管理，否则将冒着建立WordPress的基础的风险。

@avocadesign-一些好处。 我们现在可以注册JavaScript元框，尽管目前的想法是要有两个位置……这并不像您提到的那样灵活。

@avocadesign-很好解释。 post_content并不总是发布的重点，您的“事件和艺术家”就是一个很好的例子。 很高兴看到一些屏幕快照显示这些帖子类型的后端和前端，因此我们可以帮助开发人员可视化WP如何用作CMS，以及典型的客户端如何通过帖子编辑屏幕工作。

@avocadesign

如果我们仅将当前的元框解决方案视为“旧版”，并要求它们使用旧的编辑器

在我的建议（在您的意见上方）中，“旧式”元框位于Gutenberg编辑器下（如果需要职位类型）或Post Settings块下（取决于它们所注册的上下文）。 我认为保留旧的编辑器没有任何要求。

我同意选项卡式界面不起作用。 您如何看待我的建议。 正如我所看到的，它将为您提供您所习惯的所有灵活性，并允许您在准备就绪时移至新系统。

如果Gutenberg成为核心的一部分，您将能够为您提到的示例构建更好的UI。 它的一部分将包含一个或多个（基于JS）“帖子设置”部分中的自定义节块（所见即所得的形式）和相关设置。 用户将从直接反馈更快的界面中受益。

WordPress是以其灵活性，向后兼容性和一般用户友好性为代价的。 我们不能为新的闪亮玩具而牺牲它。

我不同意。 我认为您应该给古腾堡更多的荣誉。 他们正在努力开发一种适合所有人的解决方案。 他们正在倾听并寻找用例（就像您提到的用例一样），但还没有定下来，Gutenberg的“可能”发行版也不是其中的一部分。
如果Gutenberg不能解决当前正在讨论的所有问题，您可以相信它不会成为5.0版本的一部分。 我们已经看到，过去也有其他功能发生过多次。

这是我使用“高级自定义字段”为管理酒店物业的客户构建的界面示例。

• “属性”自定义帖子类型在10个标签中使用18个自定义字段。
• 选项卡将所有相关信息保存在一个屏幕上，单击按钮即可让编辑者访问。
• 字段类型除了ACF画廊和关系字段外，还包括简单的文本和数字字段。
• 在自定义帖子类型注册中未声明对editor支持，这意味着整个UI都依赖于自定义元框。

这种类型的UI代表了许多自定义WordPress网站，其中一系列自定义字段包含页面内容和用于组织帖子的“不可见”元数据的混合。

引入Gutenberg后，社区需要知道这种类型的界面会发生什么，我不认为要求@elliotcondon及时将其全部迁移到React以便启动是现实的期望。

@kevinwhoffman

引入古腾堡后，社区需要知道这种界面会发生什么

没错，但是此问题＃952的目的是通过讨论和建议替代方案来找到答案。 什么会工作，什么不会。 在将来的某个时刻，当每个人都认为我们都想到了可以在所有旧有和将来的情况下工作的东西时，只有这样才能实现它，并且（用户）社区可以解释它如何工作。 目前，期望团队回答IMHO问题还为时过早。

我认为您提供的用例以及@avocadesign提供的用例将极大地帮助团队。

关于您的示例，我的建议（请参见上面的一些反应）将仅显示屏幕截图中所示的所有框（当然使用新的Gutenberg样式）。

@kevinwhoffman

Gutenberg很可能会选择加入CPT，就像您的CPT不声明支持当前编辑器的方式一样。 我不明白为什么不选择CPT，因为WordPress中的大多数功能都非常灵活，古腾堡（Gutenberg）也没有什么不同。 目前仅适用于帖子。

我非常怀疑古腾堡（Gutenberg）会为这样的界面进行任何更改，也不打算这样做。 话虽如此，探索古腾堡的产品并看看是否可以通过使用它为客户创造更引人注目的编辑体验可能会很有趣。

例如，您可以创建一个属性/属性块，该属性块可用于允许您的客户将属性信息快速，轻松地嵌入到其他帖子等中。 然后，在Gutenberg中进行编辑时，他们可以更改在ACF中看到的相同信息，同时查看在Gutenberg中显示的属性信息。 古腾堡并没有超越WordPress的管理界面，它正在取代编辑器的功能，并且很可能会导致基于块的内容模板。

好事来自古腾堡，而不是头痛！

这是上述站点的事件编辑屏幕，其中ACF字段位于post_content上方，然后是Events Calendar标准元框，位于post_content下方。

该网站将向许多非技术用户开放，我们不是在谈论训练有素的编辑团队，我们是在说乔·乔普（Joe average），除了我们在网站上提供的帮助外，他从未使用过WordPress，也从未接受过培训。

我们以这种方式进行设置，以确保用户找到并输入每个事件的事件类型，类别，标题和特色图像。 我们还可以使用现有的meta框位置在屏幕上提供相关的帮助文档，以帮助他们编辑事件并以非侵入性的方式向新用户提供支持。

另外请记住，我们以管理员身份登录，非管理员用户隐藏了各种侧边栏元框，以进一步减少他们看到的视觉混乱。

“内容”与成功进入事件的各种元框几乎不相关。 如果未正确输入日期或未选择类别，则事件不会在网站上显示。 让我担心整个讨论的事情是类似问题＃1352的模型，其中元框被放到可折叠部分的屏幕底部。 我可以根据我们的经验向您保证，我们将使未经培训的用户永远不会看到meta框，只需将日期和位置直接输入为纯文本形式的内容区域，然后抱怨他们的事件未在系统中显示。 对于未经培训的用户而言，对于需要结构化信息的帖子类型而言，它的发现性不足。

同样，我们在此界面中也有必填字段，如果meta框折叠，则用户将收到警告，但无法轻松找到问题的原因。

元框或其功能类型的下一个迭代必须是一流的公民，我们需要能够将其放置在内容上方，内容旁边或内容下方，以便为客户提供可用的界面。

Gutenberg很可能会选择加入CPT，就像您的CPT不声明支持当前编辑器的方式一样。

在CPT中注册对Gutenberg的支持尚未得到证实，说实话，这更像是避免出现meta框问题而不是解决它。 如果现有站点访问Gutenberg的唯一方法是通过代码注册对它的支持，那么它将严重限制潜在的受众。

我们也不应假装自定义元框仅用于自定义帖子类型。 它们很可能存在于常规帖子和页面上。

古腾堡（Gutenberg）并没有超越WordPress的管理界面，它正在取代编辑器的功能...

这是不准确的。 就像今天一样，古腾堡（Gutenberg）是帖子编辑屏幕的全屏替代。

@ BE-Webdesign和@kevinwhoffman

还有，为什么CPT不得不错过明显优于当前编辑屏幕的Gutenberg方面？

将发布控件移到顶部，使它们与内容不会混淆，并且更简洁的整体外观绝对是该项目前进的重点。

由于没有合适的计划来创建与当前具有复杂需求的CPT（通过元框）所具有的功能相当的功能，因此我们忽略了很大一部分用户，而将他们归于第二类，最终获得了不受支持的体验。

恕我直言，简直糟透了。

我什至都不在争论元框是否需要开箱即用。 可能会有一种新的更好的方法来实现这种接口灵活性。

我担心的是，对于许多开发人员而言，在这里强制采用“ post_content”优先方法实际上并没有解决很多问题。 除了需要结构化数据输出的CPT外，我们在所有站点上都使用Beaver Builder。 古腾堡（Gutenberg）就是一种页面构建工具，非常适合具有个性化内容需求的帖子和页面。 对于结构化数据来说这很糟糕。 对于结构化数据，接口一致性，必填字段和其他布局优先级每次都比无格式表单内容重要。

@kevinwhoffman

我们也不应假装自定义元框仅用于自定义帖子类型。 它们很可能存在于常规帖子和页面上。 这是不准确的。 就像今天一样，古腾堡（Gutenberg）是帖子编辑屏幕的全屏替代品。

是的，但是它并不能代替我所指的整个管理界面。 您正在将一个不完整的项目与当前的经验进行比较。 ＃2251完成后，将重新引入全能的meta框，因此不会有太大的不同，并且会更好。 某些插件作者可能需要进行某些调整，但是在大多数情况下，我相信一切都会顺利进行。

@avocadesign

还有，为什么CPT不得不错过古腾堡方面明显优于当前编辑屏幕的方面？

没有人说我知道吗？ 添加对CPT的编辑器支持与添加对块编辑器的支持之间并没有太大区别。

由于没有合适的计划来创建与当前具有复杂需求的CPT（通过元框）所具有的功能相当的功能，因此我们忽略了很大一部分用户，而将他们归于第二类，最终获得了不受支持的体验。

我认为已经制定了一个不错的计划，也许还不清楚，但是我非常有信心古腾堡将满足绝大多数所有类型用户的需求，甚至可以说是做到了。

没有人说我知道吗？ 添加对CPT的编辑器支持与添加对块编辑器的支持之间并没有太大区别。

我担心许多人在选择让古腾堡加入CPT的过程中所谈论的步骤将导致古腾堡在中短期内忽略许多当前的复杂用例，并有效地迫使诸如事件之类的用例上面说明的一种方法可以使用现有系统，因为Gutenberg不够灵活。 这有效地迫使那些当前复杂的用例错过了项目的其他优势。

我们经常被告知“别担心，那会没事的”，但是@ BE-Webdesign在您对我们中的某些人建议根本没有明确提出该计划时是正确的，我只是看不到所有这些在短期内将如何令人满意地解决-如果可以随时指出讨论或问题以启发我。

编辑：
我所说的“短期”是指向公众发布5.0，这似乎是2018年初的目标。 在2到3年的时间里，我可以看到这个解决方案更加成功。

@BennyVL ＆ @dmccan灵活性是这里的关键问题。 如果我错了，请纠正我，但是从事此工作的开发人员所提出的建议都没有我们现在所拥有的灵活。

使用ACF和其他插件，我可以轻松地在内容上方（标题下方），内容下方和侧边栏中注册元框。 界面的设计由我决定。 它并没有强制要求编辑器是第一个，也不要求编辑器必须存在。 我可以注册新的metabox，也可以注销或移动其他metabox。

我想要的是一种可以长期保持这种灵活性的解决方案。 是否需要将元框更新为闪亮的新JS格式，变为适当的块或需要进行其他更改以使这种可能性成为可能，这实际上并没有困扰我。 我希望古腾堡（Gutenberg）拥有我们目前享有的灵活性，而无论到达那里的方法如何。

我想要的是一种可以长期保持这种灵活性的解决方案。 是否需要将元框更新为闪亮的新JS格式，变为适当的块或需要进行其他更改以使这种可能性成为可能，这实际上并没有困扰我。 我希望古腾堡（Gutenberg）拥有我们目前享有的灵活性，而无论到达那里的方法如何。

这是目标，也是大多数人想要的。

我已经听过很多有关meta box问题以及使用此新编辑器会发生什么情况的讨论。 我个人认为Gutenberg应该只关注编辑器，而不是整个页面编辑屏幕。 但是似乎已经做出了决定。

嗨，大家好，

我是Carbon Fields的首席开发人员，想添加我们可能会受到影响的操作/过滤器的列表：

筛选条件：

• postbox_classes_{$page}_{$id}

动作：

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title （定位糖-不重要）

我的问题：

• 如果我们要保留旧版元框，它们将如何与数据更改交互？
• 什么类型的事件（jQuery？发射器的某些公开实现？）以及我们可以期望新编辑器提供哪些事件（例如，提交成功，失败等）？
• 这些事件是否可用于旧版元框或仅可用于React实施？

PS：
我只想感谢古腾堡（Gutenberg）团队的辛勤工作和努力，这让我感到兴奋的是WordPress正在朝着现代化的工具和解决方案迈进（即使这段旅程看起来很可怕）！

支持元框非常重要...

...适用于成千上万的wordpress开发人员和用户。

WordPress不能忽略大插件播放器...

...例如Advacend Custom Fields Pro（https://github.com/elliotcondon/acf/issues/622)、WooCommerce或Yoast SEO。

我负责Toolset项目，该项目大量使用自定义类型，字段和分类法。

我们希望使我们的插件与Gutenberg兼容。

这是我的理解：

• 当他们使用古腾堡（Gutenberg）时，我们将需要使用新的API在页面和帖子上显示自定义字段和分类法。
• 我们不需要针对CPT的Gutenberg做任何事情，因为它们将使用普通的WordPress编辑器而不是Gutenberg。

这个对吗？ 如果是这样，您能否请我参考在古腾堡（Gutenberg）显示自定义框的API文档？

我认为文档仍在不断发展。 https://github.com/WordPress/gutenberg/tree/master/docs上有一些文档//gutenberg-devdoc.surge.sh/

我听到@ BE-Webdesign和其他人在谈论将中断最小化的意图-谢谢，这令人放心-但只想增加我的5便士的价值（好的，好的，我通常的105便士的价值。）

任何已经开发了一段时间的人都将记住为定制数据库手动创建Web界面的痛苦-无聊，耗时，容易出错并且在开发人员时间方面非常昂贵。

WordPress加上高级自定义字段（Pro）是一个有效的工具，可以有效地创建具有吸引力的前端，严格的数据输入检查，直观且一致的用户界面等的定制数据库驱动的网站（甚至是Intranet数据管理工具）。这些系统可能无法具有海量的关系数据可伸缩性，但是在很多情况下，它们并不需要如此。 这些都是简单的系统，可以为客户创建具有成本效益的方式。 这就是使WordPress真正有用的CMS（实际上是轻量级的RDBMS），而不仅仅是博客平台。

我（而且我敢肯定，还有许多其他）小型企业使用WP + ACF（或类似的自定义数据插件）来为客户组织和IT预算不高的个人创建定制的站点和系统。 如果在没有适当考虑支持现有编辑/数据输入流，元框等情况下进行古腾堡（Gutenberg）的介绍，那么我有两个“非技术性”但仍然很重要的问题：

1 /我的最终用户将需要重新培训（对于技术人员来说，这很容易让我们忘记通过界面更改可以使大量非技术用户感到困惑-我写了Clarify Password Reset插件，因为我浪费了太多时间进行整理用户完全被4.3中引入的新密码重置过程所困扰。

2 /除了为不同的metabox方法升级自己的插件外，我还必须花时间以专业的勤奋程度升级和测试我所有的客户站点，并确保我使用的所有第三方插件使用还设法正确更新了他们的代码库。 （而且在这种情况下，我无法控制第三方插件的更新速度，无论是在5.0版本发布之前还是在更新之后（甚至更糟），因此工作负载规划变得非常困难。）

在上述两种情况下，我都认为向客户收取更多额外工作的费用是正确的； 毕竟，我选择了用于构建其站点和系统的平台，但这并不像他们要求进行任何更改或改进一样。 在这方面，也许我“太好了”或天真，但正如人们在上文中提到的那样，这是一个信任问题。 我们相信WordPress不会因为破坏向后兼容性而让我们陷入困境，因此我们的客户可以相信我们不会因为意外的额外费用而fees害他们。 最终结果是，我突然有了大量额外的无薪工作，以某种方式适应-如果立即通过升级主动破坏站点，则可能会急需-同时继续进行足够的有薪工作以维持生存。

我真的很喜欢使用WordPress，并投入了大量时间来学习绳索，开发自己的方便项目框架等，以至于现在我可以通过基于WordPress的开发项目来谋生（并养活家人等）。 我还尝试通过花一些时间来正式发布我在WordPress.com上开发的有用的小插件，以回馈他人，因为我重视OSS，基于社区的开发等。我想这主要是为了解决这个问题在本期杂志中尽可能多地提及否则，我同意代码库可能存在真正的危险。 作为WordPress的粉丝和插件贡献者，我认为这确实是一个糟糕的结果。 但是，作为依靠WP谋生的独立开发人员，出于经济上的必要，我可能不得不使用分叉（即适当向后兼容）的版本。 请不要让这种情况发生！

@konamac提出了一些要点，其中一些我已经在其他线程中发布了。

为了支持这一点，对于元盒的未来不给我们一个令人放心的答案是完全不可接受的。

1. 对于现有元框的未来支持，没有直接的答案。 对于开发机构和主题/插件作者来说，这是一个极其令人沮丧和沉重的举动。 “古腾堡是开源的，所以自己弄清楚”是不负责任的。

2. 古腾堡很棒。 我喜欢界面，视觉设计，而且我确实认为这是未来编辑内容的方式。 但是，对于考虑将其用于4.9或5.0版本而言，它远远落后于所需的位置。

3. 我应该能够在遗产中做的一切就是我在古腾堡中应该做的一切。

4. 屏幕选项
5. 元框（ACF，Yoast等）
6. 永久链接？ 我什至无法理解为什么在1.0中还不能对此进行编辑
7. 经典内容块无法在本地主机环境中正确加载
8. 文档必须是创建不同样式块的关键。 举几个例子，几个用例。 并非每个主题开发人员都是后端，因此请不要假设。 清晰明了
9. 阻止设置需要工作。 很难说出每个块可用的设置。 似乎是随机的。 什么时候需要编辑块设置，什么时候不需要？
10. 古腾堡周围的文本编辑器，整个注释标签是......悲伤地看到。

我们中的一些人对此过程感到非常沮丧。 这应该是一个死定的简单答案。

古腾堡（Gutenberg）是否会保护当前使用的metabox / ACF，并且有计划无限期地确保这种支持吗？

我们不需要知道现在的解决方案是什么-我们知道您正在解决它。 但是我们对此还没有明确的答案。 特别是，ACF需要以完全相同的方式工作，即始终支持那些不同意收取更新费用的老客户-尤其是在某些时候讨论删除旧版编辑器时（您现在怎么能开始进行对话？！）。 ）

爱古腾堡。 但是我必须参加合唱团-这太荒谬了。 项目团队传达此期望的方式并不简单。 是或否是我们正在寻找的全部。

@ BE-Webdesign

完成后，将在其中引入全能的元框

因此，我可以建议您就此问题写一整篇文章，实际上您已经表明，请保留现在的元框。 这样可以避免社区中许多担心自己的业务的开发人员。

另外，我鼓励团队优先考虑现在添加这些。 我敢肯定，这将避免整个项目的负面影响。

如＃2308中所述，我复制了创建/保存自定义字段时Meta Box插件使用的钩子：

• 脚本，样式使用admin_enqueue_scripts 。 我们确实检查了当前屏幕（通过get_current_screen ），以确保只为该页面排入脚本和样式。 对于核心插件，它将按帖子类型进行检查。 对于扩展名（术语元，用户元数据，设置页面），它将检查更多分类法，用户个人资料页面或设置页面。
• 我们还使用print_media_templates打印下划线模板。
• 我们在插件中使用的脚本包括：颜色选择器，下划线，主干，媒体脚本，tinymce（用于编辑器字段）
• 我们使用init初始化插件的所有钩子。
• 使用add_meta_boxes钩子注册元框。
• 隐藏的meta框使用default_hidden_meta_boxes 。
• 我们还挂钩到post_edit_form_tag以允许上传文件。
• 我们使用save_post_{$post_type}和edit_attachment ， add_attachment保存帖子和附件的元值。

建立钩子以在古腾堡上方/下方/侧边栏显示元框有什么问题？

我想我也可以做第三方开发人员做得最好的事情，并在工作中投入更多精力。

Mattias告诉我们，元框可以重新想象为存储在post_meta中的块。 如果这是合并的目标，那么有一些问题需要解决：

许多元框为此注册了the_editor($custom_id);以便在古腾堡的上下文中受支持，或者从一开始就需要用于创建嵌套块的接口和api，或者我们说元框只能具有第二类编辑器接口，没有任何积木的好处。 对于目前使用ACF灵活布局进行设计的大量代理商而言，这将尤其成问题，因为它们将需要一种方法来为各种环境和领域创建单独的Gutenberg块。 即使是“按块思维”，我也没有一种解决“内容区域后跟模板部分后跟内容区域”问题的好方法，而从第一天开始就不支持在“元块”中嵌套。

以此为出发点，是对未存储在post_content中的块进行嵌套的技术问题。 Mattias说块将能够存储到postmeta，但是如果一个块可以定义存储在postmeta的位置，那么当父块存储到postmeta时，嵌套操作将如何进行，并且用户将一个子存储到另一个post_meta ... （或者在病理情况下，Tha存储到postmeta的嵌套块包含一个存储到相同postmeta字段的块。

这导致了第三个metabox问题。 如果Gutenberg是完全编辑页面的替代品，而不是the_editor()的替代品，人们将如何能够在其他页面和其他上下文（例如使用the_editor()框或自定义管理面板）中排队和使用块

如果给用户提供古腾堡（Gutenberg）选件的权利，并且对他们来说如所声称的那样具有革命性，则在这些情况下无法提供新界面可能会对代理商造成灾难性的影响。

对于现有元框的未来支持，没有直接的答案。

我反复说过，我们将考虑元框。 唯一的不确定性是什么在技术上可行，以及如何在新UI中显示。

我们没有试图破坏任何东西-短代码，自定义字段等-都应该仍然有效。 与它们进行交互的UI可能会发生变化（除非您完全禁用Gutenberg），并且元框的某些用例将更适合向前发展的块。

古腾堡很棒。 我喜欢界面，视觉设计，而且我确实认为这是未来编辑内容的方式。

我很高兴听到！

永久链接？ 我什至无法理解为什么在1.0中还不能对此进行编辑

因为REST API尚不支持此功能。 欢迎任何帮助： https :

我反复说过，我们将考虑元框。

@mtias我认为关于支持从@m这表明传统的插件将可以恢复现有的功能元盒结果的混乱。 阐明现有接口的哪些方面（元框，元框位置，挂钩等）将继续与Gutenberg一起使用，以及哪些方面需要旧式插件才能继续工作将是有帮助的。

我反复说过，我们将考虑元框。

@mtias致歉，我一定错过了其他地方的澄清。 很高兴听到！ 使当前的迭代在视觉上更具吸引力和针对性，这将是巨大的成功。

我了解您在说什么有关REST API的支持，我将观察该线程是否有更新。

谢谢您的澄清。 现在，有了这种洞察力，我就全速前进了古腾堡（Gutenberg）-我的所有恐惧都被搁置了。

@kevinwhoffman是的，我认为问题的核心是“现有功能”也包括演示文稿，并且由于Gutenberg大大改变了UI使其恢复为上一个界面，因此需要禁用该插件。 正在努力解决元框如何适应新UI以及如何在不经过开发人员干预的情况下支持旧元框的问题。 我不知道具体如何解决，所以我无法保证具体的结果。 我还认为，这可能最终可以使元框功能更清晰地呈现出来。

@brograhamer无需道歉，这是一个很大的

我目前正在使用ACF构建具有10种不使用tinymce编辑器的自定义帖子类型的Web应用程序。 我正在使用“标题”功能和每个CPT平均约15个ACF字段。
当前，您可以声明CPT支持哪些功能（即编辑器，缩略图，摘录等）。
是否可以从编辑屏幕中隐藏/删除“写故事”段落块以及“插入块”图标？

@ cr101我认为，如果您从CPT支持中删除“编辑器”，我们可能应该删除块插入器和来自Gutenberg的块，对我来说似乎很合理。

另一方面，使用metabox的v1版本，可以从底部扩展metaboxes窗格，如果我们保持此状态，则应确保在没有“ editor”支持的情况下CPT始终处于“打开”状态。 如果元框始终显示在编辑器下（例如上面的一些设计建议），则可能没有必要。

我不确定这是否是正确的选择，但是核心自定义元字段呢？ 关于第三方插件的讨论很多，但是关于核心自定义元字段呢。 我知道这些工具并没有那么受欢迎，但是我可以想到一些我使用它们的网站。

是否有计划将核心自定义元字段集成到Gutenberg？

嗨@jawittdesigns ，

我很确定核心元框（至少其中的大多数）已经在古腾堡中重新实现了！ 它们在处理分类法等方面具有一些更好的工作流程。

并非每个人都使用WordPress进行博客撰写。 我们许多人将WordPress用作CMS。 我们目前正在使用WordPress REST API和ACF构建网络应用。 我们有10种自定义帖子类型，每个CPT都有20个自定义字段，并且所有CPT都使用ACF Relationship和Post Object字段以及ACF Post-2-Post插件通过双向关系相互链接

古腾堡（Gutenberg）对我们当前的形式没有用，因为我们甚至不使用当前的编辑器。 我们仅将标题文本框用于CPT，其余的是自定义字段，这些字段存储在post_meta表中。

我坚信古腾堡（Gutenberg）编辑器不应成为当前状态的核心部分。 我认识到WordPress作为一个项目需要对那些没有使用自己的自定义主题的网站建设者起到一定的作用……但是，古腾堡（Gutenberg）编辑器似乎是对我们这些使用高级自定义字段进行复杂内容输入的人的直接攻击为网站所有者提供了一种非常具体的输入内容方式，从而为网站所有者提供了“白痴证明”。 古腾堡（Gutenberg）编辑器的当前状态似乎是对我们这些使用ACF的人的直接攻击。
使用Gutenberg插件，标题中的编辑链接会将用户直接发送到Gutenberg界面，该界面不显示任何ACF元框，并且在屏幕顶部没有用于激活它们的屏幕选项选项卡。 是的，用户可以返回页面/帖子数组并选择“经典编辑器”选项，然后看到元框，但这意味着站点编辑器需要采取额外的步骤才能访问ACF字段。 考虑到在许多情况下使用ACF的目的并不是使非技术编辑人员更轻松，更直接地对复杂布局进行编辑，因此这并非最佳选择。

这是一个长期存在的问题！

随着＃3345和＃3554的合并，对元框的支持已处于一种状态，我们很高兴将其称为_feature complete_。 请注意，这与_complete_不同，因为显然仍需要完善元数据框体验，尤其是在样式，更复杂的JavaScript处理以及确定退回经典编辑器的规则方面。

感谢所有积极参与此问题的人，我确实知道这是一个困难且有时引起争议的过程。 有关古腾堡如何处理元盒以及如何（如果您愿意）将元盒标记为与古腾堡不兼容的文档，请参阅手册。

如果您遇到与特定插件或元框相关的错误，请打开一个新问题，以便可以对其进行正确跟踪和修复。

相对而言，这离功能的完善还很遥远。

@coffeeneed如果您想成为具有建设性的人，请打开一个新的杂志，其中有足够的详细信息，以帮助我们。 谢谢