Gutenberg: 一种在代码中禁用Gutenberg编辑器的方法？

也可以看看：

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-be-able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

嗨@aduth更新了标题，使其更有意义-寻找代码选项:)谢谢

我认为这对于许多开发人员来说将是非常有用的功能。 实际上，我会建议我，只要合并到核心中，我认为古腾堡只应在5.0版的WordPress新安装上处于活动状态，而不应在升级到WordPress 5.0版的站点上处于活动状态。

如果将其与激活/停用代码的方式结合在一起，则开发人员可以在准备就绪时将其打开。

您能否详细说明为什么需要通过代码实现这一目标？

如果这是客户端可见性/控制的问题，则可以始终将上述插件安装为“必须使用的插件”： https :

因为代码更改既快速又容易-启用插件不是1）不是我的代码，而是2）不像添加某些代码那么简单-将依赖关系添加到列表中并不是解决该问题的实用且不明智的方法。

定义常量可能是您的代码，但是在该常量上运行的逻辑将与您的代码不如正式维护的“经典编辑器”插件那样多。

我要澄清的是，我并不是要争辩，而是要更好地了解这些方法为何如此吸引人，确保存在足够的选择，而又不提供过多的选择来维持。

为什么插件功能不能成为核心的一部分？ 只是问，因为我很好奇:)

我想反映对启用/禁用Gutenberg编辑器功能的需求。 我的特殊情况是，我的一个WordPress网站是基于具有自定义编辑器的主题构建的（例如：Enfold主题中的Avia Editor）。

启用古腾堡（Gutenberg）后，编辑人员的工作流程将更改。 他们必须转到“所有帖子”或“页面”，然后单击“经典编辑器”，然后单击“高级布局编辑器”按钮，该按钮将调用主题内置编辑器，而不是简单地在要编辑的页面上单击“编辑” ，或从预览页面。 我们需要这个编辑器，因为我们网站的外观和风格是围绕我们使用该编辑器构建的模板进行标准化的。

尽管该过程对大多数人来说似乎微不足道，但数十名编辑人员的工作流程更改将引起一些支持方面的麻烦。

我的2美分。

我认为区别只是“心理”上的。 在Core中拥有它意味着我们将无限期拥有它，这会伤害Gutenberg的采用，因为它将它作为插件意味着我们将在一段时间内支持它（我想Matt说了几年），并且在某个时候我们会停止。

我不知道是否需要将其分解为一个单独的问题，但我想表达我对@wpmark的想法的支持，

如果您愿意阅读它，我写给我的我的论点，它综合了客户界面的巨大变化以及正确支持古腾堡（Gutenberg）可能需要进行的代码更改。对于我的客户，可能没有预算）。

感觉古腾堡（Gutenberg）对于WordPress新手来说，非常适合安装新博客并开始使用。 对于那些升级并认为“是的-新编辑-我会的”的人来说，这将是很棒的。 但是对其他人来说，这将是巨大的震惊。 在某些用例中，GB可能不是编辑自定义帖子类型的好界面，或者“块”可能不是正在编辑的信息的良好数据模型。

感觉就像在这个主题上需要听到开发人员和小型企业主的声音。 我认识许多WordPress小型开发商店，而由于我的博客文章中概述的所有原因，这种变化将是痛苦的。 我还没有听说过任何开发人员或小型机构说自动为更新的站点启用GB是个好主意。 我听说过很多想法。

这种WordPress用户（以及像我这样的开发商店都是WordPress的大力支持者和拥护者，所以我们真的希望您会听到）非常了解他们的用户，我们深入了解我们在WordPress上构建的内容以及是否建立了WordPress。无需修改即可很好地适合GB用户界面，我们需要能够代表客户管理此更改的功能。

我知道我们可以安装经典编辑器插件，并且仍然可能需要这样做，以消除我们的客户端自己启用GB的可能性。 如果事实证明GB对于升级站点是可选的，则自然会涉及在核心中具有禁用它的代码。 因此，这也会使@ smp303 （以及其他想要在内核中禁用它的方法的人）感到高兴！

我希望在制定合并到核心的计划时能听到开发人员和像我这样的小型WordPress企业的意见。 这种变化可能会影响我们的生计，有些人会觉得这种变化过快地强加于他们。 请为我们提供更多管理过渡的选项，并考虑到GB首次添加到内核中时，它并不是适合每个人的。

WP核心中的过滤器或wp-config.php的常量似乎可以提供两个可靠的选择。

呼应@rosswintle及其上面的出色博客文章：我们是使用自定义字段，元框（尤其是ACF）提供真正丰富的编辑体验的众多代理机构之一。 “ WordPress作为平台”是我们的承诺，这就是最近几年我们一直在做的事情。

必须有一种方法为那些想要的人启用古腾堡，而不是为那些不需要的人强制执行。 对于这是在代码中还是通过插件发生，我相当容易-实际上，当某人使用管理控制台维护50多个WordPress网站时，安装大量插件来禁用Gutenberg会更实际（如果不是极客的话），但是，只要可以做到。 甚至是仪表板中的设置选项都可以，IMO-更好的默认设置为“ Gutenberg：关闭” ...

罗斯（Ross）关于古腾堡（Gutenberg）向后安装场地的观点也是正确的。 实际上，为客户建造的任何人都知道，绝大多数人花了他们的预算来启动，然后再没有任何预算。 翻新Gutenberg，重新培训客户，提供不同的界面-认为除了开发人员和企业主之外，任何人都可以为此付出代价的是幻想之地。

就像回应@ smp303 ， dmje和@rosswintle的情绪一样。

能够在functions.php中添加一个简单的操作来禁用Gutenberg似乎是最简单，最明显的事情。

我禁不住觉得插件方法已经使它比绕过Gutenberg所需要的难度要大一些。

我知道核心团队已经为古腾堡（Gutenberg）付出了很多努力，但其成功应取决于其优点，而不是减少避免的能力。 此外，考虑WP开发人员必须为一个全新的编辑器进行开发，学习反应并仍然开发和维护旧版内容-开销很大。

我也想回应一下-我也希望通过代码而不是通过插件禁用Gutenberg编辑器的选项。

另请参阅此已创建的Trac票证，现在已作为wontfix关闭： ＃WP43068

在https://core.trac.wordpress.org/ticket/43068#comment中每个@ dd32 ：6

我不认为我们会为此提供支持，而是直接将人们引向该插件，并可能为其提供一个mu-plugin包装器，这仅仅是因为现有的插件不只是一个开关，而是涉及不在核心使用的代码。

WordPress一直在努力摆脱常量，因为它们很难在以后更改。“哦，我想让Gutenberg为何禁用它？哦，我的随机SEO插件（或前开发人员）以为我不会想要它并强行禁用它，太好了。现在我可以为我修复此问题”（最终用户）

我可以看到为什么有些人想要禁用它，但是我看不到有任何必要以这种方式完成它。

我认为我们可以安全地将其关闭为wontfix ，以后可能会更改（然后我们将再次进行访问），但是我不希望如此。

谢谢大家的反馈。 我知道要求Classic Editor插件完全禁用块编辑

在未来几年中，用于管理站点数据的“块”概念将成为思考，布局，交互和编辑数据的主要方法。 WordPress 5.0中的块编辑器是朝这个方向迈出的第一步，而今年的古腾堡定制化重点是下一步，以及古腾堡主题。

当然，当WordPress 5.0发行时，并不是所有人都会100％准备好进行块编辑器。 这是每个人都知道的实际现实，我们不希望让人们没有可行的升级到WordPress 5.0的方法。 考虑到这一点，根据您的特定用例，有几种不同的禁用Gutenberg的方法。

如果您注册了不与块编辑器一起使用的元框，则可以轻松地将该元框标记为不兼容。

类似地，讨论了为CPT添加类似标志（＃2457），以便不需要块编辑器功能的CPT可以选择退出。

这是禁用块编辑器的两个主要的长期用例-无效或不适合使用模式的情况。

考虑到这些问题，让我们考虑一下WordPress未来如何发展（注意，我在这里注视着一个水晶球-此列表上的事情不一定按此顺序，时间框架或甚至-只是一个潜在的场景，在很大程度上取决于WordPress 5.0版本最终的运行方式）。

• 定制程序对所有内容都使用块概念。 对于99％的新站点，块是创建整个站点所需的唯一内容。 块操作是网站的构建方式。
• 新主题将完全围绕建筑工地发展。 标准的WordPress用户体验是使用块构建的。
• 同时，wp-admin将开始采用Gutenberg带来的JavaScript-app接口。 当然，仍然可以切换到经典编辑器，但它与WordPress界面的其余部分不匹配。

我要重申，这已经过去了几年的时间，将会有诸如Classic Editor之类的插件来还原较旧的接口，但是这些接口不一定要在Core中维护。 虽然在WordPress 5.0中禁用块编辑器是一个合理的选择，但是如果您使用WordPress 5.5或6.0，并且仍在使用经典编辑器，那么会对您的客户造成很大的损害。 举一个例子，网站布局最佳实践已经从表格布局发展到CSS布局的多次迭代，以及现在的网格布局，WordPress开发最佳实践也在不断发展。

因此，回到最初的问题，禁用块编辑器的基于代码的单个选项不是可行的长期解决方案，它无法扩展以为将来的WordPress Core开发提供适当的选项，这确实有害无益。如果我们要创建此选项，请向此处的所有人发送。 但是，Classic Editor插件可以继续发展以适应未来带来的任何范例。 它提供了一个更宽松的环境，可以专门开发它以满足人们的需求，而不需要适应整个WordPress世界的更一般的需求。

古腾堡（Gutenberg）编辑器的问题不是块或块的概念-编辑器本身不是一个好工具。 当前，它比现有的编辑器更令人困惑-它本身还远远不够完美。 而且，随着时间的流逝（我猜是在四月，预计会越来越多），人们越来越担心，反馈永远不会是“您是对的，这就是我们计划解决的方法”，就像您所做的那样。上面的“嗯，这正在发生，所以最好登船。”

