Gutenberg 尊重 CPT 声明的编辑器支持，如果不受支持，则不会加载。

如果这意味着 Gutenberg 根本不加载，而是使用 Classic 编辑器，那么这将使我们走上一条分裂的 WP 管理员之路，该 WP 管理员分为 Gutenberg 和 Classic 环境。 这在很多方面对 WordPress 都是不利的。

• 新用户必须了解两种类型界面的主要区别和细微差别。 像发布帖子或更改为文本视图这样简单的操作在 Gutenberg 和 Classic 编辑器中的工作方式不同。

• 现有的开发人员将被迫在这两种环境中维护他们的主题和插件的功能。 我们不是在谈论过渡期； 我们正在无限期地交谈。 旨在扩展任何帖子类型的插件将受到最大影响。 如果这些开发人员最终将他们的元框转换为块，那么他们仍然必须维护旧的元框，以防有人在非古腾堡帖子类型中使用他们的插件。

• 进入 WordPress 开发的新插件开发人员必须学习如何以两种不同的方式构建插件。 假设他们包含 Gutenberg 块，他们的插件功能甚至可能无法在使用 Classic 编辑器的帖子类型中使用。

尽管我相信我们必须让元框工作，但从长远来看，简单地关闭古腾堡并不是最好的解决方案。

如果这意味着 Gutenberg 根本不加载，而是使用 Classic 编辑器，那么这将使我们走上一条分裂的 WP 管理员之路，该 WP 管理员分为 Gutenberg 和 Classic 环境。

在 CPT 根本不想启用编辑器的情况下，这似乎是前进的最佳途径。 它只是一个不同的管理视图，针对不同的体验进行了优化。 （例如，来自 Woo 的“订单”视图。）尝试在 Gutenberg 上下文中呈现这些对任何人都没有帮助。

它类似于定制器的出现——它是一种新的界面范式，在不同的上下文中做一些相同的事情。 我们总是需要一个“管理”界面和一个“编辑”界面。 通过阐明接口的不同目的，这就是我们前进的部分方式。

但是由于 Gutenberg 的范围蔓延，它不仅仅是启用或禁用编辑器的类型。 由于古腾堡现在决定了整个编辑界面，因此有一整套与我上面列出的编辑器类型相关的副作用。

我们总是需要一个“管理”界面和一个“编辑”界面。

这些正是编辑器和元框今天所扮演的角色。 它们不是孤立的体验。 他们一起工作。

那么也许应该解决范围蔓延问题，并且应该将古腾堡限制在wp_editor()填充的区域内。 它肯定会解决许多兼容性问题。

范围蠕变

解决范围蠕变是我的偏好，也是我们许多人在过去几个月中一直呼吁的事情。 这样做将使我们能够在不拆分管理体验的情况下改进编辑器。

为每个帖子类型启用古腾堡

关于禁用每种帖子类型的古腾堡的能力，我想强调的是，避免问题与找到解决方案不同。 为每个帖子类型切换古腾堡可能会避免某些插件的元框不兼容，但从长远来看，它会损害 WordPress 的格局。

如果你不明白为什么，想象一下在 Gutenberg 被合并后两年后进入这个行业的新插件开发者。

• 作为开发人员，您将插件 UI 编写为块还是元框？ 如果你想支持所有的帖子类型，你必须把它写成两者。
• 当用户搜索插件时，他们是否知道您在插件页面上承诺的功能仅适用于支持古腾堡的帖子类型？ 当他们发现不能与 Classic 编辑器一起使用时，他们会感到失望吗？
• 当同一用户联系您寻求支持时，您是否知道他们是在询问您的插件在 Classic 编辑器还是 Gutenberg 编辑器中的工作方式。 那个客户甚至知道其中的区别吗？
• 当您想在发布几个月后添加功能时，您是否愿意增加开发时间以将该功能构建到 PHP 元框和 JS 块中？

当我们继续使用两个编辑器并且在 UI 中没有通往奇点的道路时，这些只是一些混淆景观的问题。

show_in_rest

当show_in_rest未设置时，帖子不能使用 Gutenberg 的事实只是影响编辑体验的无关功能的另一个例子。 我对 REST API 中公共帖子可见性的偏好没有理由会影响我在编辑时使用的界面。 我理解技术原因，但逻辑不存在，我怀疑许多开发人员甚至不知道这是此时的限制。

