使用技巧

Beta版现已提供新的Gatsby源WordPress插件

Beta版的新Gatsby源WordPress插件现在在Beta中

盖茨比 宣布 其针对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上。 的 WPGraphQLWPGatsby 插件也是必需的。

像这样:

喜欢加载中……

资源