盖茨比 宣布 其针对WordPress的新源插件（v4）现在处于测试阶段。 该插件已经过全面改进，可以改善 无头的WordPress 设置盖茨比为前端提供动力的地方。 它还与 盖茨比云 提供实时预览和增量构建。
Gatsby团队在为能够满足更复杂用例的WordPress网站创建集成上进行了漫长的旅程。 目前，将Gatsby与WordPress结合使用的方式有3种，各有各的优缺点：
- Gatsby源WordPress + WP REST API
- Gatsby源GraphQL + WPGraphQL
- Gatsby源WordPress（v4）+ WPGraphQL
第一种方法依赖于WP REST API来获取所有数据（帖子，术语，媒体等）并将数据缓存在Gatsby的节点缓存中。 第二种方法允许开发人员编写GraphQL查询以从Gatsby缓存中获取数据并在模板中呈现该数据。
根据Gatsby工程师和WPGraphQL的创建者Jason Bahl所说，前两种方法仅适用于基本用例。
Bahl说：“当您开始添加更多高级功能时，例如Advanced Custom Fields Flex Fields，WP REST API开始崩溃，并且很难以分离的方式使用。” “ WP REST API具有一个架构，该架构可以允许插件和主题扩展WP REST API并声明任何给定端点将公开的数据类型。 这有助于解耦的应用程序提前知道要什么样的数据。
“问题在于，插件和主题可以在不使用Schema的情况下扩展WP REST API，或者只需将Schema中的字段类型定义为object类型或array类型即可。 这意味着要让包括Gatsby在内的应用程序解耦，没有简单的方法来知道对这些领域的期望。 Gatsby依赖一致的数据，而WP REST API不一致。 从端点返回的数据形状（尤其是当插件扩展REST API时）是无法预测的，这对于分离的应用程序来说是个问题。”
WPGraphQL是WP REST API的替代产品，它通过其强制实施的Schema解决了许多这些难题。 这使诸如Gatsby之类的解耦工具受益匪浅，因为它们可以对模式进行内部检查，以在请求任何数据之前确定可用的数据。
“因此，即使在高级自定义字段弹性域这样的情况下，返回的数据可能是许多可能的弹性域布局中的一种，盖茨比仍然可以在请求数据之前知道可能的数据，” Bahl说。 “ WPGraphQL的强制性架构使解耦的工具可以放心地交付，并消除了所有类型的错误。”
Gatsby Source GraphQL + WPGraphQL方法相对于使用WP REST API进行了一些改进，但是由于它不将数据缓存到Gatsby节点缓存中而受到限制。 这使WordPress网站无法利用Gatsby的基于云的商业产品进行预览和增量构建。 Bahl解释说，新的Gatsby Source WordPress插件（v4）+ WPGraphQL如何成为“两全其美”：
它在WordPress服务器上使用WPGraphQL在Typed GraphQL模式中公开WordPress数据。 Gatsby源WordPress v4使用GraphQL自省从WordPress网站读取模式，并在Gatsby中构建几乎相同的模式。 然后，它使用WPGraphQL提取数据并将数据缓存在Gatsby中。 然后，用户使用GraphQL与Gatsby缓存进行交互，并获取数据以在其Gatsby站点的组件中进行渲染。
新的集成使内容创建者可以单击“预览”以在Gatsby支持的网站中实时查看他们的更改。 发布不再需要完整的网站重建。 它只会将更改推送到受影响的页面。 更改将在几秒钟内完成，类似于用户期望WordPress在没有无头的集成的情况下如何工作。 新的插件与Gatsby Cloud结合使用，将内容创建体验与Gatsby的React + GraphQL开发人员体验更好地结合在一起，同时在前端提供快速的静态页面。
如果您想测试新的Gatsby Source WordPress插件的beta版，则可以找到它（及其依赖项） 在GitHub上。 的 WPGraphQL 和 WPGatsby 插件也是必需的。
像这样：
喜欢加载中……