至少使我感兴趣的是，停用古腾堡（Gutenberg）的兴趣不是块与小部件的未来以及定制器的长期路线图-而是真正的编辑器很烂。 我不想使用它。 我的客户不想使用。 使用它不是一件好事。 而且，它不是很好的原因是每个段落和一段文本都是一个“块”的基本概念，我们都讨厌那个。

这就是我们要关闭此功能的原因。 对许多人来说，去古腾堡（Gutenberg）是非常不愉快的经历，对客户和发展都造成了极大的困扰。

我不在乎未来的路线图。 我很担心失去客户和业务，到目前为止，古腾堡团队中没有人似乎也有这种担心。 当我们收入的核心平台朝着我们不想走的方向前进时，我们应该怎么做？ 当我们以“未来路线图”的名义抛弃我们的担忧时，我们应该怎么做？

我全心全意地将小部件，插入和短代码替换为通用块系统。 它认为这是一个好主意-我支持它。 我喜欢尝试让用户更好地控制其网站布局-为什么不呢？

我很担心，因为当前实际的内容创建工具是一个令人头疼的混乱局面，我的一个客户（超过300个）都不希望使用。 他们实际上惊恐地看着它，所有漂亮的YouTube小样和视频以及录制的WordPress谈话都向他们展示了他们讨厌它的程度。

他们不想写块！ 他们不需要基于块的编辑器！ 他们都讨厌-他们希望它像MS Word或Google Docs一样工作，因为这是他们通常用来写东西的方式。 那就是他们想要的。

当所有WordPress想要做的事是推挤他们的喉咙时，我该如何给他们呢？

我唯一的选择是关闭古腾堡。 因此，我想要一个可靠的方法。 至少直到这门开发火车开始发挥作用，并创造出实际上值得使用的东西-不是作为块机制，而是作为一个实际的该死的编辑器。

我需要一个功能编辑器，其中的文本不是基于块的。 古腾堡什么时候提供？ 回答这个问题，我会告诉您，我们不再需要禁用古腾堡的方法。 在此之前，对数百万的WordPress用户和企业有一定的同情和关怀，并提供一种关闭我们可以信任的Gutenberg的方式-这意味着代码，而不是其他插件。

需要一种从代码级别停用古腾堡的方法。 请礼貌地为我们服务。 不要再给出陈词滥调的答案-只是给我们一种方法，可以将所有该死的东西关掉。

@pento ，多年来，每个用户都有一个简单的选项可以关闭tinymce，尽管许多开发都是针对tinymce的，但没有人建议删除该选项。

我还没有听到有人建议删除该选项作为gutenberg的一部分，而且对我来说，如果不继续使用当前的tinymce，便可以从gutenberg转到基于文本的编辑器，这对我来说没有多大意义。 请记住，tinymce仍必须作为文本小部件和wp_editor API的一部分得到支持，因此没有任何开发或UI意义，不能迫使人们安装插件以公开维护的核心API。

即使出于任何原因，您不想从软件开发POV更改该用户选项以包括gutenberg相关设置，只要您要支持关闭gutenberg，它都应该是gutenberg的一部分，并应保留为API是其发展的一部分。 如导入程序插件所示，即使“核心”插件也不同步，也变得不可用，主要是因为它们不是实际核心开发的一部分。

拒绝将此类API作为核心部分进行维护意味着即使在5.1版本中也没有承诺让人们禁用gutenberg，该版本可能会在2018年发布。您不能期望人们能够使用这样的API制定任何中期计划不确定。

@pento感谢您的详尽答复。 我认为这不仅是如何禁用古腾堡的问题，而且还涉及默认情况下是否以及如何启用它。 我认为您的回答涵盖了这两个方面，但这也困扰着我。

让我感到非常惊讶的是，这里和其他地方都暗示着经典编辑器将从WP中删除，而“经典编辑器”插件会将其重新添加。这是否是正确的理解？ 对我来说，这似乎是一个非常糟糕的主意，但我现在无法阐明为什么。

@markkap还对文本小部件和wp_editor API提出了很好的建议-如果删除TinyMCE，它们将如何保留在核心中？

并且编辑meta_box / CPT代码以防止Gutenberg加载很好，但是实际上，我是一个孤独的自由职业者，可能为客户建立60-80个站点。 我不会去编辑所有的代码，许多小客户不想付钱给我。 我宁愿选择加入而不是选择退出：当我宣布支持它时，应该打开Gutenberg。 同样，此处的默认设置是向后。 您正在强迫人们进行更改以防止事物更改/破坏（如果需要，我很乐意为此提出一个单独的问题）。

如果您使用WordPress 5.5或6.0，并且仍在使用经典编辑器，将会给客户带来极大的伤害

（也用我的水晶球）我不一定同意这一点。 我认为无法断言古腾堡（Gutenberg）和图块将对以后的所有用例提供更好的编辑体验。

我还发现自己对“块”的本质有些困惑。 这可能是一个术语，但是它暗示以下一项或多项是正确的：

• 我正在努力进行范式转换，或者我误解了一些东西
• 新范式沟通不佳
• 像我这样的开发人员使用WordPress来为客户构建内容管理工具的方式尚不清楚
• 像我这样的开发人员使用WordPress来为客户构建内容管理工具的方式已广为人知，并被忽略。

你说过：

在未来几年中，用于管理站点数据的“块”概念将成为思考，布局，交互和编辑数据的主要方法。

这让我有些害怕，我会再说一遍。

https://wordpress.org/gutenberg上的Gutenberg页面似乎与该描述不一致。 它称块为“内容块”，并解释说：

[块]是样式内容的统一方法

_注意：我是一个后端开发人员，我在数据方面非常思考：系统中存在哪些数据，数据项具有哪些属性，数据项如何关联以及如何查询和操作数据。

我的理解是，“块”是内容的一部分，可用于组成帖子，页面等。 它们主要使用HTML注释存储在数据库中的帖子内容中，以实现向后兼容，但是您也可以配置块以将数据保存到其他地方，例如post_meta。 （注意：这就像黑客一样，可以让像我这样的人满意地将元数据放入块中-感觉这不是关于块的性质的深思熟虑的设计决定）

您所说的意思是块将驱动_everything_。 它们是将如何管理“站点数据”。 您所说的这些以及其他内容暗示，块不仅是内容的一部分，而且是可以与任何内容关联的某种用户界面设备：站点选项，自定义，有关帖子，小部件，菜单的元数据，用户个人资料字段，所有内容。

因此，我认为我们需要澄清“障碍”的性质。

如果您的意思是正确的，那么我认为这代表着对像我这样的人如何使用WordPress的根本误解。 我认为这种方法将促使我摆脱WordPress培训，并为某些项目找到替代的CMS。 WordPress将用于博客和杂志，但是自定义帖子类型提供的许多机会将消失。

WordPress中的元数据如下所述：有关数据的数据。 这些信息为内容项提供了其他属性。 元数据不满足要求。 而且，IMO，因为我理解它们不适合放在“块”中，所以我创建的某些帖子类型除标题外没有其他内容：它们仅具有属性/字段/元数据。

如果您在此处描述的内容是正确的，那么我想知道为什么发布状态不被阻止？ 为什么类别和标签不被阻止？ 为什么摘录不成问题？

我个人认为这些不是我理解的“障碍”，因为它们不是内容，它们是有关内容的信息。 它们在UI中的位置很重要。 用户如何与这些信息交互是很重要的。

我创建的一些post_meta是相同的。

我（我想）会喜欢Gutenberg和用于创建帖子和页面的块。 但是我误解了“区块”，或者项目误解了人们如何使用不适合“区块”的数据。

我很高兴澄清这一点，也很愿意被说服。 但是，将块作为“思考，布局，交互和编辑数据的主要方法”似乎并不适合我在WordPress中构建的内容。

而且，这又回到了主要问题，这就是为什么我不认为应该从核心中删除经典编辑器的原因，也是为什么我不希望我的用户在将其升级到v5时自动将其打开的原因.0。

@rosswintle您已经总结出每种方式都绝对完美，几乎与我交谈过的每个开发人员都具有相同的感觉。 我只是希望有人在听这些问题，我们可以为每个人找到解决方案。

添加+1，使Gutenberg仅作为新安装的默认编辑体验。

正如@rosswintle所说，有成千上万的WP开发人员，他们的客户对花时间恢复经典编辑器不感兴趣。 让现有站点按原样继续（当然可以使用新的编辑器，但如果没有按预期使用，也可以切换回去），并使用新安装来推出Gutenberg。

想想所有拥有WP网站的小型企业所有者。 几年前开发的网站发展得很好，没有任何新的发展。 突然，这些用户迫使古腾堡（Gutenberg）受迫，不仅需要学习一个新的界面（这些用户一开始可能不是很精通技术，古腾堡可能对他们来说可能不那么直观），但这样做可能会阻止他们从编辑其网站内容。

还有WordPress的声誉需要考虑，我们仍在努力摆脱WP充满安全漏洞的观点。 @wpmark和我什至在本周早些时候与某人进行了随机交谈，一旦他们知道我们使用WordPress开发后，他们提到的第一件事就是“如何保护您的网站”。
用户是否有可能发现其站点损坏或难以使用的风险？ 这将如何影响WP在未来几年的声誉？

我绝对认为新站点应该启用古腾堡（Gutenberg）功能，这可能是一个很大的功能，在5分钟的安装过程中，它会从屋顶上喊出来，但是请让旧站点保持原样。

我不希望只在新安装的设备上打开古腾堡而迷失在这个关于禁用方便性的担忧中。 这是它的一个特定问题https://github.com/WordPress/gutenberg/issues/4423

请添加您的想法，投票和反馈。 @乔夫夫@wpmark @rosswintle @markkap @dmje

当场@rosswintle。

当我宣布支持古腾堡时，应该将其打开。 同样，此处的默认设置是向后。 您正在强迫人们进行更改以防止事物更改/破坏（如果需要，我很乐意为此提出一个单独的问题）。

