DE{CODE}：适用于 WordPress 开发人员的 Headless 101

无头开发可以比传统的 WordPress 开发更强大，甚至更有趣。 然而，在这个新兴堆栈中有如此多的新选择，最好的入门方法是什么？ 本次研讨会将引导构建者安装和优化无头 WordPress 项目，一直到在分离的前端中模板化您的第一页。

会议幻灯片

全文抄本

GRACE ERIXON ：欢迎来到 WordPress 开发人员的 Headless 101。 我的名字是 Grace Erixon，我是 WP Engine 的副开发倡导者。 加入我的是来自豪斯的史蒂夫。 今天，我们将向您快速介绍什么是无头 WordPress，以及如何开始使用它。

因此，为了了解什么是无头 WordPress 网站架构，重要的是要确保我们都在同一页面上了解传统 WordPress 架构的外观。 传统上，像 WordPress 这样的 CMS 会同时处理网站的前端和后端。

在传统架构中，发布者在 WordPress 中创建和管理博客文章和页面等内容。 开发人员使用 PHP 和 WordPress 的主题 API 编写代码来控制网站的外观和功能。 然后 WordPress 生成发送给访问者的 HTML 页面。

在这种耦合的 CMS 架构中，WordPress 为发布者提供了内容管理功能。 它还负责为网站访问者提供 HTML 页面。 无头 CMS 使用分离架构，前端和后端分开管理。 在无头架构中，发布者仍然在 WordPress 中创建和管理内容，这与在传统 WordPress 架构中相同。

开发人员编写代码来控制网站在 JavaScript 中的外观和功能，以及使用 WPGraphQL 或 REST API 从 WordPress 中提取数据。 Faust.js、Next.js、Nuxt.js 或 SvelteKit 等框架通常用于为该前端应用程序提供支持。 然后前端 JavaScript 应用程序生成并提供发送给网站访问者的 HTML 页面。

与传统架构不同，WordPress 不再负责生成 HTML 页面。 因此，WordPress 后端和前端 JavaScript 应用程序之间交换内容的交互是通过 API 层发生的。 API 层的两个选项是 WordPress REST API 或 WPGraphQL。

REST API 与 WordPress 捆绑在一起。 但是，它所需的数据访问模式可能会很慢，因为 REST 要求每个资源都有自己的端点。 例如，需要多次往返才能重建完全建模的帖子。 如果您想获取帖子的内容、作者和类别，则需要三个单独的 API 调用。

相比之下，WPGraphQL 允许我们在一次请求中询问帖子的内容、作者和类别。 因此，WPGraphQL 是我们首选的 API 层。 WPGraphQL 是一个免费插件，可为您的 WordPress 站点提供可扩展的 GraphQL 架构和 API。 WPGraphQL 比 REST API 更快，因为它获得了所要求的确切数据，并且通过查询优化减少了执行的功能，减少了数据下载，提高了数据加载效率，并且在单个请求中包含了多个资源。

无头架构让开发人员可以自由选择任何前端技术堆栈，其中 JavaScript 框架最为流行。 一些最流行的前端 JavaScript 框架包括 React、Vue.js 和 Svelte。 新框架一直在发布，所以这个列表远非全面。

其中许多 JavaScript 框架与元框架结合使用，为路由、服务器端渲染等添加解决方案。 React与Next.js结合使用，Vue.js与Nuxt.js结合使用，Svelte与SvelteKit结合使用。 Gatsby 是另一个流行的元框架。

WP Engine 开发了 Faust.js，这是一个构建在 React 和 Next.js 之上的 JavaScript 框架。 Faust 是专门为支持无头 WordPress Web 应用程序而创建的。 它支持开箱即用的身份验证和发布预览，提供方便的内置 React 挂钩以访问 WordPress 数据等。

所以我们已经讨论了无头 WordPress 架构的含义以及您将使用的技术种类。 但是让我们快速谈谈为什么你甚至会选择无头。 WordPress 本身是一个重量级的 CMS，它使用的是 PHP，这不是一种快速的语言。 Headless WordPress 通过 JavaScript 使用 foster 语言，并通过 API 调用仅加载必要的文件。 它更轻巧，因此您的网站加载速度会更快。

Headless WordPress 还可以最大限度地降低您的内容的风险，因为您的数据与前端交付是分开的。 它较少受到网络攻击。 主要好处是 headless WordPress 架构允许发布者继续受益于 WordPress 提供的出色发布体验，同时还允许开发人员和网站访问者利用现代 JavaScript 应用程序带来的技术功能。

