DE{CODE}：古腾堡和无头 WordPress

Gutenberg，又名 WordPress 块，为内容制作者提供了在传统 WordPress 网站中布置内容的强大新方法。 但是无头 WordPress 开发人员如何为营销团队赋予这些相同的能力呢？ 在此 DE{CODE} 会议中，GraphQL for WordPress (WPGraphQL) 的创始人 Jason Bahl 分享了在无头站点上使用 WordPress 块编辑器的新功能和最佳实践。

会议幻灯片

全文抄本

杰森·巴尔：嗨。 欢迎来到我关于 Gutenberg 和 Headless WordPress 的演讲。 我叫杰森·巴尔。 我是 WPGraphQL 的创建者和维护者。 我是 WP Engine 的首席软件工程师。 您可以在 Twitter @jasonbahl 或 Twitter @wpgraphql 上找到我。

所以今天，我想和你谈谈古腾堡甚至是什么，无头 WordPress 是什么，什么时候以及为什么你可能想要使用无头 WordPress，如何使用古腾堡，特别是无头 WordPress，以及无头 WordPress 和古腾堡的时间和原因在一起可能对您的项目有意义。

所以 WordPress 历史上有一个看起来有点像这样的编辑器。 我们有一个 TinyMCE 文本区域，我们可以在其中编辑我们的内容。 我们可以插入媒体然后发布我们的内容，然后在 2018 年出现了基于块的编辑器 Gutenberg，它允许我们将内容插入到这个空白画布中并在块级别与我们的内容进行交互。

所以每个段落都有设置。 每个图像都有设置。 每个画廊、标题——任何你能想到的内容都是所谓的块。 我们现在可以真正细化我们如何控制我们的内容，我们可以拖放它并编写我们的内容。 所以它现在是 WordPress 中非常丰富的编辑体验，所以它是古腾堡是什么的初级读物。

那么现在什么是 Headless WordPress？ 所以要了解 Headless，让我们看看传统的 WordPress。 所以传统的 WordPress，我们登录到 WordPress，管理 UI，我们发布我们的内容，然后用户访问我们的网站，PHP，WordPress 内置的语言，呈现页面。 因此它加载 CSS、HTML 和 JavaScript 并将页面交付给用户。 所以这是一种传统的 WordPress。

使用 Headless WordPress，您仍然使用 WordPress 作为 CMS。 您仍然在 WordPress 中发布内容、策划内容、管理内容，但不是向浏览器提供 HTML 页面，WordPress 通常以 JSON 格式提供数据，然后客户端应用程序可以使用该数据，因此我们可以拥有原生 iOS 或 Android 应用程序甚至虚拟现实应用程序。

我的同事 Anthony 分享了有关他如何使用 WordPress 为虚拟现实应用程序提供支持的内容。 或者我在一家报纸工作，我们使用 WordPress 作为我们印刷报纸的入口点。 因此，如果您正在阅读纸质报纸，那么您正在阅读 WordPress 制作的内容。

当然，我们仍然可以使用这些数据来呈现到网络，但我们不必局限于 PHP 模板，我们可以灵活地选择我们想要的任何前端技术。 因此，Headless 分离了后端、内容管理以及我​​们如何呈现在 WordPress 中管理的数据。

因此，我们可以通过两种常见方式使用这些数据。 我们可以从 WP REST API 获取 JSON 格式的数据，WP REST API 是 WordPress 的内置 API，还有另一个 API 称为 WPGraphQL。 这是一个开源插件，您可以安装它并从 WordPress 和 JSON 中获取数据。 我们今天将讨论 WPGraphQL。

那么既然我们知道 WordPress 是什么，您为什么要构建 Headless WordPress 项目呢？ 就像我提到的，您在选择前端技术方面有很大的灵活性。 对于某些人来说，能够选择如何构建前端项目是一件非常重要的事情。 有一些框架，如 Next、Gatsby 和 Svelte，真正针对改进的核心 Web 活力。 因此，您可以使用 WordPress 进行 Headless，并改进核心网络生命力。

您可以从代码中的代码拆分等方面受益。 因此，您可以为前端应用程序构建组件。 并且基于为特定页面构建的组件将向客户端发送更少或更少的资产并加速您的页面。 Headless 还使开发人员可以更好地控制前端用户体验，因此安装在 WordPress 管理中的插件对前端的影响较小

