蓋茨比 宣布 其針對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 插件也是必需的。
像這樣：
喜歡載入中……