Gutenberg: 古腾堡推出时间表的经济影响

很棒的帖子布里奇特，谢谢你写这篇文章。 它呼应了我的担忧。

我曾经为一家公司工作，到我离开时，该公司拥有 400 多个带有自定义主题的 WordPress 站点（使用内部框架构建），并且在长达数年的时间里从较旧的 CMS 迁移了约 200 个除了新的构建。 虽然像这样的公司无疑正在密切监视 Gutenberg 并做好准备，但我想开发人员的大部分时间将花在安装一些东西来禁用它上，而不是试图让 400 多个站点与 Gutenberg 一起工作。

我自己管理 30 个站点，这就是我要做的，然后我会在以后查看每个站点，看看哪些站点可以轻松更新，然后尝试找出如何处理其余站点。

根据站点的复杂性，开发人员根本无法为现有站点花费大量时间，因为除非客户特别要求升级他们的主题以适应古腾堡，否则我们无法收取费用。 我们围绕向后兼容性构建我们的维护定价结构，这一直是 WordPress 的优势，而这让我想起了我目睹的同事在以前的角色中工作的漫长的 Drupal 6 到 7 迁移 - 不同之处在于 Drupal 一直都是这样所以合同和定价结构反映了这一点。

我的合同中有一个条款，如果一个站点不再与最新版本的 WordPress 或插件兼容，它将继续在最后一个兼容版本上运行，直到找到解决方案。 我从没想过我需要为 WordPress 本身使用该条款。

另一方面，有些用户使用免费或商业制作的主题 DIY 自己的网站，这些主题依赖于元框和短代码，如果 Gutenberg 不是明确可选的，这些网站会在某些时候突然中断。 当然，这对于保留来说会很糟糕。

我想开发人员的大部分时间都会花在安装一些东西来禁用它上

正是我的想法。

我看过经典编辑器插件，用户仍然需要勾选一个框才能完全删除古腾堡。 因此，我要么将其分叉并将其安装在我客户的站点上，要么只是在 5.0 下降之前将版本设置为 499.x。

然后我可以在我自己的时间将我的客户迁移到 Grav、Kirby 或我喜欢的任何其他东西，因为我们都知道大多数客户真的不关心他们的网站运行的是什么 CMS！

@doubleedesign有这个条款是件好事。 我会尽早开始教育您的客户群，以便您可以让他们习惯这个想法。

@senlin Piet，

你是说你可以离开 WordPress？

@吉吉布里奇特，

我正在认真地研究其他 CMS，并且已经将几个站点与 Grav CMS 放在一起。

所以，是的，你确实可以说，当古腾堡在 WP 5.0 中下降时，我有 50% 以上的机会会下降 WP。

还有其他需要考虑的事情：

如果您现在正在登陆一个中型项目，如果您选择WP，您肯定会使用ACF构建，那么您真的会选择WP吗？

我知道我不会。 我宁愿有学习曲线，也不愿在 4 个月后告诉客户我开发的网站不能再编辑或不能更新了。

这就是我所害怕的——大规模的。

我很欣赏你的诚实，一点也不怪你。 这是一种营销
确定的问题。

在 2017 年 12 月 11 日星期一下午 2:41，Piet Bos [email protected]写道：

@gidgey https://github.com/gidgey Bridget，

我正在认真地查看其他 CMS，并且已经整理了一个
几个带有 Grav CMS 的站点。

所以，是的，你确实可以说我有超过 50% 的机会
当古腾堡在 WP 5.0 中下降时会下降 WP。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350882640 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AV3JZs__wiuV2FslRNQMRkxvCoRKWnEJks5s_a-kgaJpZM4Q93ul
.

——
手机 949 370 4059
www.bridgetwillard.com

这正是我一直在与我的朋友和客户谈论的内容。

叹。 感谢您的反馈，皮特。

2017 年 12 月 11 日星期一下午 3:01，Piet Bos [email protected]写道：

还有其他需要考虑的事情：

如果你现在正在登陆一个中型项目，你肯定会
使用 ACF 构建 如果您要选择 WP，那么您实际上会选择 WP 吗？

我知道我不会。 我宁愿有学习曲线，而不是告诉
客户在 4 个月内无法再编辑我开发的网站或
不能再更新了。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350887165 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AV3JZrxdz6HgF-9vGrhvZPC5Bi7prd2Nks5s_bQ7gaJpZM4Q93ul
.

——
手机 949 370 4059
www.bridgetwillard.com