因此，管理员用户不能只安装插件并将任意脚本或任意标记添加到 Headless 站点的前端。 更多的是开发人员在前端定义约束，WordPress 获取发送过来的数据，然后我想强调的一件事是开发人员体验。

使用 Headless WordPress，由于您可以灵活地使用任何您想要的技术堆栈，因此在某些情况下会有更好的开发人员体验的好处。 我将要涉及的其中一个案例称为基于组件的开发，我们稍后会详细讨论它。

这就是为什么的一些原因。 那么当你想要使用 Headless WordPress 时，你可能处于什么情况？ 好吧，如果您需要构建非 Web 应用程序，例如原生移动应用程序，您可能想要使用 Headless。 同样，如果您的 WordPress 网站、您当前的 WordPress 网站上的核心网络活力很差，或者它们还可以，但保持它们良好的成本变得非常高，您可能需要考虑 Headless。

如果您的组织中有多个应用程序需要从 WordPress 获取数据，您可能也需要使用 Headless。 如果您已经为您的组织投资了一个组件库或基于组件的设计系统，并且您需要来自 WordPress 的数据，您可能想要投资于 Headless。 如果一个团队更喜欢 JavaScript 而不喜欢用 PHP 构建东西，那也是考虑 Headless 的一个原因。

不过，您可能不想使用 Headless 的某些原因——目前，它确实需要一点额外的开发时间。 因此，如果您的预算较低或缩减时间，并且您已经在传统 WordPress 中拥有解决方案，那么您可能还没有采用 Headless。 如果您的站点管理员确实需要控制安装修改前端的插件，您可能还没有使用 Headless。

如果您的团队真的更喜欢 PHP 而不想学习 JavaScript 或其他前端，您也可以坚持使用传统的 WordPress。 如果您没有投资于基于组件的开发或基于组件的库，如果您对此不感兴趣，您可能会坚持使用传统的 WordPress 开发工作流程。

如果您在传统 WordPress 上的核心 Web Vitals 非常好，并且您的维护成本非常低以保持您的网站运行非常快，那么您可能会坚持使用传统 WordPress。 所以你不必去无头。 但我将向您展示为什么我认为采用 Headless 对某些团队有好处。

因此，如果我们再次审视 WordPress 开发人员的体验，我们会在一个生成大量 HTML 的字段中发布我们的内容。 即使我们使用具有这些细粒度块的古腾堡编辑器，最终结果也是一大块 HTML。 因此，无论我们是在古腾堡还是传统的经典编辑器中发布，这一块 HTML 都会通过 PHP 发送到我们的主题，我们有一个全局页面可以加载我们的 HTML、CSS 和 JavaScript。 这些资产在全球范围内应用于页面。

所以 WordPress 开发人员通常会根据文件类型来解耦我们的开发，所以我们会将我们的 CSS 放在单独的文件中，这些文件全局应用于页面，或者 HTML 将用 PHP 编写，并从 WordPress 中提取我们需要的数据，然后 JavaScript 将经常用 jQuery 写在单独的文件中。 因此，这三件事将一起构建页面。

问题是这些不是孤立的，它们应用于整个页面。 所以有时候你可以做出改变。 就像这件事发生在我身上。 有一次我应我的经理的要求更改了网站页脚的样式，三天后，据报道该网站其他地方的样式由于通过代码审查而发生了变化。 我们通过了。

突然间，网站上的其他东西坏了，这是因为 CSS 是全球应用的，可能会影响你没有意识到的事情。 不过，过去有一种新趋势——我不知道——七八年可能被称为基于组件的架构。 这使我们能够在所谓的组件中构建应用程序的特定部分。

我们可以将我们的 JavaScript、我们的 HTML、我们的 CSS 组合成小块，我们可以单独测试它们，这样我们就可以构建我们的应用程序的各个部分。 关注点、标记、JavaScript、样式，我们可以将这些组件组合在一起以构建更复杂的应用程序。

因此，基于组件的开发允许我们将复杂的功能分解成更小的独立部分，我们可以单独测试它们，确保它们正常工作，然后我们可以耦合我们应该耦合的关注点。 UI 的每一部分都有特定的职责。 如果它是图像卡片，它可能会负责以特定大小呈现具有特定 URL 的图像。