如果我尝试过，则无法同意。 我不认为推动古腾堡的男孩和女孩理解这一点。

只是从企业角度补充了Ross所说的话（他很好地介绍了小型自由职业者的一面）：我为一家跨国PLC管理的站点就像油轮一样。 像这样的根本性更改需要很长时间才能实施。 必须进行测试，甚至需要进行测试，然后将它们安排在每周的发布计划中，这是详细的代码审查和批准过程的一部分。

这将给我自己和我的团队带来巨大的头痛。 实际上，很有可能，我们可能最终会停留在4.9.x上，直到发布5.0.0的最终RC之后我们能够彻底检查古腾堡的影响为止。 这可能需要数周甚至数月的时间。 这不是快速解决方案。

我还发现自己对“块”的本质有些困惑。 这可能是一个术语，但是它暗示以下一项或多项是正确的：

•我正在努力进行范式转换，或者我误解了一些东西。
•新的范式无法很好地交流。
•像我这样的开发人员使用WordPress来为客户构建内容管理工具的方式尚不清楚。
•像我这样的开发人员使用WordPress来为客户构建内容管理工具的方式已广为人知，并被忽略。

我绝对觉得是后者。 我毫不怀疑，古腾堡（Gutenberg）团队的成员知道并了解大多数专业开发人员如何使用WordPress构建网站。

但是，这种方法是完全不兼容的，因此将WordPress推向站点构建器方法，Automattic需要WordPress来使它继续与WordPress，Wix等人竞争。

WordPress不能同时成为网站建设者和专业CMS。 只是做不到。 它在两者之间走了一条细线，允许用户通过插件在任一方向上移动它。 （针对使用Beaver Builder，Divi等人进行的网站建设以及针对具有ACF和CMB等插件的专业CMS）。 但是，现在很明显，CMS正在坚定地朝网站建设者的方向发展。 使用自定义字段的网站是该死的。

最后，您对块和数据库的看法已经确定。

我认为WordPress团队在研究诸如Gutenberg之类的东西之前应该首先解决许多问题：

• 更新最小版本的PHP
• 实现本机语义数据（通过自定义字段）并修改数据库结构以解决该问题。

最后要说的是，Statamic的家伙们演示了如何使用新的Bard字段类型来处理此问题。 可选的编辑器界面，解决了与Gutenberg相同的问题，但以一种更加智能且破坏性较小的方式解决。

我重复我的观点是没有意义的，它们已经在上面表达了。 我同意普遍的共识-在从4.x到5.0的版本中使Gutenberg成为非强制性的，应该将其作为考虑的选项。

当我在这里为大多数开发人员服务时，我为许多客户提供服务，其中有些人非常精通技术，有些人则不是，但是我认为将其推向这个方向只会使大多数人感到困惑。

就任何可能破坏的东西而言； 从客户的角度来看，他们已经为所提供的解决方案创建并花费了预算，他们不会意识到他们可能需要另一个预算来提供支持或解决由他们本人或我自己制造的问题所引起的问题。

在提供给他们的经过深思熟虑的解决方案的开发人员/设计人员或提供者之间，客户和提供者应选择何时启用这种重大更改，而不必遵循强制性规定。

只是把它扔在那里。 尽管WordPress并未严格遵循语义版本控制方法，但5.0.0版是一个重大更改。

如果Automattic不愿意改变有关Gutenberg的策略-坦白地说，那是正确的做法-那么唯一的选择就是将4.9改成LTS版本。

这样，可以在未来5年内将安全补丁应用到4.9。 对于网站开发人员来说，这有足够的时间将其网站迁移到Gutenberg或完全脱离WordPress（我怀疑这将是最受欢迎的选择）。

好吧，每个人都肯定喜欢在这里写长评论。 for今天晚上对我来说，所以我不会谈所有事情，但我想谈谈几个问题。

让我感到非常惊讶的是，这里和其他地方都暗示着经典编辑器将从WP中删除，而“经典编辑器”插件会将其重新添加。这是否是正确的理解？

那是不对的。 我在之前的评论中提到过，元框和CPT可以自动回退到经典编辑器-如果删除了经典编辑器代码，它们将无法执行此操作。 🙂

古登堡（Gutenberg）使用TinyMCE来驱动可编辑的文本块-不会随处可见。 像wp_editor()这样的函数可以在Core中相对容易地维护，而无需移至插件-我希望它们可以无限期地继续工作。

您所说的意思是块驱动一切。 它们是将如何管理“站点数据”。 您所说的这些以及其他内容暗示，块不仅是内容的一部分，而且是可以与任何内容关联的某种用户界面设备：站点选项，自定义，有关帖子，小部件，菜单的元数据，用户个人资料字段，所有内容。

我就是这么说的嗯，元数据不是一个块，尽管它可以告知如何使用或显示一个块。

因此，我认为我们需要澄清“障碍”的性质。

当然。 块是可以与其他块组合在一起的HTML块。 有很多API使得处理块变得轻松而又轻松，但这就是它的原因。

_不是_：

• 一堆HTML存储在post_content中（尽管有些块使用该存储方法）。
• 静态的（尽管有些块是）。
• 动态生成的（尽管还有其他一些块）。

@rosswintle ，您几次提到元数据，我想澄清一下您在这里指的是什么。 您能给我一些您认为是元数据的例子吗？

如果您在此处描述的内容是正确的，那么我想知道为什么发布状态不被阻止？ 为什么类别和标签不被阻止？ 为什么摘录不成问题？

只是一个建议，我不确定是否应该使用主题选项，但是为什么不将其添加到add_theme_support（）中，因为过去大多数新开发的功能都是这样？

这样，可以在未来5年内将安全补丁应用到4.9。

鉴于WordPress 3.7是在3年前发布的，而其最新安全发布是在6周前，所以我认为可以合理地假设WordPress 4.9将在很长一段时间内获得安全补丁。

@eirichmond ：古腾堡自定义焦点可能需要add_theme_support() ，但是大多数主题将支持基于块编辑器的内容，而无需进行任何修改。

古腾堡（Gutenberg）定制焦点可能需要add_theme_support（），但是大多数主题将支持基于块编辑器的内容，而无需进行任何修改

@pento请问古腾堡定制化的重点是什么？ 这意味着什么？ 您提到_most_主题将支持基于块的内容，因此您能指出为什么主题不支持该块吗？

我看到带有侧栏的主题不支持某些块，因为该块指示其为全宽度，例如封面图像。

请问古腾堡定制的重点是什么？ 这意味着什么？

马特在《圣经》中谈到了这一点-今年的三个重点是：

• 古腾堡编辑
• 古腾堡定制
• 古腾堡主题

古腾堡（Gutenberg）编辑器是WordPress 5.0中的功能。 古腾堡（Gutenberg）定制刚刚开始进行，并且正在研究站点定制，以及它如何在区块范式中工作。 古腾堡（Gutenberg）主题将成为今年的默认主题，并可能在今年晚些时候开始实施。

您能否指出一个主题为何不支持该主题？

希望所有主题都能正常工作。 🙂有些块确实有一些CSS与之关联（封面图像是一个很好的例子），因此有可能有些东西看起来不太正确。 不过，没有什么会导致主题停止工作。

我能提醒人们，古腾堡不是一个自动机项目，不要贬低非自动机制造商所做的贡献和工作。

我还不清楚为什么插件不够用，我所见过的论点都表明人们不喜欢Gutenberg，或者他们已经设置了工作流程，之前已经提到了所有问题，并且都已解决。通过安装并启用经典编辑器插件。

请记住，链接插件中也有先例。

但是无论如何，让我们建设性地：

我升级到WP 5.0，古腾堡替换了我的自定义编辑器/我不喜欢它/我需要与客户更多的时间

我该怎么办？

安装经典的编辑器插件并启用它，问题已解决。 现在，古腾堡被4.9版中的经典编辑器所取代

缺点？

您将不会获得任何新的Gutenberg功能，而将来的新功能可能无法在经典编辑器中使用。 例如，如果行和列块在5.1中到达，我看不到经典编辑器中的意义

我有很多客户端站点，不是在每个站点上都安装和激活该客户端，如果禁用了客户端怎么办？

用作MU插件：

• 将插件文件夹放入wp-content/mu-plugins
• 将文件包含在您的mu-plugins文件夹中：

<?php
require( 'classic-editor/classic-editor.php' );

现在，插件始终处于加载状态，无法停用。 除了放置文件，不需要其他步骤。 然后，您可以将文件和文件夹上载一次到每个站点，而不必担心。

经典编辑器插件的经验教训

这个插件中有很多有用的功能，例如检测是否激活了古腾堡，而其中的大部分实际上是在移除钩子并替换它们。

它甚至添加了一个设置区域，该区域具有一个选项，可以选择加入“经典编辑器链接”，这样您无需替换古腾堡，而是可以通过在帖子屏幕中激活“经典编辑器”链接的gutenberg插件获得所看到的内容，从而给你3不是2的选择。

我强烈建议人们实际看看该插件，对其进行测试，并查看其构建方式。

请记住，我们是一个社区，而不是Automattic产品团队的主题。 如果它损坏了，我们将在整个WP发布周期中对其进行测试和修复。 我在此线程中看到许多涉众，他们具有修复该插件的技术能力，然后还有一些。 如果确实有这么大的事，那么我相信有人会加紧努力，就像核心工作的人加紧了一样

@rosswintle ，您几次提到元数据，我想澄清一下您在这里指的是什么。 您能给我一些您认为是元数据的例子吗？

@pento当然：

国家示例：

“国家”帖子类型，其名称，标题（说明），内容（内容），然后：

• 人口
• 标记图片的网址
• 排名（和其他因素，可能以某种方式编码）
• 相关的“社区”（与另一种职位的关系）

请参阅： http ：

房地产示例：

具有以下内容的“属性”类型：

• 价钱
• 类型
• 房间的数量
• 施工日期
  等等