如果您现在正在登陆一个中型项目，如果您选择WP，您肯定会使用ACF构建，那么您真的会选择WP吗？

一些背景故事：我的职业生涯始于初级 Drupal 开发人员，并为我自己的客户学习了 WP。 我的下一份工作是 100% WordPress，所以虽然我想留在这两个生态系统中，但实际上长话短说，主要坚持使用 WP 更有意义。

吸引我使用 ACF 的第一件事基本上是它把我喜欢的 Drupal 的一些东西——在后端轻松指定内容类型字段的能力——带入了 WP。 这有很多用途。 客户很容易用他们的内容填写表单，而不必担心格式和布局，然后我用模板控制显示。 这是我建立网站的基础。

因此，如果我不能再像这样构建并且 Gutenberg 不适用于我的客户（我已经可以想到一些讨厌它的人，因为他们不想考虑格式或布局，那是我的工作）然后不，在某些情况下，我不会选择 WP。 我可能会回到 Drupal。 不适合所有人，甚至可能不适合大多数人 - 我仍然会使用 WP - 但绝对适合某些人。

谢谢你填写我们，Leesa。

我的假设（和希望）是 ACF 插件会转换。 但它开着
他们来制作他们的街区，而不是在 WordPress Core 上。 我想他们是
在投资太多之前也在等待古腾堡的“船舶”版本
资源（时间和金钱）。 这就是我会做的。

2017 年 12 月 11 日星期一下午 3:10，Leesa Ward通知@ github.com
写道：

如果你现在正在登陆一个中型项目，你肯定会
使用 ACF 构建 如果您要选择 WP，那么您实际上会选择 WP 吗？

一些背景故事：我的职业生涯始于初级 Drupal 开发人员并学习了 WP
一边为我自己的客户。 我的下一份工作是 100% WordPress，所以虽然我
想要留在这两个生态系统中，长话短说实际上它使更多
感觉主要是坚持使用 WP。

吸引我加入 ACF 的第一件事基本上是它带来了
我喜欢 Drupal 的一些东西——为内容指定字段的能力
在后端轻松键入 - 进入 WP。 有这么多用途
这个。 客户很容易用他们的内容填写表格，而无需
不必担心格式和布局，然后我控制显示
与模板。 这是我建立网站的基础。

所以如果我不能再像这样建造而古腾堡对我不起作用
客户（我已经可以想到一些讨厌它的人，因为他们不
想考虑格式或布局，那是我的工作）然后不，我会
在某些情况下不要选择WP。 我可能会回到 Drupal。 不是为了
每个人，甚至可能不是大多数人 - 我仍然会和 WP 一起工作

• 但绝对适合某些人。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350889174 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AV3JZmN-TRB-9rQgHSqACUhcz9CqdOl-ks5s_bZtgaJpZM4Q93ul
.

——
手机 949 370 4059
www.bridgetwillard.com

我的假设（和希望）是 ACF 插件会转换。

是的，绝对，我相信它会，这就是为什么我不会立即，仓促地将所有事情都跳回 Drupal ;) 与 WooCommerce 真的没有什么不同，它已经成为生态系统的支柱。

但是，它仍然令人担忧，因为开发人员需要时间来使 ACF 兼容。 这意味着那些大量使用该插件的人在转换之前无法转换现有站点。 这可能会使已经很短的时间线变得更短。

我完全同意古腾堡至少一年是可选的建议。 这使插件开发人员有机会彻底地使他们的插件兼容，并让开发人员有时间整合这些更改并教育客户。

此外，对于由于成本/时间限制根本不会转换的网站，应该有一个选项（例如通过经典编辑器插件）关闭古腾堡并在此之后保持经典编辑器更长时间. 中小型网站的保质期意味着在几年内客户可能想要重新设计，然后他们会在那个时候得到古腾堡。

@doubleedesign Leesa 在这里提出了一个很好的观点：

他们 [客户] 不想考虑格式或布局，那是我的工作

这也是让我生气/失望的事情之一！ 有页面构建器是一回事。 显然，这是有市场的，但这不是我的市场，也不是我的客户的市场。
那么为什么现在每个人都被推入 WP 成为页面构建器？ 并且使用短语 _democratizing publishing_ 因为它并不能使它正确。

当我为客户建立网站时，他们是高度定制的，他们完全按照客户的意愿行事。 我的客户在编辑内容时不会犯错误，因为（使用 ACF）我创建了一个没有错误余地的后端体验。

我正在观看@mor10的演示，他提到主题开发人员可以引导用户浏览内容。