现在，让我们深入研究一个真正的无头站点的代码。 我预先录制了新的 Atlas Blueprints 无头 WordPress 网站的演练。 Atlas 中的新蓝图功能提供了一种非常简单的方法来启动和运行完整的无头 WordPress 站点。 它们带有起始代码、插件、内容模型和页面结构，可以让您的应用程序更快地启动。

因此，让我们创建一个新的蓝图站点，以便我们可以深入研究代码。 从 WP Engine 的仪表板内部，我们将转到 Atlas。 单击创建应用程序。 选择从蓝图开始。 然后我们将选择我们想要使用的蓝图。 我要选择投资组合蓝图。

然后将您的 WP Engine 帐户连接到您的 GitHub 帐户，并将该蓝图克隆到一个新的存储库中。 这将需要几秒钟的时间来构建。 最后，您只需选择刚刚创建的存储库的名称、离您最近的区域，然后单击“创建应用程序”。

现在，如果您单击 Atlas URL，我们可以查看我们的 headless WordPress 网站的外观。 我们对 Posts 页面特别感兴趣。 如您所见，该站点正在将所有最新帖子拉入此“我们的博客”页面。 每个帖子也有自己的个人视图页面。 但是所有这些数据来自哪里？

如果我们回到 WP Engine 仪表板，我们会看到一个 WP Admin 按钮。 这是我们的无头 WordPress 网站的后端。 如果我单击“帖子”，您将看到与 Web 应用程序拉入的列表相同的列表。现在，我们可以打开我们的蓝图被克隆到的 GitHub 存储库。 让我们将该 repo 克隆到我们的本地环境中。

然后，我将在我最喜欢的代码编辑器 Visual Studio Code 中打开此存储库。 深入到项目目录，可以在 SRC、pages、posts、Index.js 找到博客页面的文件。 该项目是使用 React、Next.js、Faust.js 和 WPGraphQL 构建的。 如果您不熟悉 React 甚至 JavaScript，那么乍一看可能会感到困惑。

在第一部分中，文件只是从内部和外部源导入它需要的东西。 定义后节点预传递字段的第二部分是列出我们需要的每条数据的地方。 通过 prepass 运行它可以确保数据在我们需要的时候就在那里，并且不会发生级联请求。

然后我们有页面功能。 起初，它只是将我们需要的数据收集到几个不同的变量中，即常规设置和分页的帖子列表。 返回语句中的标记是将在网页上可视化呈现的代码。 首先，我们有标题组件。 然后，在这个主要组件内部，我们有一个条目标题组件，这就是在页面顶部显示“最新帖子”的大标题。

最后，我们到达 post 组件，它接受分页的帖子列表作为参数。 让我们看看 post 组件如何处理这些信息。 在这里它循环遍历它收到的帖子列表中包含的每个帖子。 对于每个帖子，它会在最新帖子的页面上显示类似卡片的视图。 这首先包含一个包含在单个博客文章页面链接中的特色图像组件、帖子标题的标题以及由帖子的日期和作者组成的帖子信息组件。

回到显示所有帖子的 Index.js 文件，我们通过在页面底部显示加载更多组件来完成此操作，以在请求时检索更多帖子和页脚。 最后一个函数 getStaticProps 是一个 Next.js 静态站点生成函数，它告诉它在构建时使用该函数返回的道具预渲染此页面。 就是这样。

感谢 Blueprints 为我们处理 Headless 设置。 使用 WPGraphQL 分解进入帖子页面的内容以从 WordPress 后端获取数据并使用 React 组件显示帖子是很简单的。 感谢收看。您可以在 Twitter @graceerixon 上找到我。

查看 developers.wpengine.com 了解有关 Headless WordPress 的更多内容。 我们有一个教程，介绍如何使用 Faust.js 从头开始​​构建您的第一个 Headless WordPress 网站，我们现在正在处理 Headless 101 系列内容。 如果您注册一个免费的 Sandbox 帐户，您可以获得 Atlas 提供的所有工具。 现在，我将把它传递给史蒂夫，让他更多地谈谈为什么 Haus 选择 Headless WordPress 作为他们的 leoburnett.com 项目。

史蒂夫·斯卡沃： 谢谢，格蕾丝。 大家好，我是 Haus 的首席技术官 Steve Scavo。 我们是一家位于加利福尼亚州洛杉矶的创意技术工作室和代理机构。 本次演讲的标题恰如其分地命名为 WordPress 开发人员的无头 101。 坦白说，我不是 WordPress 开发人员，但我认为这是无头架构之美的一部分。