所以它具有标记依赖性。 它具有样式依赖性。 它可能有状态交互。 这些都与该特定组件有关。 所以我们可以将我们的标记、我们的 JavaScript 和我们的 CSS 结合在一个地方，测试它，并确保它运行良好。 因此，我们可以在整个应用程序中重用这些组件，甚至可以跨项目重用我们的组件。

所以出现了一种叫做组件库的趋势。 有像 Material UI 或最终设计组件这样的项目，或者 Chakra UI 也是一个流行的项目。 我们可以跨项目使用这些组件。 我们可以解决诸如可访问标记之类的核心问题。 我们可以对这些进行更新，并立即将它们应用到我们组织的多个项目中，正因为如此，我们可以更有信心地更快地迭代和交付。

那么我们如何使用 Headless WordPress 呢？ 就像我之前提到的，有两种方法可以将数据从 WordPress 中获取到组件中。 一个是 REST API。 一个是 WPGraphQL。 我的朋友 Drake 已经建立 Headless 网站有一段时间了，所以我问了他，他是这么说的……

他更喜欢 WPGraphQL。 这就是我们今天要讨论的内容。 那么什么是 WPGraphQL？ 你可能会问。 好吧，它是一个免费的开源 WordPress 插件，可为任何 WordPress 站点提供可扩展的 GraphQL 模式和 API。 那么 GraphQL 是什么？ 好吧，这是一种图形查询语言。

好吧，杰森。 我还是不明白你在说什么。 好吧，让我给你看。 所以 GraphQL，它的工作方式是客户端应用程序发送一个请求，指定他们想要从服务器获得什么。 请求看起来像这样。 它看起来像没有值的 JSON 键。 所以在这种情况下，请求是在询问查看器，而在查看器上，我们希望返回“名称”字段。

来自 GraphQL 服务器的响应可能如下所示。 它的实际 JSON 数据、键和值以及它与请求的形状相匹配。 所以在这种情况下，我们得到了名字，或者我们得到了名字为 Jason Bahl 的观众。 所以 GraphQL 让我们的客户端应用程序从应用程序数据图中采摘树。

视觉上看起来像这样。 我们可以输入图形，比方说，添加查看器或用户字段或节点。 那个节点可能有一个属性，比如名字 Jason。 并且该节点可能与图形中的其他节点有连接，例如头像，它可能具有图像 URL 等属性。

并且该用户可能与其他节点有连接，例如该用户创作的帖子。 这些帖子本身可能具有标题、你好世界或再见火星等属性。 这些帖子可能与图中的其他节点有联系，例如具有自己标题的类别，如新闻或体育。 这些类别可能与其他节点有联系以及更多帖子。 这些帖子可能有特色图片等等。 所以我们有了这个大数据图，我们可以使用 GraphQL 请求其中的片段。

因此我们可以在 GraphQL 管理员或 WordPress 管理员中使用工具。 有一个名为 GraphiQL 的工具，我可以在其中编写查询。 在这里，我选择了带有子选择、名称、头像、URL 的查看器字段，当我们执行它时，我们得到了我们要求的字段，因此在视觉上查询看起来有点像这样。

我们输入了图表并询问了一个用户。 我们询问了用户名，头像 URL 中连接的头像。 我们拥有所有可用的数据图表，但我们只要求一组特定的数据，作为回应，我们得到了特定的挫折。 然后我们就可以采取——我们现在可以使用组件了。

所以我谈到了基于组件的开发的好处，我想向您展示这一点。 所以这就是我所说的展示组件。 所以这是一个负责的卡片组件。 它有责任渲染这张带有图像和标题的卡片。

我们可以查看代码，发现我们有一些样式控制。 我们可以设置宽度，我们可以将我们想要的图像传递给它，我们可以将标题传递给它。 所以我们可以在整个项目中重用这个组件。 并且该组件具有我们需要的所有依赖项。 它具有要呈现的 HTML。 它有风格。 我们在这里有一些样式控制。 它有一些有状态的组件，比如悬停状态等等。

所以这是一个我们可以重用的独立组件，现在使用 GraphQL，我们可以使用 GraphQL 获取我们刚刚在 WordPress 管理中编写的查询，我们可以将其引入并现在拥有一个查看器卡组件。 所以我们可以编写我们的查询，将它与我们的卡片组件结合起来，现在它完成了该组件。