过去几年我已经这样做了！！！ 没有古腾堡！

我在 2005 年开始使用 WP，从那以后一直很开心地使用它。 我开发了许多插件，其中一些插件比其他插件更受欢迎，并且开发了一个让我远离街头的专业。

正如我经常告诉我的客户一样，网站世界一直在运转，我想我在 WP 上花费的时间已经接近尾声，新的前沿领域对我来说即将到来。

我只是不喜欢它结束的方式，但话说回来，有时候分手比让它慢慢死去更容易……

有页面构建器是一回事。 显然这是有市场的，但这不是我的市场，也不是我的客户......

我的客户在编辑内容时不会犯错误，因为（使用 ACF）我创建了一个没有错误余地的后端体验。

@senlin ，就像你在读我的想法！ ;)

有页面构建器是一回事。 显然这是有市场的，但这不是我的市场，也不是我的客户......

我的客户在编辑内容时不会犯错误，因为（使用 ACF）我创建了一个没有错误余地的后端体验。

@senlin ， @doubleedesign ，这里完全一样。

古腾堡无疑是一个有趣且雄心勃勃的项目，但对我 99% 的客户没有任何用处。

我已经使用 WordPress 10 年了，从一开始我就参与了法语社区，但这一次，由于你提到的所有原因，这是第一个让我害怕的版本......

我想按照目前的计划对时间表提出一些看法。 我说计划是因为当我们向 5.0 迈进时，社区、5.0 领导和核心团队将共同努力找出合并的路径。 请注意，它尚未合并，预计至少有 11 个版本 - 1 个刚刚发布。

值得注意的是，所有版本都有一个候选发布阶段，5.0 也不例外。 另外值得一提的是几个人都有的，很长一段时间都会有经典编辑器插件的选项，甚至网络激活它。 该插件在 5.0 版本中不会出现任何地方，并且可能会保留很长一段时间，经典编辑器本身仍在维护中。

自定义字段不会被遗漏，有一个很棒的插件正在开发中，这里有一篇文章： https :

Metaboxes 有一些潜在的升级途径，现在它正在解决其中最好的问题。 系统将如何默认以及用户体验将如何。 没有什么是一成不变的，一切都在为最佳用户体验而努力。 用户是各种类型的人——真正写作的人、主题创作者、插件制作者等等。

我知道改变是艰难而可怕的，我们都感受到了。 我知道，你知道，而且当我们不能完全理解变化时情况会更糟。 我会向人们指出wordpress.org/gutenberg作为了解该项目的起点。 我说的起点是从那里你可以去手册：wordpress.org/gutenberg/handbook。 例如，以下是我认为很重要的兼容性部分：

古腾堡项目正在积极解决兼容性问题。 块是用于构建内容功能的事实上的新机制，我们建议开发人员迁移他们提供的由块很好地封装的任何功能。 但是，将保留对现有 WordPress 功能的支持，并且将提供短代码、元框和自定义帖子类型的转换路径：

简码。

• 将继续工作而不作任何更改。
• 有一个新的“短代码块”来帮助插入它们。
• 有一个计划的机制来预览它们。

元盒。

• 有些将在新 UI 下继续工作而不会发生任何变化。
• 有些需要更新（尤其是那些依赖 DOM 进行操作的）。*
• 有几个可以转换为原生块（尤其是那些在前端渲染的块）。
• 有些可以过渡到内容区域之外的新古腾堡原生扩展点。
• 将有一种机制让冲突的元框加载经典编辑器而不是通知。

自定义帖子类型。

• 得到古腾堡的支持。
• 需要 REST API (show_in_rest) 声明。
• 可以通过不声明“编辑器”支持来选择退出。
• 将能够声明受支持的和默认的块。

• 某些依赖于当前编辑屏幕特定结构的元框不能保证在 Gutenberg 下工作，并且可能需要更改才能正确加载。

我鼓励大家在我所说的内容中考虑哪条道路适合您的特定设置。 每个人可能想要或需要对古腾堡采取不同的方法。 关键是在第一天没有人期望你制作块。 如果人们有，那将是惊人的，但现实是，您可以选择慢慢升级。 需要进行大量的文档、教育和讨论。 这很好，因为整个社区都参与其中并且可以做到这一点。