事件示例：

具有以下内容的“事件”类型：

• 日期
• 时间
• 复发详情
• 位置
  等等

有许多。

启用并玩了一点之后，我有一些主要的担忧...现在，我将专注于主要的一点：

WooCommerce完全崩溃了……就像在编辑产品时一样。 而且我想还有更多的插件也会完全崩溃。 那么有什么计划来帮助社区兼容？ 我们会得到多久？

@tomjn

我所看到的论点都表明人们不喜欢古腾堡，或者他们已经设置了工作流程

“不喜欢”可能是错误的说法。 我认为人们对古腾堡（Gutenberg）不适合许多WordPress用例提出了很好的论据。 这不是喜好或品味的情况，而是适用性的情况。

而且开发人员只想要执行此操作的选项。 我可以在wp-config.php中切换其他主要功能，例如调试，代码编辑器，多站点，自动更新和发布修订。 某些功能仅通过使用add_theme_support支持它们的主题启用。 为什么我们不能使用代码中的选项以相同的方式切换古腾堡，以便开发人员可以使用适合他们的工作流程来进行如此重大的更改？

这里的问题之一是，开发人员（不一定是我，而是其他人）在表达对Gutenberg的担忧时感觉不到他们在听。 将其添加为令牌手势可以帮助他们，这将帮助您使他们更加自信。 即使出于您自己的某些哲学原因，您不同意这样做是正确的，也应将其视为可以提供给不满意的开发人员的橄榄枝。

请记住，链接插件中也有先例。

链接插件是一个不好的例子。 如果您正在使用它，它将保留核心中的现有功能，而仅删除新安装的功能（或者如果您不使用它）。

我喜欢这个先例。

这就是＃4423中所主张的

让我真正感到惊讶的是，核心开发人员和Matt都假设整个世界都将毫无疑问地完全采用“ Blocks”概念和Gutenberg编辑器。 我猜这一切都很好，但是他们与古腾堡（Gutenberg）一起使用的这种“我们的方式或高速公路”方式不仅不友好，而且会严重影响整个WordPress的状态。

各个世纪以来，有很多真正伟大的想法没有被保留，因为它们根本没有被大众接受。 Betamax是一种非常出色的格式，但是它确实坚持了下来，VHS赢得了胜利。 如果古腾堡和积木不粘怎么办？ WordPress将会发生什么呢？

然后是信任因素。 绝大多数WordPress用户甚至都不了解WordPress是什么。 他们只是因为WordPress很受欢迎而使用它，而无论您如何看待WordPress，对于大多数人来说，它只是一个品牌。 品牌的生存和消亡取决于消费者的信任。

当5.0更新最终推出时，一百万个WordPress网站突然发生了巨大变化，那些对WordPress世界一无所知的最终用户将如何应对？

我的大多数客户都说过“几乎没有能力打开计算机”，或者只是想要他们付的钱就可以按承诺工作。 这些人相信WordPress可以完成承诺的工作。 如果有一天，由于用于管理其站点内容的全新格式而无法兑现承诺，则该消息将突然改变。 然后，他们对WordPress的信任将被破坏，如果人们不再信任它，人们将只会放弃一些东西。

我认为，这正是开发人员最担心的地方。 我们建立了出色的自定义WordPress网站，这些网站可以准确地满足客户的需求，而现在由于古腾堡（Gutenberg）而一切都将被“破坏”，并且我们没有其他选择来防止可能发生的巨大灾难。

古腾堡（Gutenberg）的唯一目的是增加WordPress Marke份额，但可以很容易地做到相反。 它实际上可以使人们远离WordPress。 古腾堡可能成为WordPress的新可乐，而WordPress不像可乐那样大，它可以像可乐那样恢复。 人们会继续前进，而不回头。

您一直在谈论“这将影响Gutenberg的采用的未来，等等，等等，等等”，但实际上就是这么简单。 要么每个人都喜欢它，要么需要通过代码或插件删除它，或者任何不相关的东西，或者古腾堡将成为某种奇怪的功能，而没有像Press This这样真正使用过的功能。

就目前情况而言，采取的方向要么是古腾堡将会成功，要么整个WordPress都会失败。 我们，那些担心的开发人员，只是在努力不完全弄乱用于内容管理的出色工具。 我们比任何人都更了解我们的客户如何处理和使用WordPress。 核心开发人员和Matt仅查看统计数据和市场份额，您知道这给我们带来了什么？ 捉鬼敢死队重启。

我们确实确实希望与您合作以实现这一目标，但是，如果我们能够控制将其介绍给世界的方式，而不是将其强加给毫无戒心的用户，那将是更好的选择。 我们所需要的只是一种使我们的客户轻松使用新编辑器的方法。 确实要求不高。

如果古腾堡真的将成为它所承诺的创新，那就太好了！ 大家都跳上古腾堡（Gutenberg）火车。 如果不是这样，那么我们只是要求选择不造成巨大灾难的选项。

就像您知道它不会受到很好的欢迎一样，您想让它如此糟糕地发生，以至于您认为它甚至可能成功的唯一方法就是强加于每个人。 这就像政客们告诉你一个大胆的谎言一样，那就是一项税收法案将如何使所有人受益，而实际上只有超级富豪才能真正从中受益。

就像伟大的考克斯博士曾经说过的那样。

帮帮我。帮帮我。帮帮我。帮帮我。

WooCommerce完全崩溃了……就像在编辑产品时一样。 而且我想还有更多的插件也会完全崩溃。 那么有什么计划来帮助社区兼容？

@ smp303不是讨论此问题的地方，但我们正在努力实现WooCommerce + Gutenberg兼容性。 密切关注WooCommerce开发人员博客。

Windows 8可能比“ New Coke”更好的比喻。

对于更移动的计算心态，这是一个大胆的新愿景，因为它改变了太多的基本使用假设，因此却适得其反。 是的，深入设置后，用户可以重拾以前的Windows经验，但是除非他们加入了技术期刊，否则用户不知道该怎么做。 结果是Windows发生了灾难。

古腾堡（Gutenberg）的发展非常迅速。 它正在做出一个巨大的改变，完全由公司而不是社区来驱动，并且它（通过外部插件）（通过这种方式我几乎看不到任何细节）在一条相当晦涩的道路上通过外部插件返回到传统的编辑器中。谁不喜欢这种新方法。

我认为，如果Automattic / WordPress没有在“设置”中提供一种方法来禁用数百万临时WordPress用户的Gutenberg，他们将对此深表遗憾。 古腾堡是一个巨大的变化。 用户将会大量回退。

在此线程中，我们试图警告您，并建议外部插件不够用。 您需要向用户提供“退出”古腾堡的权限，即使只是允许他们进行一段时间的调整也是如此。 如果我们可以通过代码将其激活到我们现有的主题中，那么我们就可以避免灾难。

我们正拼命地在这方面提供帮助。 外部插件是不够的。 需要内置一个还原为Classic编辑器的选项。它可以作为发行版的一部分来提供，也可以为我们提供一种方法，通过我们可以构建主题的代码来实现。

从逻辑的角度来看，我试图理解允许开发人员在add_meta_box（）中声明一个metabox而不支持Gutenberg的哲学，Gutenberg然后在使用metabox的任何地方导致编辑器屏幕显示“经典版本”编辑器屏幕。 那么为什么有些开发人员反对wp-config.php文件中定义的常量？ 如果我可以声明古腾堡的东西不在某个代码区域中使用，为什么我们不能像在当前设置define语句那样将其声明为在其他区域中使用呢？

请记住，要保持不变，经典的编辑器插件需要与WordPress捆绑在一起，并带有自定义加载程序，并永久保留在那里。 无论用什么代替古腾堡，它都可能会在10、15年后出现。

即使那样，对于需要或同时需要两个编辑器的人，仍然仍然需要插件。

别忘了，由于Gutenberg即将到来，您仍然可以在v4.9中安装和设置插件。

我认为，如果Automattic / WordPress不提供

@robmcclel Automattic不是WordPress，WordPress.org！= WordPress.com，一个是开源社区，另一个是付费的第三方服务。 Automattic不会发布WordPress的版本，WordPress不是内部的Automattic产品，古腾堡也不是。 有许多非Automattic的贡献者，发布线索等在Automattic之外做事。

“即使那样，对于需要或同时需要两个编辑器的人，仍然仍然需要该插件。”

实际上，根据此处和其他地方所讨论的内容，如果自定义帖子类型或metabox声明其不支持gutenberg，则编辑器屏幕会自动退回...而无需使用“经典编辑器”插件。 这是古腾堡项目当前状态下的许多问题之一，对于在某些情况下会发生什么有很多意见/陈述，而且这些陈述/意见有很多次与其他陈述/意见有所不同。

请记住，要保持不变，经典的编辑器插件需要与WordPress捆绑在一起，并带有自定义加载程序，并永久保留在那里。

@tomjn等等！ 那么，您是说整个meta box系统都被剥离了内核吗？

不，我完全没有提及元框。 但是请记住，古腾堡中存在元盒，暗示它们已被剥离，这意味着您尚未测试古腾堡，并且忽略了生态系统中很大一部分依赖它们的情况。 对于wordcamp.org，wordpress.org等而言，这将是一个巨大的问题

作为参考，我不是古腾堡团队的成员，我只是观察并运用常识。 仅仅因为我在Automattic工作并不意味着我在Gutenberg具有特殊的能力。 我和在座的其他人一样有发言权，如果我想改变这一点，我将像其他任何人一样通过贡献代码和解决问题来做到这一点。

@tomjn所以你的意思对我来说毫无意义。 “经典编辑器”基本上只是一个管理页面，上面带有元框以及保存等功能。 这意味着为了能够在Gutenberg和Classic之间切换，必须在内核中内置代码，以允许这两个选项，并且Classic功能的所有代码都将保留在原位。

因此，这意味着Classic插件不过是触发切换的一种方式。 似乎在核心中只构建一个常量或主题支持类型的东西比必须构建和维护一个插件要容易得多。