我们有我们的 HTML、CSS 我们的 JavaScript。 由于有了数据，我们现在可以用我们要求的数据来呈现一些东西。 所以现在我们可以在整个应用程序中使用它，并且有一个称为片段的 GraphQL 特性，这允许我们获取 GraphQL 查询并将其分解为可重用的片段。

因此，在这种情况下，我正在创建一个用户个人资料卡片片段，我正在指定名称、头像和 URL，然后我在更大的查询中使用该片段。 当我们执行时，我们会得到我们期望的结果。 我们现在可以获取该片段，将其放入组件中。 现在我们有一个不同的组件，称为用户配置文件卡。

此用户个人资料卡指定任何时候我们查询用户时，我们都应该获取名称、头像和头像的 URL 以在组件中使用。 所以现在我们有了这个可重用的组件，我们可以在应用程序的任何地方请求用户，我们可以获得必要的数据来渲染这个可重用的卡片，其中包含头像和用户名。

因此，现在可以将其引入并用于我们应用程序的更大部分。 这是我们在查看器查询之前使用我们从可重复使用的用户资料卡组件导入的片段进行的查询。 然后我们将它输出到查看器卡组件，现在我们可以在我们的应用程序中重用它。

我们可以制作依赖于此用户卡或作者卡的应用程序的更大部分。 所以我们现在可以有多个组件，比如负责标题的博客标题组件。 我们可以有一个我们刚刚创建的用户个人资料卡来呈现用户的个人资料。 我们可以有一个内容或摘录组件来负责我们应用程序这部分的标记和数据。

是的，我们可以构建这些负责标记、CSS 和构建此应用程序所需的数据的小组件。 我们可以将它们组合在一起。 我们可以单独测试它们，也可以将它们作为更大的单元进行测试。 所以我们也可以在各种模板中使用它。

我们可以将这些可重用组件用于博客文章或我们拥有不同作者的博客角色，但我们可以使用相同的组件来呈现它们。 我们可以将它用于其他存档页面。 与 WordPress 模板部分非常相似，我们可以将 Headless 应用程序分解成小块，但我们可以获得将我们的技术耦合在一起的好处。

所以这就是 Headless WordPress 开发人员体验基于组件的设计及其好处的一点点。 那么现在谈到古腾堡时，为什么要特别考虑使用古腾堡的 Headless WordPress？ 好吧，如果您的团队已经在使用 Headless WordPress，可能使用高级自定义字段和弹性域，并且您想要更新编辑器体验以使用 Gutenberg，这显然是您可能会使用 Gutenberg 的 Headless 的原因之一。

如果您想从构建在管理中使用的组件和在前端使用的组件中受益，那么考虑使用 Gutenberg 进行 Headless 是一个很好的理由，因为块编辑器的 Gutenberg 后端编辑器都是基于组件的。 您可能想利用结构化输入。 管理员中的每个块都有结构化的字段。

您具有可以在字段级别控制的特定属性。 您可能也想从将结构化输出传送到您的组件中获益。 就像我提到的，您可能希望跨项目重用组件和块。 例如，您可能希望拥有您的机构构建的块库，以解决您希望跨项目使用的可访问性和特定标记问题等问题。 然后你可以在你的项目中更新这些，而不仅仅是在一个单独的项目中。

因此，这是 WordPress 中的子主题难以扩展的部分，因为您必须访问每个站点并更新每个站点上的标记和诸如此类的东西。 那么，在这里，您可以使用块库作为 NPM 依赖项并在整个组织中更新它们。

所以目前，使用 Gutenberg 进行 WordPress 开发的状态是我们在后端有块，这些块是基于组件的。 我们可以构建自己的自定义块或使用核心 WordPress 块。 但是 PHP 的输出，就像我提到的那样，是一大块 HTML，那么我们如何才能从获取这一块 HTML 过渡到在后端拥有组件，这些组件也会传输到我们前端的组件？

因此，我们将研究一些将 Gutenberg 数据从 WordPress 提取到组件中的选项。 因此，一种选择是将内容作为 HTML 获取。 所以我们可以将我们的 WordPress 内容查询为 HTML，然后将该 HTML 解析为组件。 或者我们可以将块查询为 GraphQL 类型。 所以我们可以——这允许我们查询块列表，每个块都是我们可以映射到组件的 GraphQL 类型。