最后，请不要害怕。 WordPress 是一个社区，虽然像这样的话题看起来很可怕，但古腾堡不是，参与该项目的任何人都不希望你感到害怕。 那些让古腾堡关心的人，那些在社区里关心的人。 WordPress 是一个很棒的项目，它真正尊重人们正在制作的很棒的东西。 我鼓励您找出最适合您的路径，然后探索、享受乐趣并为积木感到兴奋。 制定您的计划，然后看看如何从那里建立起来。

如果您对古腾堡有任何疑问，在任何情况下，chat.wordpress.org 上的#core-editor 频道都随时为您服务。 您还可以在该频道中观看正在进行的工作，并在星期三的 UTC 时间 18:00 观看每周会议以及通常的聚会。 让我们在前进的道路上共同努力。

@karmatosed塔米，

Metaboxes 有一些潜在的升级途径

事情是在 GB 之前我的 metaboxes 很好很花哨。 他们可能在我不再管理的站点上处于活动状态。 我几年前开发的那些网站的客户呢？ 突然之间，他们的网站内容不再可编辑。

我知道改变是艰难而可怕的，我们都感受到了。

这些类型的评论是不必要的，因为它们看起来真的是居高临下和傲慢的！ 在我看来，让人们阅读大量尚未完成且仍在进行中的文档是荒谬的。
一种。 我没有时间做那个和 b。 这个讨论不是关于理解GB 而是关于古腾堡推出时间表的经济影响

关于短代码、元框和 CPT 需要做的事情的列表，表明它比我想象的还要糟糕。

如果不声明show_in_rest CPT 将不再起作用？！？！？！ 所以我现在应该回到客户的网站并重做 3-5 年的工作？

塔米，这正是@gidgey (Bridget) 在这篇文章中提出的经济影响！ 您似乎无法理解这一点充其量是可怕的，尤其是因为您是 GB 的一员和布道者！

@karmatosed感谢您的详尽回复。

很长一段时间内都会有经典编辑器插件的选项，甚至网络激活它。 该插件在 5.0 版本中不会出现任何地方，并且可能会保留很长一段时间，经典编辑器本身仍在维护中。

对于在可预见的未来将使用经典编辑器的网站，是否需要在 5.0 推出之前安装？ 在这些情况下，对我来说最理想的是古腾堡永远不会打开，可以这么说 - 不是我匆忙登录我的所有网站将其关闭。

我知道改变是艰难而可怕的，我们都感受到了。

” 这个线程不是Stewie Griffin 的声音“房子出了问题！我不喜欢改变！” 事物。 这是关于它的速度。 你说你不希望任何人在 5.0 发布时构建块......但如果没有干预，站点后端将具有该界面，需要更改开发中的新站点或计划升级； 正在计划/范围内的新网站将在他们的计划上留下一堆问号。

此外，拥有现有站点但没有维护计划或活跃的开发人员的客户可能会感到困惑，如果他们的站点出现故障，就会生气。 IT 部门将收到他们一无所知的支持请求，开发人员将接到愤怒的过去客户的电话。

所有这些都将占用每个人的大量时间。 我知道 Gutenberg 已经处于测试阶段了一段时间，但这与能够在真实网站上与真实客户一起使用它来确认我们的网站和我们的客户的真正问题点是什么不同。

会有选项供你慢慢升级

缓慢的过渡需要成为默认和期望。 这可能已经被建议了，但升级到 5.0.0 时肯定会出现“请选择您的编辑器”提示。 这对于没有活跃的开发人员/维护人员而担心变化的客户特别有帮助。

@senlin

塔米，这正是@gidgey （布里奇特）在这篇文章中提出的经济影响！ 您似乎无法理解这一点充其量是可怕的，尤其是因为您是 GB 的一员和布道者！

对开发者担忧的默认反应似乎是“但古腾堡太棒了！！！” 现在，我不在乎它有多棒，我会在适当的时候通过在发布后正确使用它来发现这一点。 现在，我关心的是我目前维护的 30 多个站点以及我目前正在开发的少数​​站点会发生什么以及我需要做什么。

用户是各种类型的人——真正写作的人、主题创作者、插件制作者等等。

@karmatosed这也有点居高临下，无助于一些开发人员目前的疏远感。 我们知道我们不是唯一的用户。 事实上，在这个帖子中已经有评论表达了我们对实际写作的一些用户的影响的担忧，因为他们是我们的客户。 我们不仅仅是关于我们想要如何编码（尽管这是它的一个元素，但与本主题无关）。

@senlin让我们从意图的指责继续前进，我们都关心这里发生的事情，尊重很重要。