古腾堡如何超出 wp_editor() 参数的范围仍然让我感到困惑。 如果古腾堡“编辑器”被限制在 wp_editor() 中，那么每个帖子类型的“启用作为选项”将成为现实，并且在未来更易于管理和扩展。 我仍然没有看到关于为什么 Gutenberg 范围蠕变不能缩小而只能包含在 wp_editor() 中的合理解释。

为不使用编辑器且不直接显示在前端的自定义帖子类型启用古腾堡是没有意义的。

我见过各种网站，其中 CPT 不仅用于真正的帖子类型，而且还用作为各种设置和元素创建管理界面的方法。

例如，我工作过的一个作者网站有“书籍”和“商店链接”的 CPT。 让古腾堡担任图书列表页面的编辑绝对是有道理的。 但是“商店链接”没有自己的帖子或页面，而是用于为每个“书”页面上的在线书店链接提供逻辑。 图书页面模板显示与区域（例如英国、美国）和格式（例如电子书、印刷品）相匹配的产品页面的商店链接，将存储在帖子元字段中的 ISBN 插入每个在线商店的 URL 结构中 - 请参见屏幕截图。

CPT 可能不是管理此类数据和设置的最佳方式，但有许多网站使用无编辑器 CPT 和自定义元字段将各种功能连接在一起 - 我可以提供此类用法的其他示例。 强迫古腾堡编辑器使用根本不使用该编辑器的 CPT 会令人困惑和适得其反。

为不使用编辑器且不直接显示在前端的自定义帖子类型启用古腾堡是没有意义的。

不，这没有意义，但只要 Gutenberg 是全屏替代品，那么包含或排除 Gutenberg 的决定会产生更大的影响，超出了您是否希望在帖子类型中使用编辑器。

例如，假设您是一名插件开发人员，并且您希望您的“商店链接设置”元框在一种使用 Gutenberg 的帖子类型和另一种不使用的帖子类型中可用。 当您将插件分发给希望它与任何帖子类型一起使用的数千名用户时，您没有选择的余地。 这就是https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663 中提到的问题发挥作用的时候。

值得重申的是，在它们自己的帖子类型中隔离的元框受古腾堡影响最小，因此我们必须考虑它如何影响跨帖子类型提供服务的插件功能。

是的，我可以看到插件必须同时支持古腾堡和非古腾堡接口将是一个主要的持续问题

我想问题就变成了古腾堡应该如何处理不支持编辑器的 CPT——古腾堡如何在从块构建页面没有意义的上下文中运行，它只是元驱动？

... Gutenberg 应该如何处理不支持编辑器的 CPT - Gutenberg 如何在从块构建页面没有意义的上下文中运行，它只是元驱动？

如果 Gutenberg 要缩减并且只替换我在https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018 中提到的 Yoast 概念中的编辑器，那么启用或禁用 Gutenberg 就变得非常简单了。

• 如果启用了editor ，则块编辑器存在并且元框可以出现在其上方或下方，具体取决于所使用的钩子。
• 如果editor被禁用，则块编辑器不存在，元框向上滑动成为帖子类型的主要界面。

这基本上就是它今天的工作方式，并且通过保持这种行为，它将允许插件在有意义的情况下逐渐将元框转换为块。 它还可以避免上面列出的许多与拆分管理体验相关的令人困惑的问题。

我发现“范围蔓延”是一个使用起来很奇怪的术语，考虑到启动职位和项目收到的祝福。 自 1 月 11 日我们开始讨论和研究如何从整体上改善编辑体验以来，已经在公开场合完成的工作让人感到轻蔑。 没有任何事情发生在我们身上，这一直是计划，这就是为什么没有固定期限的重点。

尽管如此，我想谈谈设计的角度，以及为什么我觉得设计编辑器的重点只是替换内容区域会是一种可笑的妥协体验，只是为了保持完整向后兼容过去十年中为扩展编辑器而构建的每个插件。 维持现状是最简单的出路，但并不总是正确的方法。

在不重新考虑流程的情况下向现有编辑器添加块会在已经存在复杂性的地方增加复杂性。

鉴于任务 - 重新考虑后期创作以涉及替换短代码，自定义 HTML，小部件等的块 - 我将浪费我作为设计师的责任，因为我没有从整体上看待整个写作，编辑和发布流程。