如果Classic的所有内容仍在核心中，为什么要制作一个插件来激活它？

因此，如果必须保留原样怎么办。 WordPress核心中已经有很多旧的和不赞成使用的代码。 内置的Classic触发器在宏伟的方案中根本没有多大区别。

汤姆，我们不要轻描淡写。 Automattic是古腾堡背后的驱动力。 Automattic员工没有多少“但不是”来改变这样一个事实，即晴天时，它就像天空中的太阳一样明显。

古腾堡非常像马特的孩子。 就像是Automattic。 他推动了这个项目。 他一直是它最大的啦啦队长。

古腾堡（Gutenberg）为Automattic带来了可观的运营优势-即为其提供一种产品，以使其与最大竞争对手的游戏感达到平衡。 对于社区的其他人则不能这样说。

是的，许多WordPress用户通过插件使用页面构建器。 但是，还有很大一部分通过诸如ACF和CMB（及其许多分支）之类的插件大量使用了自定义字段。 多年来，该社区的人们一直在呼吁WordPress项目将自定义字段实现为本机功能。

但是，它未能实现，因为没有足够的资金来实现它，并且每次筹集资金时，都会遭受如此常见的开源问题，即委员会辩论导致的死亡。

其他许多紧迫的问题也遭受了同样的命运–例如将min-PHP版本升级到7年来都没有使用寿命的东西。

这些只是几年前应该完成的事情的少数例子，因为该项目的主要资助者不支持它，所以仍然没有实现。

Automattic已将自己的精力投向了古腾堡（Gutenberg），这主要是由于马特（Matt）坐上了驾驶席。 大量的工作时间致力于实现这一目标。 这意味着可以直接从WordPress项目的主要资助者– Automattic获得资金。

我看不到这和机票有什么关系？

@rosswintle这非常相关。 有许多开发人员想要一种简单的方法来选择关闭Gutenberg。 很明显，权力不希望给我们这个，并使其尽可能不方便地关闭古腾堡。

该决定背后的驱动力是Matt和Automattic的议程，以增加他们在DIY网站空间中的市场份额。 显然，由于Matt和Automattic对项目的影响，社区的关注没有得到解决。 这就是100％的社区对古腾堡（Gutenberg）感到沮丧的地方。

由于古腾堡项目的方向在很大程度上受到Matt和Automattic的影响，因此与所有对该项目的讨论一样，它在本讨论中也很重要。

@tomjn

从Gutenberg和即将发布的版本开始，WordPress是Automattic的产品。 相信其他任何东西都是愚蠢的。 .Com或.Org无关紧要-WordPress程序现在是Automattic的产品。 现在，开发人员和从事此类工作的人不过是Automattic的无薪实习生。

社区希望Gutenberg作为插件。 马特没有。 Matt是Automattic的负责人。 Matt是此版本的自任命负责人。 领导古腾堡发展的人是Automattic员工。 Matt强迫这样做。 没有其他决定或辩论-他拥有51％的选票并且正在行使。

不要自欺欺人，以为WordPress可以以任何方式塑造或形成民主或社区产品。 它现在是Automattic的产品，但是过去是在框架或市场上销售的，现在它们正在指导开发重点，进度和决策。

@rosswintle ，这与票证有关，因为社区要求关闭Gutenberg的方法，而Gutenberg团队则回应说插件将是唯一的方法，而不管社区是什么。大整体正在要求。

马特（Matt）和自动机（Automattic）正在对此行使其权威。 您不妨关闭这张票以及所有其他人喜欢的票，因为除了表达同情并为我们提供发泄的余地之外，我们的声音已不再重要。 此票可能甚至不存在。

Automattic负责此事，而不是社区。 我们需要面对这一挑战并做好准备，因为这种情况正在发生，并且唯一的下降是Classic Editor Plugin，甚至还有些慈善。 没有别的了。

我个人没有看到在这里讨论谁在做决定如何将问题向前推进。 它正在作为一个开源项目进行开发，这意味着您可以发表意见，并且我鼓励人们通过帮助开发选项和实施此选项的理由来建设性地使用他们的意见。

关于请求的主题的最后一篇帖子是@wpstudio和@jawittdesigns的一些相关问题

请记住，要保持不变，经典的编辑器插件需要与WordPress捆绑在一起，并带有自定义加载程序，并永久保留在那里。 无论用什么代替古腾堡，它都可能会在10、15年后出现。

常量从未被弃用吗？ （真正的问题）看起来WPLANG可能已经在v4.0中出现了？ 这是关于常数本质的哲学问题吗？ 过滤器会更好吗？ @ smp303是否可以接受过滤器？

即使那样，对于需要或同时需要两个编辑器的人，仍然仍然需要插件。

这是为什么？

@jawittdesigns正确地问：

如果Classic的所有内容仍在核心中，为什么要制作一个插件来激活它？ 因此，如果必须保留原样怎么办。 WordPress核心中已经有很多旧的和不赞成使用的代码。 内置的Classic触发器在宏伟的方案中根本没有多大区别。

@pento几乎排除了大部分删除的可能性：

古登堡（Gutenberg）使用TinyMCE来驱动可编辑的文本块-不会随处可见。 像wp_editor（）这样的函数可以在Core中相对容易地维护，而无需移至插件-我希望它们可以无限期地继续工作。

最后：

别忘了，由于Gutenberg即将到来，您仍然可以在v4.9中安装和设置插件。

我们都知道这一点。 我们试图提倡为工作流程不同的开发人员提供选择的不同方法。

@rosswintle –讨论它很重要，因为最终知道谁在做决定可以

但是，是的，您是对的，因为此特定问题不是讨论此问题的正确位置。 但是，拒绝接受我们的要求表明，与推动决策的人相比，我们处于弱势地位。

无论如何。 您在上一篇文章中提出了一些要点。 实际上，让我来谈谈您的报价：

请记住，要保持不变，经典的编辑器插件需要与WordPress捆绑在一起，并带有自定义加载程序，并永久保留在那里。 无论用什么代替古腾堡，它都可能会在10、15年后出现。

我们是否假设一旦出现替代古腾堡的事情，我们将不会再进行同样的讨论？ 与竞争对手相比，WordPress的大型USP一直致力于向后兼容。 到目前为止，效果一直很好。 正如我们都指出的那样，古腾堡打破了这一点。 除了我们目前拥有的东西之外，别无选择，只有有效的官方认可的黑客手段才行。

事实是，代码仍处于核心地位。 这是一种更聪明，更有效的方法，允许在需要单独维护的插件上使用常量（一行代码），而该插件最终将需要数百行代码。

事实是，代码仍处于核心地位。 这是一种更聪明，更有效的方法，允许在需要单独维护的插件上使用常量（一行代码），而该插件最终将需要数百行代码。

这完全是我的观点。。。不仅仅是需要这个功能的人。 由于Gutenberg当前正确地破坏了大量的插件和主题等，因此...另一个插件不是一个修复程序，它是一个hack，一个依赖项。 这不是解决问题的正确方法，而该问题最终可能会驱散那些制作了最佳WordPress网站的人员。

另一个让我最害怕的选择是，人们只坚持使用4.9，而不升级网站。 然后，这些变得不稳定，容易被黑客入侵，并降低了WordPress的名称。

我只是觉得自己没有足够的想法，因此为什么插件是最终的解决方案。

如果TinyMCE将继续在“古腾堡”下面某些区域，那么为什么不这样处理呢？
5.0之前的版本（也就是由WordPress提供支持的当前网站）默认情况下会通过过滤器/常量禁用Gutenberg，从而可以轻松启用Gutenberg。
5.0或更高版本（又是在5.0及更高版本上安装的WordPress网站）默认情况下会启用古腾堡（Gutenberg）过滤器/常量，使其易于禁用。

这样，任何想使用古腾堡的人都可以轻松地做出选择，而任何不准备或不愿意使用古腾堡的人（无论出于何种原因）也都可以轻松地做出选择。 有时似乎有些人想在古腾堡山上垂死挣扎，而这似乎是更实用（短期内）的解决方案。

@wpstudio这几乎是＃4423要求的。

像@rosswintle一样，我认为重要的是让此问题重归正轨，并让最后的评论看起来很高兴。 感谢您的讨论。

不得不说，无论您对一家公司及其动机有何看法，很多人正在许多不同的公司从事Gutenberg的工作。 就像WordPress一样，它是由社区贡献的（不仅仅是一家公司）。 对那些从事此工作的人做出笼统的陈述是不公平的。 对于那些开始这个问题并想要解决方案的人来说，这也不公平。

我希望这个问题能回到正轨，并继续恭敬地辩论这个问题的重点。

@karmatosed ， @ ntwb ， @ tomjn和该线程中的其他线程，如果上面的小家伙犯了

从上面的线程来看，我认为很明显可以在Core中禁用Gutenberg，因为其他组件必须保留为Core的一部分，因此它只是关闭了Gutenberg。 这很有意义，因为它目前作为插件存在，并且许多站点都可以正常运行。 因此，除非有迄今为止未曾提出过的技术原因，这意味着该决定不是技术决定，而是哲学决定。

而且，这才是真正的核心。 我认为整个社会对此都不是一个主意。 差远了。 这就是为什么要与Matt做出决定（注意，我说是“放置”而不是“责备”）的原因，因为他似乎是背后的推动力。 而且，很明显，在坚定不移地决定使Gutenberg成为Core和5.0版本的一部分的背后。

问题是“为什么？”

我当然可以看到迫使古腾堡进入核心市场的原因。 我认为“区块”对于WordPress，.org或.com的未来生存和广泛使用非常重要。 我做。 我落后于“障碍”的100％。

但是，我认为古腾堡本身作为这些“块”的交付方式并不是一个经过深思熟虑的系统。 正是从这个线索，有3个不同的使用情况（我@rosswintle，并@ smp303）和古腾堡似乎并不满足我们任何人。 确实，这引起了我们相当大的关注-对于我们，我们的业务和我们的用户。