我分享我所做的事情是为了通知，而不是为了光顾。 重要的是要注意我看到了这次讨论的价值，我参与了并且我在这里参与。 我也确实看到了线程的要点。 我的感觉是，共享我们现在拥有的资源对于制定路径很重要。

让我们从这一点开始，深入回复您的评论：

我几年前开发的那些网站的客户呢？

这就是我添加文档引用的原因，以显示正在处理的潜在后备。 这将取决于元框，但可能会发生这种回退。

对于从事此工作的人来说，值得注意的一件事是，分享您正在考虑的示例很重要。 这有助于双向对话。

@doubleedesign ，也感谢您的回复。

对于在可预见的未来将使用经典编辑器的网站，是否需要在 5.0 推出之前安装？

今天确实需要打开经典的编辑器插件。 这意味着让它在 5.0 的那一天上线。

我完全会鼓励人们今天尽可能在网站上尝试古腾堡。 通过尝试，可以将错误、问题和反馈发送给从事此工作的人。 这对于进行这两种方式的讨论至关重要。

_这将取决于_metabox，但后备_可能_是会发生的。

。。。

这将取决于元框，但可能会发生这种回退。

诚然，我自己没有参与过这种规模的软件项目，所以我不知道这是否正常，但我对所有在即将发布时似乎仍然不确定的部分感到紧张。

@doubleedesign只是为了清楚

我们知道我们不是唯一的用户。 事实上，在这个帖子中已经有评论表达了我们对实际写作的一些用户的影响的担忧，因为他们是我们的客户。

我是说这是关于每个人的体验，开发人员，设计师，用户。 我想确定这一点，因为我觉得它被误解了。 我说的是所有问题，而不是完全不考虑开发人员的经验。

总结一下我说的：

• 当 5.0 发布时，事情不会坏。 有一些选项可以避免这种情况。 可以添加更多选项。
• 为了确保事情不会中断，需要反馈。 测试，告诉团队问题出在哪里以及哪些设置有问题，是必不可少的。 这并不是说从事这项工作的人没有进行测试，只是存在每个单一的压力情况，没有人知道。 双向沟通是关键。
• 古腾堡如何发货是 5.0 的详细信息。 团队现在专注于产品、获取反馈、响应和迭代。 这并没有否定任何事情，但这就是 5.0 的领先地位，社区介入的地方； 弄清楚古腾堡是如何发货的。

@karmatosed

当 5.0 发布时，事情不会坏。

这是保证还是只是总结您所说的话而没有任何附加价值？

@gidgey我认为中期的一个潜在解决方案是这个众包网站，用于获取和提供帮助将产品过渡到古腾堡： https :

我意识到这主要解决了潜在的症状，而不是您的总体担忧。 从纯粹的哲学角度来看，我想知道我们是否低估了这个社区所吸引的那种人的适应能力。

我无法预测未来（尽管它是我对超级大国的愿望清单的首位），但您是对的，这将产生巨大的经济影响。 我认为我们必须睁大眼睛进入这一变化，并感谢您在这里公开表达您的担忧以供讨论。 像这样的对话可以帮助我们命名我们的恐惧，以便我们尽可能地解决它们。 🤗

没错，约瑟法。 我的意图不是散布恐惧，而是意识。

也感谢 Piet 和 Tammie 的评论。

这是一个伟大而急需的讨论。

2017 年 12 月 12 日，星期二，上午 8:16，josephahaden [email protected]
写道：

@gidgey https://github.com/gidgey我认为也是一个潜在的解决方案
中期是这个众包网站，用于获取和提供帮助
将产品过渡到古腾堡： https :

我意识到这主要是针对潜在的症状，而不是针对
你最关心的问题。 从纯粹的哲学角度来看，我
想知道我们是否低估了这种人的适应能力
社区吸引。

我无法预测未来（尽管它是我的超级愿望清单的首位）
权力）但你是对的，这将产生巨大的经济影响。 我认为
我们必须睁大眼睛进入这种变化，谢谢你
在这里公开表达您的担忧以供讨论。 是对话
像这样帮助我们命名我们的恐惧，这样我们就可以尽我们所能解决它们
能够。 🤗

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-351101104 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AV3JZpL52P_idTCVbWhTT9qAnAnHjgfyks5s_qbegaJpZM4Q93ul
.

——
手机 949 370 4059
www.bridgetwillard.com

如果不声明show_in_rest CPT 将不再起作用？！？！？！ 所以我现在应该回到客户的网站并重做 3-5 年的工作？