所以内容是HTML。 这是我们今天可以在 WPGraphQL 核心中做的事情。 如果你想查询块作为单独的 GraphQL 类型，目前有两个选项。 我们有用于 Gutenberg 扩展的 GraphQL，这是社区扩展，然后我们有 WPGraphQL Block Editor，这是我个人正在开发的 beta 插件。

因此，让我们看看这些选项。 在 WPGraphQL 核心中，我们可以将内容查询为 HTML 并解析为组件。 这看起来像是我们查询类似帖子的内容，我们可以请求 ID 和标题或内容等字段。 内容将返回一个大字符串，一大块 HTML，然后我们可以解析该 HTML 并将不同的 DOM 节点映射到不同的组件。

就像 wpgraphql.com 上的这种情况一样，左侧的链接指向实际发生这种情况的代码。 我获取从 WPGraphQL 返回的标记，然后解析它，查找特定的 HTML 节点并将其转换为 React 组件。 所以我可以有像这个代码块这样的交互式东西，它会突出显示语法并允许用户单击复制，然后我还可以解析和创建目录，例如。 所以这是一种方法。 我今天在 wpgraphql.com 的生产环境中使用它。

如果你走这条路，你可能需要考虑一些事情，HTML 有效负载可能是不可预测的。 服务器中的更改，例如安装新的块库或编辑器可以放入内容中的各种 HTML，它们是不可预测的。 所以它可能很难解析。 您无法检查更改。 作为客户端开发人员，您看不到发生了什么变化，所以只需要考虑一些事情。

我会说这种方法最适合对 WordPress 管理员和前端有非常严格控制的团队。 因此，如果您是一个人或一个在 WordPress 后端和前端工作的小团队，它可能适合您，因为您可以更好地控制输入和输出。

其他选项之一，WPGraphQL for Gutenberg，这是一个社区维护的插件。 这将允许您查询内容块，每个块都有自己的 GraphQL 类型。 它的工作方式是一个设置页面，你必须进入作为模式的块，所以这会在一个不可见的 iframe 中打开 Gutenberg，从 JavaScript 客户端获取块注册表并将其发送到服务器。

然后我们可以使用 GraphQL 来查询我们的块作为特定类型，我们可以使用我之前展示的片段，我们可以使用这些片段映射到我们前端的组件。 所以这是一种选择。 这个插件的一些注意事项，对块注册表的更改是可自省的，所以这是一件好事。

在前端应用程序上工作的团队可以使用 GraphQL 内省来查看架构如何随时间变化，并且他们可以知道是否存在重大更改或他们可以使用的新字段。 我会说这种方法对多人或多团队项目效果更好一些。 如果您有一个团队负责 WordPress 管理员工作，而另一个团队负责前端工作，那么这种方法可能会更好。 他们可以使用 GraphQL 模式作为双方使用的块之间的契约。

一件有点有趣的事情是它像我提到的那样在 iframe 中加载块。 正因为如此，它并不总是适用于所有情况。 因此，如果您将块注册到特定页面或特定模板或特定帖子类型，这种将块注册表映射到模式的方法可能会错过某些块。 所以它可能无法扩展到每个项目。

所以下一个项目，WPGraphQL Block Editor，这是我目前正在开发的测试版插件。 这也允许您将内容块查询为它们自己的 GraphQL 类型，因此与 Gutenberg 的 WPGraphQL 非常相似，我们可以编写返回我们指定数据的片段。 然后我们可以在前端将这些片段与我们的组件一起使用。

对此的一些考虑，它是一个测试版插件，就是这样。 您确实受益于结构化输入和结构化输出。 因此，作为前端开发人员，这无疑是一场胜利。 它确实适用于在 block.json 文件中注册的块。 所以核心 WordPress Gutenberg 块确实有这个文件，所以这将适用于该方法。 许多第三方不会以这种方式注册他们的块，因此您必须手动映射这些块。

块不被视为单独的节点。 我想将块视为单独的节点，但没有全局 ID，因此您必须将这些块作为更大对象（如海报页）的一部分进行访问。

因此，我希望您了解了一些有关 Headless WordPress、Headless WordPress 的好处以及将 Headless WordPress 与 Gutenberg 结合使用的知识。 今天我邀请您试用 WPGraphQL。 您可以在 wpengine.com/atlas 注册一个免费的 Atlas Sandbox 帐户。 感谢您参加我的演讲。 同样，您可以在 Twitter、jasonbahl 或 Twitter @wpgraphql 上找到我。 谢谢。