将Gutenberg放入Core的决定对Automattic有意义，因为它迫使每个插件开发人员都采用它，并重新编写其插件以使用它。 这对WordPress.com非常有用，而且可能对WordPress.org有利。 但是，同样，有些用例不会从块中受益，但是希望块的存在也不会对它们造成伤害。

但是，这意味着一小部分人正在为许多人做出一些非常有力的经济和商业决策。 仅对我个人而言，更改为块将需要数百小时和数千美元，再加上为维护系统的重要部分而不得不从计划目标（我服务的社区实际上想要的）中夺走资源所浪费的开发时间以满足那些未知的决策者的需求（同样，我假设Matt是该决策小组的重要组成部分）。

如果古腾堡为我解决问题，我对此不会感到那么糟糕-或说害怕。 但是，事实并非如此。 到目前为止，这使我的生活更加糟糕。 情况可能会有所改善，但是我看不到开发方向的巨大变化。 似乎有关使用，实现，UI / UX以及手段和方法的95％的决定都是由一小撮其他人决定的，没有太多辩论或投入。

WordPress支持整个互联网的25％以上。 转化为数百万个网站，数十亿个网页，甚至可能达数千亿美元。 从《纽约时报》到我网络上的少数书籍博客作者。 从庞大的电子商务网站到我服务的作者出售的个人签名书。 那是巨大的-巨大的。 实际上，它是一个全球性的全球实用程序。

然而，显然是在没有辩论的情况下做出了决定重写所有重要基础的决定，这一决定影响了数百万人。 从界面到对REACT的依赖（由Facebook控制的事实证明它具有高度掠夺性，请问SnapChat）都是如此。 所有这些决定基本上都是单方面做出的。

如果这仅仅是为JetPack中的模块供电，那么没人会在乎。 那就是WordPress.com业务。 但是，事实并非如此。 它正在改变整个互联网的基础。

这导致我现在和现在。 社区，绝对是该线程中的社区成员，正在寻求对使用开源和公开可用的WordPress.org代码构建的产品和业务的控制。 我们正在寻求保护自己和用户的能力，而我们能够想到的唯一方法就是寻求一种关闭古腾堡的方法。 我们要求这种能力成为Core的一部分，就像添加Gutenberg成为Core的一部分一样。

可以将关闭Gutenberg的功能添加到Core中吗？ 是谁做这个决定并指导潜在客户这样做的？ 问这个问题的机制是什么？ 答案有待辩论吗？ 会付诸表决吗？ 有评论程序吗？ 如果是这样，在哪里？

并且@karmatosed ，您100％正确，因为Github的“问题”部分并不是进行辩论的最佳场所。 我同意，此回购协议应很大程度上留给其预期的目的，即确定和解决与Gutenberg插件直接相关的技术问题。

可悲的是，似乎没有其他地方可以进行此讨论。 我的意思是，Gutenberg插件的“评论”部分，但是对于这种对话而言，这是一个非常有限的论坛。

会不会有一个讨论古腾堡的网站？ 不仅要实现它，还要评论和讨论界面？ 发布时间表？ （例如，用什么标准来控制Gutenberg和WP5.0是否“完成”并准备发布？谁来做决定？”）是否会有用户对Gutenberg接口进行测试？有没有办法从@收集数据和反馈

YouTube上有一个有趣的视频，要求人们尝试使用Gutenberg并对其直观性进行评分（链接：https：//youtu.be/7iWRBLCP-l0）-还有其他类似的视频吗？ 是否需要进行大规模测试Gutenberg？ 如果是这样，该数据保存在哪里？ 数据如何共享？ 社区可以看到吗？ 它被用于驱动设计吗？

我们现在与古腾堡（Gutenberg）一起面临的问题-确实是这一线索背后的驱动力-是社区感到与这一过程非常孤立。 我们觉得这正在发生。 确实，这是强迫我们的。 开放评论和辩论的过程，允许人们对界面，共享数据和用户见解等事物发表新的声音和想法，将大大减轻这些担忧。

而且，将块作为核心功能，但将Gutenberg保留为插件可以使一切变得不那么令人恐惧，并且对整个社区来说更可口。 我个人喜欢。 给社区时间探索和开发古腾堡的替代方法-不同的界面和用例-但仍鼓励区块的发展和未来。

所以，那是很长的时间，但是再一次，除了这里，我们还有其他辩论吗？ 而且，这场辩论非常重要。 考虑到受影响的人数和企业数量，这可能是当前互联网上最重要的讨论。

在对此进行了一些研究之后，似乎您需要在mu-plugin文件中执行以下操作来禁用带有代码的Gutenberg，除非我错过了什么-可能！

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

对于上下文，我在mu-plugins文件夹中的文件中具有处于活动状态的Gutenberg插件和上面的代码。 现在，所有后期编辑屏幕都使用经典编辑器。

需要注意的几件事：

• gutenberg_can_edit_post_type不是最终的过滤器名称- gutenberg名称将在合并到Core中之前重命名。
• 该过滤器仅表示“不加载块编辑器”，并不表示“使用经典编辑器”。 它暂时可以使用，但不能保证将来可以使用。 当特定于Classic的代码（例如edit-form-advanced.php ）移至Classic Editor插件时，它将停止回落到Classic编辑器，并明确希望您加载自己的编辑器。

@rosswintle ：从上周开始收集

考虑这一点的最简单方法是“如果数据出现在<body>和</body> ，则它是内容，并且最终可以放入一个块中”。 对于WordPress 5.0，这有一点局限性-仅在<article>和</article>是块。 😉

因此，举一个例子，房地产物业的职位类型。 价格存储在postmeta中，但这是内容。 您可能有一个名为“ Property Lede”的街区，它需要填写一些项目-价格，地址，建筑物类型，卧室/浴室/车库的数量等。 您可能还会有其他块-检查时间，功能，照片，平面图，代理等。使用块模板，您可以设置块编辑器，以便在编辑property帖子类型时，块已经找到，无法移动。 最终用户的工作流与现有的基于基于metabox的工作流看起来并不相似，但与最终输出非常相似。

这有点费劲，但是它希望设置场景-看起来像content _is_ content的任何东西，而不管数据存储在哪里，或者如何在显示在前端之前对其进行操作或格式化。 一些块可能会将其数据存储在post_content ，但这并不是使它们满足条件的定义特征-在前端显示是使它们满足条件的原因。

那么，那些没有显示在前端的信息呢？ 主人的名字？ 与查看约会有关系吗？ 那是“内容”吗？ 是否要输入“块”？

类别/标签/分类法可能会或可能不会显示在前端。 他们是“障碍”吗？

发布状态可能会显示在前端，但这绝对不是一个障碍。

您之前曾说过：

元数据不是一个块，尽管它可以告知如何使用或显示一个块。

没关系但是，为什么要告诉开发人员，将来应该使用块接口来编辑元数据呢？

这对我来说是真正的困惑。 我明白了为什么古腾堡块对于编辑body标签之间的内容是很好的，但是我不明白为什么块对编辑不在这些标签之间的其他数据是很好的。

在我看来，正是这种困惑导致开发人员想要关闭Gutenberg。 我们对WordPress的某些使用具有很多未在前端显示的信息，但是我们被告知，将来应该使用前端编辑器作为此数据的接口。

我希望这能传达混乱。

那么关于禁用它的这些方法...？

@pento该函数的doc块根本不表示此过滤器是临时的：

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

如果不按照说明进行操作，该过滤器的目的是什么？

另外@pento对此：

该过滤器仅表示“不加载块编辑器”，并不表示“使用经典编辑器”。 它暂时可以使用，但不能保证将来可以使用。 当特定于Classic的代码（例如，edit-form-advanced.php）移至Classic Editor插件时，它将停止回落至Classic编辑器，并明确希望您加载自己的编辑器。

我们在许多地方都被告知，如果帖子类型声明show_in_rest => false或帖子编辑屏幕上的meta框声明'__block_editor_compatible_meta_box' => false, ，则将加载经典编辑器。 从上面看来，您在说这将不是核心的一部分，因此如果您没有激活经典编辑器插件怎么办？

要回退到Classic编辑器，会检测到某种不支持Gutenberg的东西，那么肯定必须将Classic编辑器保留为核心的一部分-因此，我们当然不需要插件来调用此功能吗？

那么，那些没有显示在前端的信息呢？ 主人的名字？ 与查看约会有关系吗？ 那是“内容”吗？ 是否要输入“块”？

当然，元数据也有空间-在＃3330中进行了讨论。 我要注意的主要事情是，很多所谓的“元数据”实际上是内容。

类别/标签/分类法可能会或可能不会显示在前端。 他们是“障碍”吗？

好吧，它们是帖子的元内容，但可能是网站的内容。 古腾堡定制化的重点可能包括一个使用该元数据生成内容的块。 the但是，块编辑器中的块不太可能将它们用作内容，因此，为什么分类法位于侧边栏而不是块中。

没关系但是，为什么要告诉开发人员，将来应该使用块接口来编辑元数据呢？

我们并不是说所有元数据都适合块接口。 有些人可以，但不必。 一直以来，重点是元框的现有用法最适合块接口，最简单的区分它们的方法就是考虑它是否显示在前端。 ＃3330详细讨论了编辑元数据的概念。

我可以明确地告诉您，不需要在块编辑器界面中编辑元数据。 如果它不是内容，或者与内容无关，那么它就不属于该内容-还有其他地方可以插入用于编辑该元数据的界面。

那么关于禁用它的这些方法...？

如果您构建站点，请使用经典编辑器插件。 如果您构建插件，请使用CPT和meta box compat标志。 🙂

如果您构建站点，请使用经典编辑器插件。 如果您构建插件，请使用CPT和meta box compat标志。 🙂

这对于我们以后建立的网站或我们拥有“账本”并照顾他们的网站的客户来说是很好的。 但是，那些我们过去建立过站点且可以正常工作的客户端，自动更新等呢？他们可能会单击“更新到WordPress v5.0”。