我的理解是相反； 默认情况下，未明确声明show_in_rest CPT 不会使用 Gutenberg。 Gutenberg 使用 REST API 来获取和保存发布数据，所以如果 CPT 不支持 REST API，那么 Gutenberg 就无法使用它。

因此，大约 95% 的 CPT 将默认使用经典编辑器，无需任何更改。

https://github.com/WordPress/gutenberg/blob/9864a6092a965d2985307ed2456f83148a1dee78/lib/register.php#L303 -L338

默认情况下，未明确声明 show_in_rest 的 CPT 不会使用 Gutenberg。

这实际上是 API 中的一个“错误”，因为任何带有"show_ui" => true CPT 都应该能够在 Gutenberg 中进行编辑。 我希望在合并之前解决这个问题。

@iandunn这对古腾堡的未来发展来说是一个巨大的问题，因为古腾堡不应该只是一个编辑器的替代品，而是一种管理视图的全新方式。 如果 CPT 阻止了 Gutenberg，Gutenberg 就无法超越编辑器。

我在这里完全同意，对我来说问题不是改变。 如果我们不改变或继续前进，我们仍然会停留在 WordPress v1 上，这在当时很了不起，但远没有我们现在所拥有的那么好。

令人担忧的是推出的时间。 我们被告知古腾堡将在 2018 年初的某个时候推出，这非常令人担忧，在我看来还为时过早。

WordPress 中的大多数项目（考虑到 REST API）在被引入核心之前是几个月甚至几年的插件，我们甚至不是用户真正会注意到的插件。 这是我记得的第一个重大发展，它将对 WordPress 的每个用户产生巨大影响。 无论您是开发人员、设计人员还是内容编辑人员，它都会以某种方式影响您。

为了减轻这种影响，并使过渡更平滑，我们只需要更多的时间。 现在，就像这个帖子中的大多数人以及我认识的 WordPress 社区中的许多开发人员一样，我们使用 ACF 等工具来构建根据客户需求定制的站点。 要在这么短的时间内做同样的事情，我需要使用 Javascript 和 React 学习一门全新的语言，这在 4 到 6 个月内是不现实的。

这里的许多主题都告诉我们阅读文档并了解有关古腾堡的所有信息。 并不是说我不愿意学习 Javascript、React 和 Gutenberg - 我很乐意，而且如果您打算在 WordPress 中构建一些新的东西，那似乎是要走的路。 然而，就像这个线程中的许多人一样，我有一项业务要经营，当前的客户要照顾，实际上我无法在如此短的时间内学会这一点。 我只是没有时间。

我真的很担心当 WordPress 版本 5 登陆时客户网站会发生什么，我预计会有很多不满意的客户。 当然，我们还没有到那里，我希望古腾堡的 WordPress 版本 5 的道路是顺利的。 不过，我必须承认，我听到的并不是很多让我相信情况会如此，而且信息不一。

社区中从未出现过如此分裂的问题。 我们被告知不要担心，但没有确凿的证据支持这一点。 我只希望它比我预期的更顺利。

大胆思考，但我想知道人们是否会在他们认为 5.0 发布时有不同的时间。

我对餐巾纸的想法是：

古腾堡继续每周定期发布插件（有一个当之无愧的假期），直到四月初左右。

然后，Gutenberg 将被提议并入 Core。 这可能需要至少一周的后勤工作，可能需要 2 周。 然后我们将看到四月中旬。

在功能项目合并后的过去版本中，在 Beta 1 发布之前有一周的时间。 我要说 4 月 25 日（同样，这是我的想法，而不是确定的时间表）。

这种规模的发行版可能至少需要 4 个测试版，但我认为 5 个在这里可能更安全。 所以我们会说在我们到达 RC1 之前是 5 月底。

一个为期 3 周的 RC 期来消除任何边缘，将在 6 月 19 日左右发布，这距离古腾堡在 2017 年 WCEU 世界首演仅一年左右（忽略在那之前正在进行的工作，并且帖子已经在 make.wordcamp.org/ core 几个月前概述了一些早期工作）

当我考虑到我们基本上处于 API 稳定点这一事实时，这有超过 6 个月的时间来准备。 显然，近期内需要更多文档来帮助人们更轻松地在 Gutenebrg 上构建，但这基本上是准备瀑布类型的 2 个季度，或者为更敏捷的人准备 13 个 2 周冲刺。

_从 AWP Facebook Group 中加入_

