Smashing Magazine 如何管理内容：从 WordPress 迁移到 JAMstack
已发表: 2022-03-10本文得到了我们在 Netlify 的亲爱的朋友的大力支持，Netlify 是一个用于自动化现代 Web 项目的多合一平台。 谢谢！
每次开发人员谈论 WordPress，他们的市场份额百分比都会发生变化。 “ 20% 的网站都在 WordPress 上！ ” “ 40% 的网站都在 WordPress 上！ ” 无论百分比是多少，信息都是一样的：就采用而言，WordPress 是巨大的。
那么，为什么采用这种方式，使用 WordPress 的网站会考虑迁移到 JAMstack 呢？ 在这个由两部分组成的文章系列中，我们将使用您现在正在阅读的站点的案例研究来介绍实际的 WordPress 迁移。
我们将讨论得失，我们希望早点知道的事情，以及我们感到惊讶的事情。 然后我们将跟进一个可能的迁移路径的技术演示——不是完全脱离 WordPress——而是如何为分离的 WordPress 提供服务，这样你就可以两全其美：WordPress 的 JAMstack 实现，它为你提供了所有其仪表板和功能的强大功能，以及更好的性能和安全性。
让我们深入挖掘！
为什么？
2015 年，Netlify 联合创始人 Mathias Biilmann 和 Smashing 创始人 Vitaly Friedman 进行了交谈。 随着 JAMstack 架构开始流行，Smashing 对堆栈的想法越来越感兴趣。 Vitaly 和 Markus（Smashing 的前常务董事）询问 Matt 如果 Smashing 从他们传统的 WordPress/LAMPstack 站点迁移到 JAMstack 架构会发生什么。
作为一项实验，Matt 从 Smashing 中抓取所有 HTML 并将其托管在 Netlify 上，从 CDN 静态交付内容。 结果令人信服——静态版本的平均速度是其六倍以上！
这种类型的架构之所以如此有效，部分原因是您访问页面时不会按需编译页面。 由于您直接从 Content Delivery Network 提供预先构建的内容，因此该站点已经“存在”并可供用户使用。
由于您通过 CDN 提供服务，因此您还可以在全球范围内分发内容——更接近潜在访问者。 没有中心起源点，这对于任何希望为所有读者快速提供速度的在线出版物而言都是至关重要的。
于是舞台就摆好了。 Smashing Magazine 迁移到 JAMstack — 特别是作为一个平台的 Netlify。 在其 10 年的运营中，Smashing 从一个小型在线出版物发展成为一个大型 WordPress 博客，销售书籍、会议门票和研讨会等商品。
这个网站有几个部分：
- WordPress 博客
- Rails 工作委员会
- Shopify 商店
- 会议现场的另一个 CMS
当 Netlify 首次开始迁移时，该网站遇到了一些性能问题，受到 20K 评论和数千篇文章的拖累。 Smashing 还对将身份验证作为新订阅计划的一部分以及重新设计以获得更现代的外观感兴趣。
可靠性
Smashing 经常实现其他平台的梦想：通过庞大的社区广泛分享文章。 但是，当某个帖子的流量达到临界点时，Smashing 经常会遇到中断问题。 为了缓解这种情况，大量使用 WordPress 插件被引入到他们的堆栈中，但他们仍然努力保持良好的正常运行时间指标。
迁移到 Netlify 后，Smashing 团队可以避免出现数据库连接错误，并且即使在文章看到大量流量时也不必担心停机。 为什么？ 因为在没有服务器的情况下提供服务时，不必生成和提供预构建的内容——它已经存在，可以查看。 除了整个静态页面外，当场没有任何请求。
通过 CDN 提供服务也让 Smashing 在安全方面更容易入睡。 wp-login.php长期以来一直是安全漏洞和攻击媒介的来源。 无法以相同的方式访问预构建的内容，并且安全漏洞并不普遍。
缓存失效
Smashing 循环遍历了每个 WordPress 缓存插件，结果各不相同，问题也很多。 Smashing 的 Vitaly Friedman 提到，
“我们遇到的主要问题与我们每隔一周都会遇到的‘错误建立数据库连接’有关，我们确实尝试了每一个 WordPress 缓存插件。 性能还不错（总体而言），但我们希望进一步改进它。 此外，我们确实希望通过一个平台启动会员资格并将所有不同的产品（会议、职位发布、文章、书籍、电子书）连接起来，而使用 WordPress 实现这一目标非常困难。”
迁移到 Netlify 后，Smashing 团队可以看到即时缓存失效，同时还提供缓存和高性能内容，而无需额外开销。
部署站点时，HTML 文件托管在 Netlify 的 CDN 上。 它针对高速缓存命中率和第一个字节的快速时间进行了优化，同时能够立即使所有已更改的 HTML 文件无效。 Netlify 还对指向 CSS 文件、图像、字体或 JS 文件等资产的所有链接进行指纹识别，并为 Smashing 提供永久缓存它们的缓存标头。 指纹保证它们是唯一的，并且如果您更新新版本，则会提供新版本。
工作流程
查看现有设置，迁移的一个重要原因只是为了统一现有属性。 必须在所有这些不同的技术堆栈和设置之间进行上下文切换成为了工程师们面临的一个难以维护的问题。
以前他们的基础设施分散在这么多不同的系统中时，这个迁移过程也统一了一切，使主站点、会议站点、订阅和电子商务部分都一起工作，而不是用不同的堆栈单独维护。 这有助于保持较低的开发成本和一致的开发人员在所有属性上工作的经验。
事实证明，WordPress 迁移部分是最大和最精致的。 Netlify 尝试从 WP 导出器导出数据，却发现内容有嵌入需要保留，或者有时被插件更改。 为了与网站上的内容保持一致，编写了一系列抓取工具，按文章、资产、评论和主页进行细分。
编写和转换后，它会被加载到 GitHub 中的新存储库中，并改用 Netlify CMS。 Netlify CMS 的独特之处在于它是轻量级的，并将内容编辑器集成到 Git 工作流程中——这意味着它实际上将从 git 存储库而不是数据库中提取和提供 markdown 文件。 此外，Netlify CMS 与平台无关，可与（几乎）所有存储在 GitHub 中的静态站点生成器和站点一起使用。
当时，Sara Soueidan 作为一名自由前端开发人员在 Smashing 工作，负责他们的重新设计。 她创建了一个组件库来构建前端架构，并评论说使用起来要简单得多，因为她直接在 git 中工作，即使在使用 CMS 时也是如此。
“我推送到存储库的所有内容都直接应用于模式库，这意味着您不必维护两组不同的组件......这种连续性很棒！ 我所要做的就是编写 HTML、CSS 和 JavaScript 并推送到 repo，一切都像魔术一样工作。 工作流程非常棒。”
综上所述，对于如此高流量和规模的用例，Netlify CMS 有时可能过于轻量级。 Smashing 定期有客座作者和完整的编辑人员。 WordPress 提供的一些丰富功能对这类高度协作的环境非常有帮助。
这就是为什么在下面的教程中，我们将引导您完成一个无头模型，您仍然可以从 WordPress 仪表板为内容创建者获得好处，但通过 API 使用 WordPress 并让开发依赖于以 git 为中心的工作流程，这很容易供开发人员维护。 敬请关注！
框架选择
在 Matt Biilmann 创建的初始原型中，他使用最小的 Preact 编写了所有内容，并与 Hugo 配对，因为他非常关注性能。 他只是使用道具并保持一切都很轻巧。 当他将该项目交给 Smashing 的开发人员 Ilya Pukhalski 维护时，他发现 Preact 缺少一些他们缺少的功能来利用 React 的生态系统。 最终，Redux 和其他库的收益超过了成本。
现在回想起来，Matt 说他会使用 Vue，当时它的市场份额并不大（我发誓我没有让他这么说）。 我问了一个显而易见的问题：为什么不是 Svelte？ 由于注重性能的人倾向于使用该库。 他提到 Svelte 还没有 Vue 的生态系统。
当马特反思他是否还会使用 Hugo 时，他说他喜欢 Hugo，但他发现这个项目特别困难的是它没有足够的插件系统——创建横幅广告和类似的东西Hugo 对这种性质的可编程性不够，他需要注入脚本来完成它。 这些脚本往往会减慢构建过程。 也就是说，我们仍然在netlify.com 上将Hugo 用于我们自己的网站并喜欢它——这个警告特别针对 Smashing 网站的需求。
如果他能再做一次，他可能会选择 Eleventy，它在创建插件和其他可扩展脚本方面具有丰富的能力。 或者，如果他使用 Vue，Nuxt 会为他提供一些不错的插件功能，同时允许成为该框架的不错选择，提供服务器端渲染、路由和静态生成。
建设大型网站
使用像 Smashing 这样大的网站时出现了一个问题，也许您已经知道它是什么，我们刚刚谈到了它。 确实，对于在 CDN 上提供的任何大型预建页面站点，性能仍然很好，因为我们没有为用户即时构建任何东西。
但这种好处只有在站点是预先构建的情况下才能实现，而且这个过程可能很耗时。 虽然更传统的网站会在您请求时构建页面，但我们实际上是提前创建每个页面，以防用户可能需要它。 它使性能超级快！ 但是现在这个时间已经转移到了开发和发布时间——创建每个页面都需要时间。
对于较小的网站，这不是什么大问题，但在 Smashing Magazine 的规模上，我们需要更多地考虑那个时间，特别是这样人们才能在每天积极创建内容的同时保持高生产力。
Netlify 所做的是创建一个大型/production-articles文件夹，其中包含他们已经托管的数千篇文章中的大部分。 然后，创建一个名为content/articles的单独工作目录，可以放置正在创建和编辑的文章。
这个构建过程意味着在该站点上工作的每个人都在处理一小部分用于本地开发的文章，而不受等待整个构建过程的阻碍。 这个过程由一个 gulp 任务来管理以准备生产文章，并让 Hugo 腾出时间来处理正在积极处理的事情。
这种方法的一个缺点是它仍然需要运行整个构建，从而使过程变慢。 在较小的出版物中，这可能不太重要，但在 Smashing 的规模上，它确实会减慢出版过程。
开源 API
一开始，我们提到 Smashing 有兴趣迁移他们现有的电子商务解决方案，处理 WordPress 之外的评论，并为身份验证添加功能。 所有这些功能都是使用 Netlify 维护的开源解决方案构建的，将它们分解为无状态 API：
- GoTell
用于处理大量评论的 API 和构建工具。 - 去商务
一个基于 Go 的小型 API，用于处理订单和支付的电子商务网站。 - 真真
一个用 Golang 编写的小型开源 API，可以作为一个独立的 API 服务来处理项目的用户注册和身份验证。 它基于 OAuth2 和 JWT，将处理用户注册、身份验证和自定义用户数据。
这些部分中的每一个都需要迁移和它们自己的独特因素，虽然它们超出了本文的范围，但它们都包含在 Matt 合着的名为“ JAMstack 上的现代 Web 开发”的免费书籍中。 我们还将在随后的文章中对搜索和身份验证进行一些像这样的深入研究（带有可用示例）。
结论
迁移顺利进行。 粉碎？ 呃……进展顺利。 Smashing 并没有因为其自身的成功而受到惩罚——当一篇受欢迎的文章出现时，他们可以始终如一地提供内容，不再为大量负载而保释。 与此同时，向 JAMstack 基础架构的迁移带来了更好的性能和安全性。
Smashing Magazine 前首席执行官 Markus Seyfferth 指出：
“首次加载的时间比以前快了很多……之前我们必须等待 HTML 文件提供800 毫秒，而现在是80 毫秒。”
这个过程是成功的，就像任何伟大的工程项目一样，在此过程中吸取了教训。 在本系列的下一篇文章中，我们将通过一个教程和演示，根据我们所学的内容来推荐我们的建议。 如果您想现代化您的 WordPress 开发并获得 JAMstack 的性能和安全优势，请继续阅读！