我不相信 WordPress 会在五年内具有相关性，除非该项目作为一个整体采取大胆的步骤来迎接未来。 多年来，在 State of the Word 主题演讲中一直宣传 JavaScript 核心。 牢记这一点，以及我们必须从根本上简化丰富的后期内容创作的机会，查看整个编辑体验而不是一个小窗口不仅是一个机会，而且可以说，尽管它带来了挑战，否则可能会疏忽设计用它。

不看整个屏幕是不可能设计出一个好的编辑器的。 这很不方便，它使项目变得困难，而且考虑到 WordPress 的遗留问题，它使它变得更加困难。 这并不容易，我们还有很长的路要走，特别是围绕如何在本地扩展古腾堡。 但是采取半步，构建 Gutenberg 仅替换内容 textarea，将是对 WordPress 的重大损害，也是一个糟糕的启动设计。

可以将 Gutenberg 的一个组件（仅编辑器画布）

我想问题就变成了古腾堡应该如何处理不支持编辑器的 CPT——古腾堡如何在从块构建页面没有意义的上下文中运行，它只是元驱动？

@CalebWoodbridge这已经是它的工作方式了。 参见： https :

我认为使用术语“范围蠕变”是不正确的。 这个术语当然不适用于旨在做古腾堡的项目。

请原谅我在这方面的观点，但我认为值得一提。 就像在开发人员谈论技术时给予他们的尊重一样，请从同样的角度考虑设计师。 在这个项目上工作的设计师有很多经验和技巧，我非常尊重这份工作，很高兴能成为一个项目的设计负责人，有这么棒的设计师。

我很荣幸有机会与古腾堡的设计师一起工作。 这是日常的乐趣，也是我们在 WordPress 中并不总是能得到的。 大多数时候，作为核心设计师，您都是一个人，能够一起工作真是太不可思议了。

当我们审视设计方法时，体验是关键。 在最初的设想@jasmussen与@matias沿集的完整体验的基础。 作为第二个设计负责人，这是我重视并希望保留的东西。

从设计的角度来看，过去 WordPress 的一个大问题是在小迭代之上的小迭代螺旋。 虽然它适用于前几个，但随着时间的推移，它会累积起来，并带有一些改进补丁的体验。 有很多 WordPress 都受此影响。 编辑是一个，媒体是另一个，还有很多可以指出的。

古腾堡给了我们空间来删除​​补丁，看看我们拥有什么并重新建立。 因此，它为我们提供了进入定制及其他领域的强大视觉语言的开始。 实际上拥有一种将 WordPress 推向未来 10 年的视觉语言。 是的，我们必须考虑得那么远。

我想指出一点，也警告不要使用 Frankendesigns。 世界上的每一位设计师都曾在某个时候建议他们“把 x 放在这里或放在哪里”。 这是不允许设计师设计的。 作为一个项目，如果我们不让设计师设计，我们就会陷入恶性循环。 这是一种直言不讳的过程，可以扼杀设计师的热情。 让我们继续火。

这是个人笔记，超越了古腾堡。 我热衷于创造一个设计师可以茁壮成长的空间——我们并不总是作为一个项目。 让我们向古腾堡证明我们是这样做的。 激情是伟大的，但尊重设计愿景，就像我们在 WordPress 中所做的技术愿景一样。 让我们像听那些谈论最新 JS 框架的人一样多听设计师的意见。

就@jasmussen提出的大胆

我想说清楚，我并不是说古腾堡的设计已经“完成”或完美。 我们需要迭代，我们需要测试。 我们不需要的是倒退，带走已经建立的强大的设计语言。 我们不需要 Frankendesign。 我们需要的是测试、获得反馈并允许设计师进行迭代。

从设计的角度来看，过去 WordPress 的一个大问题是在小迭代之上的小迭代螺旋。 虽然它适用于前几个，但随着时间的推移，它会累积起来，并带有一些改进补丁的体验。

试图将这样的声明与这样的公开声明相协调http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/让用户很难感觉他们正在接受关于工作的诚实交流正在完成。 WordPress 被数百万人以数百万种方式使用，并且已经非常清楚地表明，在元框支持或后期存储格式等技术方面，需要一种增量方法，尽可能减少损坏。 这个决定使实施的几个部分变得复杂，并迫使做出次优但在许多方面得到更好支持的决定。