我同意教育的必要性。 但是 - 作为开发人员/网站创建者，我们不会花很多时间在几个现有网站上测试古腾堡。 如果您有一个已经完成的站点的临时站点/本地站点，只需在其上安装 Gutenberg 并进行测试。 我可能花了半个小时在 3 个站点上测试古腾堡（我在这些站点上更新了 WordPress 和所有插件）。 使用 Beaver Builder 的页面非常适合页面，只要我使用 Beaver Builder（这是完全合理的做法）并且帖子（没有构建器）开箱即用。
其他两个站点大量使用 ACF，我发现元框目前没有保存。 还没弄明白，我可能会在有时间的时候在 GitHub 上报告（我看到这个主题已经有几个问题了）。

我个人相信核心团队和所有在 Gutenberg 上非常努力的贡献者，当 5.0 出现时，它将在所有网站中的很大比例上开箱即用。 据我所知，目标不是破坏大多数在 WordPress 上运行的网站。
但是，我们确实必须通过至少报告我们在此过程中遇到的任何不兼容性来回馈社区。

另外，我不能完全同意“它会花费很多”的观点。 什么会？ 安装经典编辑器插件？ 如果您与客户签订了支持协议，那么作为 5.0 更新的一部分，您还要安装 Classic Editor 插件。 繁荣！ 你完成了 ：）
如果您没有支持协议，请花一天时间（或无论您需要多少时间 - 您有几个月的时间）来创建您为其构建网站的过去客户的列表。 发送给你自己和 Bcc 每个人，并按照以下方式写一些东西

嘿，我只是想给你一个关于 WordPress 5.0 的提醒，它计划于，将围绕发布/编辑体验进行重大更新。 因为这是一个真正的重大更新，它可能会对管理您网站的内容产生潜在的负面影响。
不要绝望！ 有一个非常简单的解决方案，它仍然可以让您安全地更新 - 只需安装并激活“经典编辑器”插件。 这将确保您继续使用与习惯相同的界面。
与往常一样，我建议您在临时站点上进行这些更新，或者至少在更新 WordPress 之前备份您的站点。
如果您想了解有关即将发布的更新的更多信息，请随时在此处阅读

如果您需要任何帮助，我很乐意提供帮助。
此致，

繁荣！ 你完成了。 是的，此时您可能需要回复一堆询问，但这只会巩固您客户的满意度。 他们会看到您关心他们和他们网站的福祉，即使在您完成之后也是如此。 如果你不想提醒你的客户，那就不要，对我来说这是值得的。

我没有在 Facebook 上发表的一些想法：

• 在更新到 5.0 之后创建一个指针（这就是他们的名字，对吧？）是个好主意，它告诉人们有关古腾堡的信息，并且他们可以安装经典编辑器插件来恢复他们的旧用户界面。 这可以显着减少急于谷歌/开发者/支持/等的沮丧的人数。 求助。
• 任何声称他们必须改变他们目前为开发自定义 WordPress 网站所做的一切的人 - 请理解情况并非如此。 在最糟糕的情况下，您只需要安装一个插件（或将等效代码添加到您的主题/插件中）就可以了。
• 对于任何说没有足够时间进行调整的人（甚至是插件作者）-拜托，还有 4 个多月的时间。 古腾堡不是在幕后工作的东西，会在没有警告的情况下被扔到每个人的头上。 同样，如果您现在进行测试，您就会知道是否需要进行任何更改。 如果某些事情不起作用 - 通过创建问题来做出贡献。

最后...

请，请，请 - 善待所有贡献者。 我知道巨大的变化令人沮丧，但让自己站在古腾堡的贡献者的角度，或者站在它的背后。 如果成千上万的手指指着你说“你做的不好，你应该感觉不好。我们不想要你的创新”，你会有什么感觉？ 与贡献者合作，而不是对抗贡献者。 帮助他们找到他们不可能偶然发现的所有代码/插件/主题组合。 帮助每个人更轻松、更好地过渡。 回馈社会：心：

和平出来 :v:

@senlin

我正在认真地研究其他 CMS，并且已经将几个站点与 Grav CMS 放在一起。

那么，您愿意花时间学习另一个 CMS，而不是安装一个只保持体验原样的插件吗？ 您确实明白，任何不是您唯一开发者的东西，在未来的某个时候可能会做出您不喜欢/不同意的选择，并使您陷入同样的​​境地？ 你当然可以随心所欲地做，对我来说这似乎是一个不合逻辑的决定，考虑到我所理解的情况（也许我们只是理解不同？）。

如果不声明show_in_rest CPT 将不再起作用？！？！？！ 所以我现在应该回到客户的网站并重做 3-5 年的工作？

