我最近才了解到关于古腾堡的新闻，古腾堡是 WordPress 编辑器改版的名称。 你现在就可以使用它，因为它最初 作为插件构建，最终将成为核心的一部分。 仓库 有更详细的信息。
在我看来，这是 WordPress 历史上对 WordPress 编辑器最重大的改变。 它也似乎与这里特别相关，因为 我们刚刚讨论了内容块 以及不同的 CMS 如何处理它们。 这正是古腾堡的本质：一个内容块编辑器。
内容区域不再是美化的文本区域（可能是对 WordPress 最有效的批评之一），而是成为你想要放置的任何不同“块”的包装器。 块包括标题、文本、列表和图像等。 它们也可以是更复杂的元素，例如画廊和嵌入内容。 重要的是，块是可以扩展的，实际上可以是任何东西。 就像一个 [短代码]，我想。
来自 Brian Jackson 的 深入了解新的古腾堡 WordPress 编辑器 的一些图像有助于说明这一点
与任何重大的软件更改一样，它也存在争议（甚至 两极分化）。 我收到一封电子邮件，有人实际上是在提醒我注意它。
共识是，这次 UI 升级要么可以将 WP 推向未来，要么会疏远数百万 WP 网站所有者并摧毁 WordPress。
我倾向于认为 WordPress 太大了，不可能消失，所以应该是前者。
我也认为，将块类型组合在一起对于 CMS 来说是一个通用而明智的抽象。 古腾堡似乎正在以健康的方式处理它。 块只是用特殊格式的 <!– wp:core/text –> <!– /wp:core/text –> 包裹起来以指定一个块，这样内容高度兼容。 没有古腾堡的 WordPress 网站不会遇到任何问题，也不会将其移植到其他地方。
此外，内容仍然在模板中被视为 一个大块
为了确保我们保持 WordPress 优势的关键组成部分完好无损，内容的真实来源应该保留在
post_content中，因为大部分帖子数据需要以可访问和可移植的方式存在。
因此，无论你在编辑器中如何构建它，它都存储在数据库中作为一个块，并用一个命令在模板中输出。 这可能使它在模板方面比你想要的 *不那么* 灵活，但这将此更改缩小到一个可接受的水平，并且仍然非常 WordPress 化。
似乎很多争议都源于 *谁动了我的奶酪* 的情绪，或者它目前支持什么以及不支持什么。 我对此并不太在意，因为人们往往会很快找到奶酪，而且这仍然处于似乎正在进行 积极开发 的阶段。
一个主要的担忧是自定义元框。 Joost de Valk
事实是，如果你现在测试古腾堡，你会发现 Yoast SEO 根本不在页面上。 此外，你可能使用的所有其他插件，例如 Advanced Custom Fields 或 CMB2，也都没有。 所有这些插件都使用所谓的元框，即当前编辑器下方和侧面的框。
古腾堡团队正在考虑更改元框，这在我们看来是一个很大的错误。 这意味着一旦古腾堡发布，许多、许多插件将无法正常工作。 大量的自定义集成将停止工作。 数十万个小时的开发时间将不得不至少部分地重新进行。 所有这些都是为了大多数网站，当前的编辑器工作正常。
这听起来确实很重要。 我想知道逐步采用古腾堡会是多么容易。 例如，为标准帖子和页面启用它，同时为你更有可能需要自定义元框的自定义帖子类型禁用它（或者类似的组合）。
在这个网站上，我大量使用自定义元框（即使只是传统的自定义字段），以及在编辑器中使用我自己的 HTML，所以古腾堡不会是我可以立即跳跃使用的。 这让我想知道是否会一直存在“经典”编辑器，或者新编辑器在某个特定版本发布时会成为强制性的。
更多争议来自 React 许可问题。 基本上是这样的
- Matt Mullenweg：我们将 从 React 切换（古腾堡使用它）因为许可问题。
- React：你们都错了，但是 我们放弃了。 现在是 MIT 许可证了。
- Matt Mullenweg：很好，但现在谈论的是允许人们使用 他们想要的任何新的 JavaScript 库。
我从未听说过“框架无关”的块渲染，但显然，这是一个东西。 或者可能不是？ Omar Reiss
有了新的古腾堡编辑器，我们正在改变 WordPress 管理员的构建方式。 现在我们使用 PHP 渲染界面，我们将开始使用 JavaScript 在客户端渲染越来越多的内容。 在编辑器之后，这很可能成为大部分管理员的现实。 这意味着如果你想与管理员界面集成，你将不得不与渲染界面的 JavaScript 集成。 如果 WordPress 选择 Vue，你将不得不提供 WordPress Vue 组件来渲染。 如果 WordPress 选择 React，你将不得不提供 WordPress React 组件来渲染。 这些东西不兼容。 React 不会渲染 Vue 组件，反之亦然。 没有库可以同时完成这两项工作。 如果 WordPress 使用特定的框架，每个人都必须开始使用该框架才能集成。
这是一个棘手的问题。 在 React 许可证更改之前，我敢打赌五美分 他们会选择 Vue。 之后，我怀疑他们会坚持使用 React。 他们自己的 Calypso 全部都是 React，除了古腾堡已经存在的内容之外，所以这似乎是一个延续的优势。
这将是一个有趣的技术故事，值得关注！ 像 Post Status 这样的网站可能会比我更 密切关注它。
我一直都在思考一个好的 CMS 替代品，它实际上速度快且安全。
大家对 .NET Core 2.0 有什么看法？ C# 和 Java 都提供了很好的安全性（远远高于 PHP），以及速度。
.NET Core 2 也运行在 Linux 上，并且可以在 Docker 中容器化。
参见这里
http://redhatloves.net
编程语言本身并没有固有的安全性或不安全性。 这完全取决于你如何使用它。
我不敢相信你在 2017 年用 .NET 替换 PHP
我不知道你的安全需求是什么，但可以看看 https://craftcms.com 作为 WordPress 的替代方案，或者使用 https://www.contentful.com 来存储内容并编写你自己的前端。
这些是我现在选择的 CMS，我可能会考虑回到 WordPress，但永远不会回到 Java 或 C#。 它们是过于冗长的语言，不适合网站。
Joe，你到底在说什么？ WordPress 速度快且安全？
WordPress（和许多人）使用 PHP 的唯一原因是可移植性。 选择任何主机，它都有 PHP。
但它是一种糟糕的编程语言，你不需要认真学习过大学的正式语言课程就能意识到这一点。 甚至它的作者在几次采访中都说事情失控了，他从未打算创造一种编程语言。
如果我们要自由地替换语言，显而易见的选择是 Python（可能还有 Flask，虽然这只是我的个人偏好）。
如今，对于自定义工作，我通常会告诉我的客户租用 VPS，然后我用 Flask 开发服务器端软件。 现在看来，也有一些用 Python 开发的 CMS，要么用 Flask，要么用 Django。
如果有人用 ASP.NET Core 创建了一个像 Craft 一样好的 CMS，我会喜极而泣。
问题是，尽管 .NET 提供了许多非常好的东西，但它从未拥有过一个很棒的 CMS。 以前平台的限制、对 MSSQL 的偏好以及该领域缺乏专注于前端的开发人员，使得这几乎不可能。（是的，Orchard 是一个东西——一个过度设计、鲜为人知的工具）
现在，代码可以在多个平台上即时编译，WebForms 的幽灵已经被驱散，JavaScript 前端已经成为标准，而且其惊人的速度甚至更加惊人——也许它会发生。
通用汽车太大，不可能倒闭。
” 我想知道逐步采用古腾堡会是多么容易。”
这是我们许多人所关心的核心问题——当前公布的计划是它不会是可选的。 它将在 5.0 中发布，并将成为默认编辑器，就这么简单。 现在，Matt 已经说过 5.0 的发布取决于古腾堡的准备情况，而不是一个日期驱动的版本，但我们中很少有人相信 5.0 会被推迟到，比如，2018 年秋季。 因此，它支持什么以及它在各种网站上测试得如何是一个关键问题。
有很多网站使用像高级自定义字段、各种短代码等等。改变所有这些内容的管理和生成方式是一个巨大的工程，而且风险很高。对我来说，风险因缺乏清晰度和细节而加剧。我们没有详细的路线图。我们没有制定任何发布前必须满足的明确要求。我们没有制定任何关于如何进行兼容性测试的计划。据我所知，插件开发者还没有一个稳定的 API，没有文档或明确的说明，说明如何调整他们的插件以与 Gutenberg 协作。
我想看到的是核心团队对 REST API 的处理方式。REST API 经过了很长时间的演变，在很长一段时间内都是作为插件提供，直到真正准备好才最终集成。发布没有因为它的存在而被搁置。它几乎是毫无意外地发布的。
Gutenberg 改变了 WordPress 核心的部分——内容的创建和管理方式。它应该谨慎地改变，需要经过大量的思考和反馈。
过去 2-3 年我一直参与这个马戏团，经历了诸如半成品、文档糟糕的自定义器（最初似乎由“改变问题”来补充，但它们却迟到了两年！）、媒体小工具（而不是让媒体数据库正常运行）等等荒谬的事情。
许多功能不断增加，大多数情况下让开发变得更加压力山大。
现在“gutenberg”的“乐趣”正在路上……我一直在认真考虑彻底放弃 WP。不是为了像许多人想的那样，以极端的方式重新制作它，把它分成几个版本，而是为了去除这些不断增加的功能，让一切平静下来，也许还可以添加一些选项来禁用像主题自定义器、XML-RPC 之类的可用性噩梦。
cu, w0lf。
你说：“这就是我们许多人担心的核心问题——目前的计划是它将不是可选的……Matt 已经声明……”
我想开源不意味着开放讨论？;)
统治世界一定很爽，或者至少统治着占所有网站 28% 的世界。
Rick:
你应该看看允许现有的元框与 Gutenberg 协作的工作。它正在针对 ACF 以及许多其他使用元框的高级插件进行测试。一旦它出现在 Gutenberg 版本中，你应该尝试用它来测试你的工作流程。
你遇到过哪些插件或短代码的问题？短代码应该继续工作。
这个“等等”指的是什么具体的项目？Gutenberg 仍在积极开发中，但目标是涵盖绝大多数现有的用例。如果我们遗漏了什么，我很想了解。
我同意我们需要改进文档，这是一项正在进行的工作。你在考虑将哪些特定的插件转换为与 Gutenberg 协作时想到的？查看实际的用例将有助于创建文档。
WPezDeveloper:
那是不公平的，有很多方法可以参与讨论。WordPress Slack、Make WordPress 博客、Gutenberg 问题追踪器，我们也会阅读诸如此类的帖子上的评论。几乎所有关于 Gutenberg 的内容都会被 Gutenberg 核心团队的成员看到。当然，需要做出决定，你可能并不总是赞同这些决定。但每个人都欢迎参与讨论！
很明显，他们应该在过渡阶段（漫长）期间，至少将常规元框保留在 Gutenberg 编辑器下方。
现有插件将继续工作，而新插件将用 React 构建。
很快，用户将开始更喜欢使用 Gutenberg 的“现代”插件，社区将自然过渡。只有在那时，WordPress 才会停止支持旧插件。
Federico:
这正是现在正在进行的工作！现有的元框将与 Gutenberg 协作，但插件绝对应该考虑如何将他们的元框使用过渡到 Gutenblocks。
我不喜欢这种实验。为什么要改变一个正常运行的东西？我正在认真考虑其他方案，Publii（静态 CMS https://getpublii.com）看起来非常不错。
我正在考虑的其他方案
Bolt
ProcessWire（作为独立选项；最好关注不止一个 CMS）
October CMS
Sitecake
ImpressPages
主要规格是：完善的文档（或者至少完善的源代码注释/PHPDoc）、与当前 WP 相当的功能、可以通过插件或扩展进行扩展、没有过高的系统要求。
cu, w0lf。
我已经使用Grav构建了一些网站，它属于静态 CMS 的类别。
效果很好，尽管学习曲线有点陡峭。尤其适用于中小型网站。
对于大型项目，或许可以切换到 Drupal？
既然你提到了……你现在可以使用React-Vue-Loader轻松地将 Vue 编译为 React。
他们可以选择 Stenciljs，它承诺是框架无关的。
不错的评论，Chris！
我知道块格式一直是一个有争议的话题，但我很高兴看到它带来的好处越来越明显。当然，正如你提到的，每个决定都有缺点。
可移植性和可读性是两个关键特征，因此我们希望人们发现它易于使用和阅读。
这当然是一个正在考虑的选项，但理想情况下元框应该可以正常工作。有一个非常酷的 PR 正在进行中，它允许现有的元框与 Gutenberg 协作。它正在逐渐完善，应该会出现在即将发布的 Gutenberg 版本中。鼓励进行测试和反馈！
有趣的是，我们也在努力解决这个问题！这仍然是实验性的，但在此 PR中展示的方法允许用 Vue 编写的 Gutenblock 使用针对 React 编写的 Gutenberg 组件（在本例中，Vue Gutenblock 可以作为“可编辑”块，它依赖于大量内部组件）。目前的实验使用自定义元素作为互操作性层，这些元素在某些框架中得到原生支持（特别是 Polymer 和 Stencil），并在其他框架中具有包装器。
正如Chris提到的，这可以用Vuera或React-Vue-Loader来实现！
这些内容块让我想起了 Django。谢谢。
/去躺一会儿。
一个看似很明显的功能（这里没有提到，但很可能很快就会出现）是实时视图，即前端编辑。即使这是一个很遥远的目標，我也希望在路线图中看到它。
有些开发者在使用 ACF 和“块”方法提供前端体验方面做得非常出色。像 Modern Tribe 的 Panels 这样的自定义编辑器视图的开发是朝着正确方向迈出的一步https://vimeo.com/194057171。
嘿，Jake，
前端编辑不在 WordPress 5.0 的路线图中，但你应该期待在 5.0 之后看到更多前端工作。Gutenberg 的重点将转向定制体验，这自然而然地需要与前端紧密结合。我毫不怀疑，在这过程中会有一些有趣的关于前端编辑的实验。
与此同时，计划是改进主题如何在仪表盘中挂钩到 Gutenberg，这样你就可以看到你正在处理的内容的前端风格。
我很惊讶有这么多人如此依赖 WP 内容编辑器。多年来我一直构建自定义字段集和选项来弥补 WP 中内容缺乏模块化和灵活性的问题。
我期待着深入研究 Gutenberg。
Gutenberg 看起来非常有趣，它已经在 WP.com 上上线了。
但恕我直言，它最大的缺点之一是它几乎在所有地方都插入了
&nbps;。这真的很烦人，会导致渲染问题，例如句子在奇怪的地方断开。所以，我从字里行间读到的是 WordPress 正在慢慢地从 PHP 迁移到 Javascript 框架。