将开发保持在一种标准而将设计保持在另一种标准上是不合理的。 有时，为了合理的生产，需要缩减“大胆的设计”。 这在汽车制造中是众所周知的，这也是很容易将古腾堡与概念车进行比较的原因。

当然，您想要一个完整的设计，在整个管理员中使用 javascript，但是如果不破坏数百万用户的体验，就不可能是 v5 版本。 相反，如果您缩小规模以专注于编辑器，而不是编辑页面，您可以提供更好的体验（可以通过明智地使用 css 实现您的许多次要目标），而不会损坏。

然后，通过提供一个有据可查的 Fields API，您可以在明年将插件和主题转换为 Gutenberg 块的心态，使生成相同的界面更容易、更合乎逻辑。 很快，metaboxes 变成了旧的做事方式，所有高价值的插件都将切换到块......再一次，这必须有机地发生。 通过弃用功能或创建拆分界面来强迫人们动手，插件作者必须为古腾堡和元框编码，这是站不住脚的。

很高兴您提到大修媒体是一个需要返工的领域……这是一个因失控、僵化的大修而遭受损失的领域。 这是 WordPress 完全采用 JS 框架的第一部分，对于开发人员来说，这在很大程度上是一个巨大的倒退。 媒体库中缺乏定制并不表示它是完美的，而是缺乏将未来和当前用例考虑在内的深思熟虑的设计。 我曾多次尝试修改媒体界面，结果发现有人在某个时候决定将主要组件硬编码到主干模板中。 我昨天真的遇到了其中一个案例！ （正如您在此处的第七段中所见：https://gschoppe.com/wordpress/disable-attachment-pages/）

将古腾堡缩放回编辑器，而不是编辑页面，将为您提供一条不会破坏一切的前进道路。 一旦 Gutenberg 成为自定义发布界面的基础，那么纯 JavaScript 的愿景就可以转移到编辑页面的其余部分。 这种迭代在大型软件包中绝对是至关重要的，除非（正如 matt 声称不可接受的那样）您提供 LTS 版本，并使每个主要版本都进行彻底的突破性更改。

有两个坑，你冒着掉进去的风险，你已经确定了一个。 是的，如果不转向使用现代技术的统一界面，WordPress 可能会在未来五年内消亡。 而且，如果 WordPress 在此过渡期间未能为其庞大的开发人员和专业用户社区提供足够的支持，它会很快消亡。

在不破坏现有工作流程的情况下，采取节拍、缩减规模并交付一些向用户开放工具箱的东西。 然后，您可以逐个版本地向前扩展。 你有一辆漂亮的概念车，但我们需要的是一辆适用于现实世界驾驶的所有边缘情况的量产车。 但是通过提供概念，您可以将这个想法应用到更有限的范围内，一年后，这些原则将无处不在

@gschoppe ，感谢您抽出时间回复。

首先，一些清晰度。 我不同意我的评论与 Matias 的帖子相反。 我完全支持他发表的帖子，这也是我的愿景，我们作为这个项目的领导者以我们看到方向的方式团结起来。 你的个人意见是你的，所以让我们从这一点开始。

将开发保持在一种标准而将设计保持在另一种标准上是不合理的。

我同意，我的评论不是为了让设计被更多人听到或有不同的标准，而是要听到所有的声音，对所有的人应用相同的标准。

很高兴您提到大修媒体是一个需要返工的领域……这是一个因失控、僵化的大修而遭受损失的领域。

我很想看到媒体从头开始关注设计师和开发人员，但事实并非如此。

而且，如果 WordPress 在此过渡期间未能为其庞大的开发人员和专业用户社区提供足够的支持，它会很快消亡。

你这么说很有趣，因为没有人会拿走任何功能。 古腾堡的设计建议没有做到这一点。 无论哪种方式，所有现有功能都可以完成，即使使用的是经典编辑器插件。

我想不出比依靠 iframe 拼凑 UI 更科学的设计了。 虽然我知道元盒正在给设计过程带来很大的麻烦，但设计的一部分是处理限制。 继续前进，就好像这些限制不存在一样，或者将过渡计划推迟到最后会增加已经担心和持怀疑态度的社区的进一步担忧。

如果 Gutenberg 的长期计划是插件领域，那么我会说无限制地进行实验。 但如果它注定不是一个人们必须选择加入而不是选择退出的插件，那么它必须现实地处理核心及其带来的所有包袱。

我的评论并不是为了让更多人听到设计