因此，对于需要利用 WordPress 的非 WordPress 开发人员，我们可以轻松地将其称为 Headless 101。 这可能是一个恰当的标题。 这就是无头的美妙之处。 正如您将看到的那样，这是各方的双赢。

那为什么是无头的呢？ 我们可以谈论很多高层次的原因，但我认为谈论真实的生产例子和现实世界的例子真的很有帮助。 我想展示一个我们为 Leo Burnett 在无头架构下使用无头的项目。 就上下文而言，李奥贝纳 (Leo Burnett) 是一家位于芝加哥的传奇广告公司，但他们在全球和全球设有许多办事处。 所以他们有很多内容，很多工作。

旧站点在单个 WordPress 主题上运行。 它真的很零散，有点慢，表现不佳。 它很难更新，也没有完全展现李奥贝纳想要传达的那种声望和品牌。 这就是我们从设计角度出发的工作。 我们选择了 headless 来真正实现他们的堆栈现代化。

我们只是希望它给人以活力和新鲜感，并具有我们需要的那种能力，才能真正将美妙的用户体验和 UI 组合在一起。 我们想提高他们的出版能力。 我们希望提高他们发布内容的节奏。 我们想重新建立品牌标识并拥有用户界面和交互，网站的感觉真的有点像李奥贝纳，以及他们想要传达的所有这些小细节和编辑、排版和交互点。

我们想为将来准备代码库和网站。 我们不只是希望该站点在接下来的 12 个月内具有相关性。 也许，我们希望它与下一个十年相关。 而且我认为这种无头架构，这种无头堆栈确实可以做到这一点。

所以 headless 的最初问题之一是总是有很多关于托管、部署和基础设施的决定，这一直是一个巨大的痛点。 所以这些堆栈决定一直留给开发人员。 你四处寻找，思考，好吧，你需要使用什么第三方，也许是 CI/CD 应用程序？ 我们要在 AWS 上托管它吗？ 我们该怎么做？ 什么服务？ 然后你可以围绕该流程实施这些潜在的临时解决方案。

嗯，Atlas 和 WordPress Engine Atlas 平台确实解决了这个问题。 这就是它发挥作用的地方。 出于所有这些原因，我们选择了 Atlas，他们拥有这种托管服务基础架构。 他们标准化了 CI/CD 管道。 你真的不必考虑它。

环境之间存在数据迁移，本质上是一键式流程。 从历史上看，这一直是从 QA 到暂存到生产的一个大问题。 本质上，WordPress 引擎和 Atlas 平台已将其简化为一次单击。

然后就是围绕微服务和 DevOps 的这种疲劳。 作为开发人员，您必须考虑和支持并意识到这一点并保持其正常运行，这只是一个沉重的认知负担。 这些都是 Atlas 平台真正从你手中拿走并以有益的方式解决的事情。

那么让我们谈谈我认为无头真正促进和强调的一些动态。 这里的第一根柱子——共有三根。 第一个支柱是开发者体验。 它使我们能够为工作选择合适的工具。 当我说我们时，我指的是开发人员。

它允许我们选择我们想要编写代码的堆栈。对我们来说，那是在 Haus，那是 Next.js 和 React。 Next.js 只是一个很棒的框架，它围绕着路由、性能和应用程序架构的一些非常好的约定。 我们还想实现一个设计系统，不仅仅是一个视觉设计系统，而是一个代码化的设计系统。 这是使我们的应用程序保持一致、经过测试和美观的东西。

交互是一致的。 它允许我们在未来的生态系统中构建新​​的页面和功能，并保持并保持这种一致性。 它还允许我们编写声明式表达代码，并且 React 认可它作为一个库。 但我们也相信这种写作风格作为一个团队。 它允许我们在前端为我们选择那个堆栈，而也许是一个传统的基于主题的 WordPress 网站，我们并没有真正拥有同样的奢侈。

我们还需要大量的创意空间。 当您访问 leoburnett.com 时，您会看到漂亮的页面转换。 有——我们不受限于传统的 WordPress 堆栈如何呈现事物。 WordPress 不再负责呈现前端。

我们的净空几乎是无限的。 我们可以选择我们的动画库。 我们可以选择我们的组件相互交互的方式。 这在 DX 方面是一个巨大的好处。