这些站点将没有安装Classic Editor插件，并且在这些元框/ CPT上将没有任何标志，因为它们是在古腾堡不在时被编码的。 这些站点将出现问题，并使其所有者感到困惑，并且坦率地说很烦。 如果我错了，请纠正我。

@wpmark钉了它。

如果将来需要，我将使用经典编辑器插件。 如果将来需要，我将使用CPT和meta box compat标志。 但是我已经创建了数十个个人，企业和各种规模和规模的慈善机构/非营利组织。 我中有些人仍与他们保持工作关系。 其他人则继续前进，他们要么只是自己运行网站，要么与其他开发人员合作，或者根本不与任何开发人员合作。

期望代码更改或在需要它的每个站点上安装插件都是不现实的。

这真的是＃4423领土。

对于所有重要的对话，该票证都没有标签或所有者。 如果这不会发生，那么保持开放有什么意义吗？

gutenberg_can_edit_post_type （或任何在Core中称为的东西）和'__block_editor_compatible_meta_box' => false将退回到WordPress 5.0中的经典界面。 但是，未来的WordPress版本可能会改变这种行为。

gutenberg_can_edit_post_type仅标记是否加载块编辑器。 现在，不加载块编辑器时的默认行为是加载Classic，但是该过滤器的假设是，如果不加载块编辑器，则将提供自己的接口。 那可能是Classic Editor插件，也可能是自定义界面。 但是，将来的WordPRess版本可能会看到Classic代码将被移至Classic Editor。

__block_editor_compatible_meta_box标志也存在类似情况。 它现在回到经典界面，但是将来的WordPress版本可能会看到默认行为已更改为保留在块编辑器中，并显示警告信息，指示meta框位于何处。

当然，如果没有进行研究并没有联系网站所有者，这些更改都不会发生-我的观点是，这些设置主要是为了过渡到古腾堡而存在。 Classic Editor插件是用于强制使用Classic接口的稳定选项。

有关这些问题的更多讨论，请参见＃3902。

关于通知网站所有者的主题，WordPress 5.0将不会被释放。 我们可以使用许多工具来通知站点所有者即将发生的更改，并让他们知道其站点是否可以正常工作。 未来的WordPress 4.9.x版本将包含有关块编辑器的信息，正在计划收集有关插件兼容性的数据（自动和众包-＃4072），并且我们接受其他选择以确保网站所有者知道怎么了

对于所有重要的对话，该票证都没有标签或所有者。 如果这不会发生，那么保持开放有什么意义吗？

在进行讨论时，我将其保持打开状态没有问题，但是目前，我认为不需要将其保持打开状态。 为了解决原始问题，无法使用基于代码的选项来退回经典编辑器。

@pento为什么关闭此

通过关闭此窗口，您只是在证明不被听取社区意见。

我真的认为您应该重新打开它，以便我们可以对此进行解决。

解决方案不是-他们将无法启用禁用代码中的Gutenberg的方法。 您必须依靠插件。

对此完全不满意，但至少我尝试过。

解决方案不是-他们将无法启用禁用代码中的Gutenberg的方法。 您必须依靠插件。

那是在何时何地发生的？ 这里没有提及任何决定。

还是这只是假装倾听然后将其关闭的典型核心团队反应？

您目前想要哪种分辨率？

如果您想使用常数禁用古腾堡，那将不会发生。 我们已经被倾听并且这个想法被拒绝了。

在进行讨论时，我将其保持打开状态没有问题，但是目前，我认为不需要将其保持打开状态。 为了解决原始问题，无法使用基于代码的选项来退回经典编辑器。

来自@pento-这就是为什么它关闭

好吧，我希望他们至少在更新之前发布该插件，从而不会破坏用户体验。

我的意思是meta box支持在2.0中仍然被打破，我不确定它是否会在这一点上发挥作用。

该插件已存在： https :

回答@ smp303的原始问题。

1. 在wp-config.php中添加

define( 'ENABLE_GUTENBERG', false );

1. 在mu-plugins文件夹中名为my-hacks.php的文件中，您可能必须创建代码

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

道具@tomjn @wpmark

您今天无需安装Gutenberg或经典编辑器就可以执行此操作。
但是请注意，当代码合并到核心中时，过滤器名称可能会更改。
...到那时某人将在编写文档，然后您可以添加另一行。

注意：名为my-hacks.php是2003年引入的，不建议使用200x。
但是并没有阻止您将其实现为mu-plugins的必须使用插件。

如果要查看删除不赞成使用的代码有多么困难，包括与之关联的选项字段
参见WordPress TRAC＃33741-删除对my-hacks.php和hack_file选项的引用

甚至更容易...在wp-config.php中

$_GET['classic-editor'] = true;

我认为阻止的概念是错误的。 我认为，块应该是帖子。 因此，如果我们在一个帖子中需要多个内容，则必须能够拥有子帖子。 就像推特一样，页面由许多独立的推文组成。

在帖子内部，我们只需要一个文本编辑器。

我们没有预算来更新所有页面。 如果wp不提供长期兼容性，将来我们会在许多用途上更改为一个更稳定的社区，因为这将为新公司敞开大门。

现在，由于社区，WordPress变得很酷。 5.0表示从0开始。因此，与其他任何框架一样。

两条开发路线可能是一个好主意，而不是停用或不停用。 正常WP和古腾堡WP。 至少在接下来的5年中。 然后，像WP一样，古腾堡（Gutenberg）将有时间稳定并拥有一个社区。

如果您作为开发人员中的许多人有一个问题，为什么不直接进入并继续下去，那就太好了
Github附有一张票，提出了一种解决问题的可行方法，而不是无休止地写出为什么您不能用当前的Gutenberg项目构建解决方案。

利用您的编程技能来帮助解决问题。

我是一名视觉设计师，目前正计划帮助我的两个客户将编辑过程移至古腾堡。我目前正在为拥有20多年工作经验且无法维护的客户设计和建造一个新站点。

加入并帮助将WordPress.org作为站点构建工具向前发展。

@TomDesign您甚至尝试阅读讨论吗？ GB团队不希望该功能作为插件的一部分，因此，除非在“使您的编程技能来帮助解决问题”中表示您应该有人破解他们的帐户以添加他们不想要的代码，否则我不确定如何编写代码在这里甚至无关紧要。

@tomdesign我提出了在＃4981中制定可行的迁移计划的要求
我指出这将需要大量工作。 我觉得这是必要的。

我敢肯定，有很多开发人员希望能够使用我们的编程技能来确保顺利迁移。 但是我们不想浪费我们的时间来开发一些会被淘汰的东西。 我认为，迁移应按其本身的权利获得一个项目，并且对每个需求进行逻辑评估。 重要的是要有一个记录齐全的提案，从长远来看将使我们到位。

西蒙最初的要求是解决长期问题。
我相信内容迁移过程将持续数年。

嗨，大家好，
阅读评论，我认为这是分享有关Gutenberg的好插件的正确位置。
我想为您介绍一个免费的插件，该插件可让您管理Gutenberg编辑器。
它称为Gutenberg Manager，可让您启用/禁用各种帖子类型（包括页面和帖子）中的编辑器。 它具有更多功能，但我留给您。

我们已经阅读了成千上万的人抱怨WP 5.0核心中的Gutenberg的未来实现，这使我们找到了一个简单的解决方案。

Gutenberg Manager解决了此问题，并允许例如继续使用Elementor，Visual Composer，Siteorigin Builder或Cornerstone，即使在WP 5.0之后，也不会出现任何问题。
从WP.org的第一个用户反馈来看，该插件似乎已被淘汰:)

因此，我想向您介绍古腾堡经理-> https://wordpress.org/plugins/manager-for-gutenberg/

由于一些有用的钩子，开发人员可以在自己的主题和插件中使用该插件。 有一个隐藏在插件选项面板中的钩子，因此最终用户将不会在WP后端看到它（对于想要在其项目中包括Gutenberg Manager的开发人员来说，这是个很棒的功能）。

我们还与最著名的建筑商团队合作，以建立合作伙伴关系和协作关系。 通过这种方式，我们希望减少向古腾堡的过渡带来的创伤！

谢谢大家的关注，
做得好。

@unCommonsTeam我可以问一下，例如，在设置屏幕中选择了哪些选项时，如何禁用插件中的Gutenberg编辑器？

当然@wpmark ，

看看第79行-> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

最好

@unCommonsTeam感谢您回到我身边。 我可能在这里错了，但是看起来插件似乎只是删除了Gutenberg插件添加的所有内容。 这是我上面通过使用以下建议的内容：

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

但是， @ pento告知这不是一个可靠的解决方案，因为它确实使编辑器重新使用了WordPress。 参见https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

@wpmark是的，该函数删除了Gutenberg插件添加的所有内容，但仅在特定的后端页面中调用了该函数，而不是所有后端。 ..所以我认为这是可以接受的。

最好

@unCommonsTeam它看起来像一个很棒的插件，但我认为它会遇到与我的解决方案相同的问题，因为它确实需要将编辑器重新添加到WordPress中。

@pento的意思是删除了Gutenberg的附加内容，它只声明不需要块编辑器，但是您应该用某些东西替换它-这是经典编辑器插件的作用。

正如@pento所说：

该过滤器仅表示“不加载块编辑器”，并不表示“使用经典编辑器”。 它暂时可以使用，但不能保证将来可以使用。

因此，我认为（当然，我会得到纠正）您的插件比我上面的尝试做的相同（但当然要好得多，并且在灵活性方面有很多不错的选择）。

我在想的另一件事是，当项目被合并到核心时，古腾堡这个名字将被挂起，或者例如那些函数（例如gutenberg_init ）将被重命名为（例如） block_editor_init 。

@wpmark你是对的。 我们希望他们在WP 5中将经典编辑器留在那里。 但是，我们可以尝试通过插件添加一个选项以包括经典编辑器。 如果WP的开发团队决定删除经典编辑器，我们认为我们的插件将变得非常受欢迎:)