就像现在一样，如果您的 CPT 没有声明show_in_rest ，它将默认为标准编辑器（因此您甚至不会通过在您的 CPT 中编辑帖子来知道 Gutenberg 已安装）。 但是正如@youknowriad上面提到的，这应该在将来修复，以便show_in_rest show_ui在丢失时默认为

您是否有机会使用您之前建立的网站之一测试古腾堡？ 如果没有，我强烈建议您在开发站点上安装它，以便您更好地了解什么对您的设置起作用，什么不起作用。

@nikolov-tmw 尼古拉，

所以，你愿意花时间学习另一个 CMS

确实是的！

但不安装一个插件来保持原样？

体验究竟能保持多久？

你当然可以随心所欲

哇，谢谢，我真的需要你的许可！

也许我们只是理解不同？

大概

您是否有机会使用您之前建立的网站之一测试古腾堡？

事实上，我已经在几个站点上安装了它

如果没有，我强烈建议您在开发站点上安装它，以便您更好地了解什么对您的设置起作用，什么不起作用。

谢谢假设！

我想最终，经济影响完全取决于您（为客户）建立网站的方式。 您提到了 Beaver Builder，我之前已经提到过（向上滚动）页面构建器不是我使用的或我的客户想要的。 所以你在这里比较的是两种不同的东西。

切换到古腾堡对我的经济影响如此之大，以至于我确实宁愿完全改用不同的方式来构建网站。 感谢您的理解和尊重！

这里有很多很棒的点。 我几乎同意所有这些。 我认为真正的解决方案是让核心 Wordpress 实现古腾堡作为一个选项。 让我们能够选择使用 Tiny MCE 编辑器，而无需安装插件。

我理解双方。 机会和担忧。 我不知道古腾堡是否会吸引新的 WordPress 用户或冒犯现有用户。 但作为一名开发人员，我不得不说，我所读到的关于古腾堡成为 WordPress 核心一部分的方式似乎是错误的。

我在这次谈话中缺少@m 。 过去关于向后兼容性的讨论在哪里？ 如果您想要平滑过渡，则不得强制进行重大更改。 不提供切换回经典编辑器的插件。 将经典编辑器设为任何现有 WordPress 更新至 5.0 的默认编辑器。 让古腾堡成为更新者的选择。 您有没有想过成千上万的 WordPress 安装进行自动更新？ 您不会让 90% 的用户告诉他们如何“解决”古腾堡问题。 干脆不要激活它。 在 WordPress 更新屏幕上讲述您的故事。 告诉人们为什么它可能很有趣。 如果古腾堡是未来，您可以在每次新的 WordPress 安装时激活它，但在更新后永远不要默认为古腾堡。

WooCommerce 转移到 CRUD。 一个突破性的变化。 而且并没有想象中的那么顺利。 然而，它并没有破坏向后兼容性。 引入 CRUD 后，开发人员有时间适应。 为什么不对古腾堡做同样的事情呢？

你谈论更好的古腾堡文档。 美好的。 但是在开发基于 WordPress 的插件和应用程序时，我学到了最好的文档源代码。 因此，您只需要等到最终的古腾堡到达，因为您不知道在进一步的古腾堡开发过程中会发生什么变化。

如果我是项目负责人，我会遵循一个简单的计划：

1. 古腾堡不会获得 WordPress 更新的活动编辑器。 仅适用于新的 WordPress 安装
2. 切换到经典编辑器的插件将是核心的一部分。 它的设置将在 WordPress 的常规发布选项下可见。
3. CPT 会像以前一样工作。 如果他们声明编辑器支持，他们将默认使用经典编辑器。 如果他们使用古腾堡，他们就必须申报。
4. Metaboxes 会像以前一样工作。 无论他们是处理内容、分类法还是自定义内容。 编辑器根本没有理由对业务逻辑产生任何影响。
5. 最后但并非最不重要的对我来说，古腾堡只不过是任何其他页面构建器。 因此，我将仔细研究这些开发人员的所有出色工作，以及他们如何设法不破坏任何 WordPress 核心功能；-)

只是我的 2 美分

谈经济影响：

一些人声称它 [GB] 是我应该解决的错误，因为我首先建议使用 WordPress。

https://deliciousbrains.com/wordpress-gutenberg/#comment -3700968927

感谢所有花时间进行权衡的人。随着项目的进展，这是有意义的反馈。

关闭此问题，因为没有任何可立即采取行动的内容。