世界上的每一位设计师都曾在某个时候建议他们“把 x 放在这里或放在哪里”。 这是不允许设计师设计的。 作为一个项目，如果我们不让设计师设计，我们就会陷入恶性循环。 这是一种直言不讳的过程，可以扼杀设计师的热情。 让我们继续火。

在世界上的每一个企业中，设计都会根据实施的约束进行调整。 如果元框的向后兼容性是一个约束，则设计需要接受这一点并在约束内工作。

坦率地说，对元框的完全支持，而不丧失可访问性，是否是设计约束？ 我想要一个明确的答案，就像成千上万的其他人一样。

古腾堡的设计建议没有做到这一点。 无论哪种方式，所有现有功能都可以完成，即使使用的是经典编辑器插件。

目前，古腾堡将所有元字段放在 iframe 中。 这在非常深的层次上破坏了功能。 我们正处于可访问性时代，采用创建自定义用户体验并将其囚禁在 iframe 中的主要预期方法从根本上消除了这些工具的所有可访问性。 它还使加载编辑器所需的请求数量增加了三倍，并为用户提供了糟糕的 ui，将全屏模式体验限制在一个很小的区域。

目前，该主题讨论了古腾堡是否应该选择加入或退出自定义帖子类型。 如果选择加入，想要支持所有帖子类型的开发人员做出的先前一致的 UI 决策将在 Gutenberg 体验和经典体验之间分裂，需要两倍的开发工作才能为两者提供合理的用户体验，并确保不一致的用户体验。

目前， wp_editor()函数（这是在非编辑页面上实现全功能编辑体验副本的当前最佳实践方式）不提供古腾堡界面，这意味着我不能在非帖子页面上创建自定义编辑体验......除了为用户提供拆分 UX 之外，我在那里的前进道路是什么？

虽然删除 Gutenberg 的插件可能会解决一些问题，但您不能将其作为插件开发人员的解决方案发布。 他们没有自由说“如果您想要跨帖子类型的一致且可访问的用户界面，您需要禁用新编辑器”。

功能删除不是标准工作流程的向后兼容性。 对于无法容纳一流体验的 1% 用户而言，移除功能是最后的手段。 在这种情况下，我给出的例子中没有一个是 1% 的问题。

火上浇油：就在上周，我在使用 iFrame 时遇到了一个大问题，即。 它们可能在桌面系统上运行良好，但在 90% 的测试案例中，它们在移动/响应式系统上大量失败。 在挖掘了大量的留言板帖子、网上的文章和 Stack Overflow 上的问题之后，我决定完全放弃 iframe 方法，因为响应性变得如此复杂，因为它们……呃。 一些转换任务相当容易完成，例如“使用重定向到项目所在的实际子域”，而不是依赖 iframe 来进行漂亮的装饰，也就是只显示假定的主域，但其他的则更令人痛苦。

尽管如此，与我必须做的大量工作相比，我必须做大量的工作才能正确地获得 RWD，最重要的是，可靠且可维护，以使用 iframe，转变要少得多的努力，因此是更好的出路。

总而言之，尽管 iframe 乍一看是一种简单的方法，但它们是一个非常糟糕的设计选择，不仅仅是因为（很多）可访问性问题。

只是我的 0.02 美分，
cu，w0lf。

谢谢@mtias展示这个问题。
波纹管我发表了我对古腾堡如何为 WordPress 插件开发人员敞开大门的想法。

任何现有块的可定制 CSS 类

需要：每个块包装器的 CSS 类以及对其进行自定义的完全访问权限。 如果 Gutenberg 要求即使来自第三方开发人员的最顶层元素上的 CSS 类，那将是很棒的。

目的：通过这种方式，我们可以将自定义类添加到块中以进行高级样式。 我们还可以使用类来添加动画或其他高级块属性。

用法示例：我们

任何现有块的可定制数据属性

需要：可以为任何块包装器添加自定义数据属性。

目的：上述自定义 CSS 类的更简洁、更灵活的替代方案。 使用数据属性，我们可以为页面上的任何元素设置样式。 除了样式之外，自定义数据属性还可用于为 JS 存储额外的元数据。

用法示例：

• 响应块：标记一个只在移动/桌面上显示的块
• 条件块：用 JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...标记要显示/隐藏的块
• 块动画: 标记要动画的块<div data-animation="on-load animation-style-3"...
• 块设计： <div data-skin="dark"...