关于gutenberg的命名您是对的，可能我们将不得不修复插件以替换钩子名称。

此外，我们的插件还将提供基于Gutenberg编辑器的其他功能（启用/禁用特定模块，新模块等）。 因此，我们认为这对于使用Gutenberg编辑器的人也将是有用的。

干杯

这可能是一个好主意，它将解决几乎所有踩踏事件和辩论：

如果Gutenberg在核心中默认禁用默认选项，并且仍保留经典编辑器，则可以节省约10亿美元的WordPress主题和插件市场，并为广大互联网带来很多麻烦，金钱损失，支持事件，以及节省很多WP。以信誉和信任损失为平台。

古腾堡（Gutenberg），虽然是一个更现代的编辑器，但似乎是根据WordPress.com和使用WordPress提供博客/托管服务的类似商店的必要性而设计的。 这一切都很好。 但是，它不应该导致对整个生态系统的冲击和冲击。 互联网，人们的网站及其生计将受到当前方向的影响。

WordPress.com可以将Gutenberg默认打开，而WP则将其默认关闭，从而为整个生态系统提供最佳体验。

我必须同意Codebard的意见，即默认情况下将禁用gutenberg，并且继续保留经典编辑器。 正是由于这个原因，我目前已禁用自动更新-我不希望多站点网络上的博客作者突然看到这种“页面构建器”类型的编辑器，并且我当然不希望完全替换经典编辑器与古腾堡。

至少，我们应该能够使用define语句（例如define（'DISABLE_GUTENBERG'，true）;）禁用gutenberg。 使用插件禁用gutenberg的一个大问题是，我们将在需要时依赖开发人员来维护和更新插件。 在插件因开发人员正在休假或因其他原因而忙于更新插件而停止工作的几天或几周内，我们将做什么。 还有一个问题，使用该插件的人将不得不在其末端更新该插件。

似乎迫使古腾堡进入我们的行列，然后寻求解决方法以将其禁用，这是事后的想法。 请默认将gutenberg禁用。 我们中的许多人只想要一个简单的博客，就发现使用wordpress变得越来越困难，因为它似乎正在发展成为网站构建器。

另一个需要注意的是，在多站点网络的情况下，网络管理员应该能够决定是否应该在整个网络上使用gutenberg。

@ WebTrooper ， Classic Editor插件由WordPress开发人员团队（与维护Core相同的人员）维护，而Gutenberg Ramp由Automattic维护，因此两者都应不受“假期中开发人员”或“太忙”因素的影响。

请注意，VIP承诺使用Gutenberg Ramp插件，该插件已在我们的客户网站和我们自己的网站上使用。 度假或如果事情破裂太忙可能意味着客户站点损坏，这是VIP想要的最后一件事。

我还要指出的是，这些插件可以是分叉的，Automattic的，并且经典编辑器插件的作者和作者不具备使他们能够构建这些插件的任何秘密知识，而且它们在技术上也不大或复杂。 世界各地有数百家代理商，开发人员能够维护任一插件。

顺便说一句，许多人争辩说默认情况下禁用gutenberg，但是我注意到，不管这些论点有何优点，他们都没有说默认情况下确切地应该启用GB。 合理的结论是永恒的经典编辑情况。

到2934年，银河帝国已跃入系统，拥有300艘巡洋舰。 当地行星新闻网已经解雇了经典编辑，为当地居民撰写报道。 在他们开始建立网站之前，没有人告诉他们有关古腾堡的事情

我一直建议默认安装新安装。

但是对于现有安装，我建议使用一种用户主导的方法，允许人们选择加入Gutenberg，尝试一下，如果喜欢的话可以保留它，如果不喜欢的话可以恢复为经典编辑器。 如果/当人们切换回以帮助进行变更的开发和文档编制时，WordPress然后可以收集统计信息和反馈。

当达到一定数量的活动站点临界数量时，默认情况下可以启用它。 不，我不会随意挑选一个号码。 但是我们可以衡量使用情况并采取适当的行动。

另外，2020年4月12日也可以。 😉

这是在旧的PHP版本中发生的，对吧？ WordPress在向后兼容PHP 5.2方面一直不知疲倦，因为人们仍然使用它，在许多情况下可能都不知道或不关心。 WordPress正在仔细分析统计数据； 努力与主持人等进行协调； 并在升级过程中轻轻引导人们。 大概该项目将在某个时候对必须做出决定的使用数据起作用。

然而，有了一个全新的用户界面来进行编辑，哪些用户确实知道并关心该方法是将其强加给他们呢？

尽管在某些情况下我实际上已经开始倡导古腾堡，但我确实希望合并提案能够像我这样的人的关注，这些人为最终用户管理许多站点，其中许多人的IT技能很差。对技术没有信心，古腾堡会感到困惑和迷失方向。

我认为，由于以下重要原因，古腾堡也应该停止安装新产品：

• 基于现有的编辑器，几乎存在着无数的教程，资源，操作指南以及您可以想象的一切。 这些使人们非常容易地进入WordPress。

• 易于进入非常重要，因为因为这样就很容易上手，所以人们认识到“ WordPress很容易”，并容易对平台充满热情，对学习更多的态度更加接受和自信。

• 所有这些结合在一起，使人们对“ WordPress可行”感到满意，并将它们舒适地推荐给同行。 这就是我们能够增长到覆盖互联网的30％的方式。

• 信息的一致性很重要。 而且，互联网上的每一项资源都无法进行更新以反映古腾堡，甚至在未来也是如此。 这会造成很多混乱。 而且最不幸的是，普通用户的反应是“我安装了它，但它不起作用”，只是因为他/他找不到执行操作的方法，并且操作与他或她使用的教程看起来不一样。 没错，没有任何更新工作就可以消除对资源，教程等的困惑。

因此，Gutenberg应该是可选的并且可以切换，以不仅在主题，现有的页面构建器内置内容插件等方面，而且在我们在线资源方面都保持“向后兼容性”。 一个平台并非“如此简单”，当谷歌带来许多不同的过时和最新资源混合在一起时，您不能向人们说“只需安装它并由谷歌...”推荐它。 而且，如果您有任何搜索引擎优化的经验，您就会知道...

借助古腾堡（Gutenberg），我们可以挖掘据称正在上升的“网站建设者”市场（蜡像，方形空间等）和潜在的“简易博客”市场（如中号等）。 但是，如果我们在此过程中仅打破互联网的30％或约10亿美元的主题/插件市场，那将是巨大的冲击，而十年之内我们可能无法恢复。

您无法安装经典的PHP插件，因此与PHP的比较并不重要，因为有数百万个站点可以保证被破坏，没有基于WP的解决方案可以解决这个问题，因此请仔细分析。 还请记住，下一个发行版会提示您安装经典插件，而不仅仅是提示用户安装Gutenberg插件。

无论哪种方式，此问题都已关闭，已做出决定。 一个封闭的问题是尝试更改其他地方计划的方法的不佳之地。

但是请记住，古腾堡是可切换的，有一些用于启用和禁用它的插件。 自GB诞生以来已经有好几年了，到目前为止，有足够的时间进行测试，有时间培训客户，有时间安装经典的编辑器插件，等等。这并不是一夜之间强迫人们的新事物

我注意到，无论这些参数的优点是什么，它们都无法说明默认情况下确切应何时打开GB。

而且，看来，即使提出这些论点的人对何时应该发生提出了一些建议，也还是会被驳回。 那么为什么要提出来呢？

我知道封闭票的工作方式。 您在这里made讽了一下。 因此，我试图提供一些建设性的回应。

@tomjn我会回声@rosswintle这里说是的，我们建议它应该只是默认情况下为新安装上- https://github.com/WordPress/gutenberg/issues/4423。 这是另一个未解决的问题，没有真正讨论该问题而已结束。

他们不愿意听，有一个插件，等等等等，这是封闭的。 一无所有在这里看到。 关于.com的全部内容没有人关心.org，那里没有自动钱。

@ smp303您能否确定他们是谁？

@rosswintle Gutenberg 0.1.0是在14个月前发布的，意味，而避免在5.2上运行的站点破裂的唯一方法是支持它们并尝试使其升级。 网站的“发布”编辑屏幕可能因古腾堡而中断，可以安装经典编辑器插件而无需更改服务器级别，因此比较不公平

他们不愿意听，有一个插件，等等等等，这是封闭的。 一无所有在这里看到。 关于.com的全部内容没有人关心.org，那里没有自动钱。

我必须同意。 无论是在此处还是在WordPress支持论坛中，尽管社区中有很多人对此表示反对，但他们似乎根本不在乎。 由于WordPress是开放源代码，因此我建议任何人就此事创建请愿书。 我个人认为并建议GB应该像Jetpack这样的插件，而不是将其合并到核心中。

旁注： @karmatosed由于您无法在WordPress论坛中有关古腾堡（Gutenberg）的评论之一中答复和回答我的问题，我不知道为什么我的评论突然消失了。 好身手！

从讨论为什么没有禁用Gutenberg的基于代码的选项开始，这个话题已经转变为来自sockpuppet帐户的隐式或直接人身攻击。

我赞赏一些人对此主题充满热情，很遗憾，这个话题已经走了，但决定不会改变。

Classic Editor插件是用于在整个站点上恢复为

如果您是网站建设者，希望从块编辑器中退出客户，则安装Classic Editor插件（并提供bug报告或修复程序）是确保经典编辑器继续可用的最佳长期解决方案。

对于metabox，已经可以选择退出块编辑器，此API将合并到Core中。 对于CPT， gutenberg_can_edit_post_type过滤器在合并时将重命名（可能是block_editor_can_edit_post_type或类似性质的东西），但也可以作为基于代码的选项使用。

为避免此线程进一步发展，我将其锁定。

绝对欢迎参与此讨论的每个人继续参与为Gutenberg准备WordPress 5.0的准备，但是请注意，绝对不欢迎人身攻击，这将导致问题被锁定或帐户被禁止。