管理员体验得到了提升，我认为我们已经优化了它，因为我们从未摆脱他们过去的熟悉。 没有后端切换。 我们从 WordPress 转到 WordPress。 我们不必导出数据和编写脚本来转移到另一个专有系统。 所以熟悉度很高。 我们希望为 leoburnett.com 的当前管理员保持这种流程。

采用和文档——如果您在网络上花费五分钟，您可能已经接触过 WordPress 后端，这简直不能被夸大。 李奥贝纳还有很多非常具体的内容点和自定义字段。 WordPress 提供并赋予您这种能力，但我们能够实施 Advanced Custom Fields 插件，这是一个关于调整管理 UI 以使其真正友好和可用的非常好的约定。 所以这是管理体验的胜利。

现在，第三个支柱当然是用户体验。 这才是真正重要的。 用户，我认为就像我们认为 Haus 的 Web 应用程序应该感觉像本机应用程序一样，不应该有下降。 我认为用户也很欣赏这一点。

它们是无缝的。 他们反应灵敏。 他们只是感觉良好。 而且我认为我们希望 Leo Burnett 和我们所有的应用程序都有这种感觉。 能够在前端选择我们想要的堆栈使我们能够做到这一点。

本机应用程序本质上与其后端内容基础架构分离，我们的网络应用程序也是如此。 这就是阿特拉斯所提倡的。 这就是无头架构通常所提倡的。 它还可以促进性能。 我们可以普遍呈现我们的 UI。 这意味着初始负载在服务器端。 之后，客户接管。

这里有很多好处。 一是它让搜索引擎高兴。 它们是服务器端内容。 它很快。 它还允许我们几乎即时地预渲染下一页，并根据视口中的内容一次性发出这些请求。

对于 Leo Burnett，就我们选择使用的内容 API 而言，我们设置了一个 GraphQL 端点。 这意味着有更精简的有效载荷返回。 我们明确定义了我们需要的内容。 在服务器端渲染到客户端渲染之后水合作用较少。

通过线路传输的代码更少、响应更少、响应时间更快。 这绝对是一场胜利，我建议，如果您打算进入 Atlas 工作流或无头工作流，那么您应该认真考虑使用 GraphQL API 与 REST API 之类的东西。

从用户的角度来看，他们看到的是新鲜、及时的内容。 这是为预览内容而优化的发布流程。 它针对暂存和预览方面的快速内容获取进行了优化，然后将其推广到生产中。 李奥贝纳 (Leo Burnett) 的管理员对更新内容的轻松程度感到非常满意，这让用户很高兴。

结果如何？ 这只是把它全部卷起来。 它启发了开发人员、高效的管理员和快乐的用户。 这是三合会，也是我认为所有 Web 开发团队真正为之奋斗的希望。

当开发人员受到启发时，他们正在使用一组优化的工具。 感觉很好。 他们很开心。 他们写出更好的代码。

管理员知道他们正在将内容制作到一个美丽的生态系统中。 它很快。 它发货很快。 用户正在看到更新的内容，他们正在体验一个现代、美观、功能良好、优化的前端。

我想把它总结一下——我希望你记住一些最后的想法。 我认为简报本身总是缺少语言。 我认为我们经常谈论的只是，嘿，为我建立一个漂亮的网站。 为我建立一个了不起的网站。 我想要它的外观和感觉——我们已经与客户进行了所有这些评论。

每个人都很兴奋，然后 V1 来了，它发布了。 然后需要接管该网站的人就像，你把我弄得一团糟。 我该如何处理？ 这是您设想的一些临时流程吗？

你不想建立一个漂亮的网站并交出一个负担。 在 Haus，我们为不这样做而感到非常自豪。 我认为 Atlas 和 Atlas 作为一个平台的美妙之处在于它解决了这个问题。

它让您确信您正在运送一个生态系统和一个网络发布系统，从基础设施的角度和代码部署的角度来看，它们实际上是有意义的。 它向 IT 团队和工程团队或营销团队提供书面证据，证明您知道自己在做什么，并且他们现在可以很好地使用您为他们构建的这个新网站。

因为请记住，我们不仅仅是在构建网站。 我们正在建立一个内容发布系统，从第一天开始理解和承认这一点至关重要。 再一次，这就是 Atlas 发挥作用的地方。

所以我希望这个小花絮能帮助你从战略上构想你的无头堆栈向前发展。 如果那是您想采取的方向，我强烈建议您看看 Atlas。 我希望你喜欢这次会议，非常感谢你。