使用新的gatsby源wordpress插件

在上一篇文章中，我討論瞭如何使用Gatsby Source WPGraphQL插件來創建一個解耦WordPress驅動的蓋茨比網站。該項目是在正在進行的WPGRAPHQL正在進行的開發版本和Henrik Wirth的出色教程之後完成的。儘管當時在某些生產地點使用了WPGRAPHQL，但仍有許多迭代引入了破壞變化。自去年11月WPGRAPHQL V1.0發布以來，該插件穩定，可通過WordPress插件目錄獲得。

WPGRAPHQL插件可用於創建使用WordPress進行內容管理的站點，但具有由Gatsby驅動的前端。我們將其稱為“脫鉤”或“無頭” CMS，因為該站點的後端和前端是單獨的實體，它們仍然通過API互相交談，而前端的組件會消耗來自CMS的數據。

WPGRAPHQL插件網站具有可靠的逐步文檔以開始入門，並且發佈公告帖子列出了使用該插件的九個示例。

從真正的意義上講，“脫鉤”或“無頭”站點，WPGRAPHQL可用於將WordPress數據端口到其他框架，例如Next.js，vue.js等。對於Gatsby Framework，建議使用Gatsby Source WordPress插件，並利用WPGRAPHQL從WordPress來源數據。

讓我們一起設置所有內容並參觀插件。

先決條件

在我的上一篇文章中，我們介紹了設置WordPress和Gatsby網站所需的先決條件，並將後端WordPress數據移植到具有站點部署的蓋茨比驅動的前端站點。我在這裡跳過了很多細節，因為本文的基本概念是相同的，除了WordPress數據由Gatsby Source WordPress插件獲取。

如果您是蓋茨比（Gatsby）的新手，並且剛剛跳入蓋茨比（Gatsby）生成的靜態站點生成器潮流，我建議您閱讀React Expert David Cramer和Jared Palmer的“ React Expert David Cramer和Gatsby vs Next.js”的“誠實評論”。我們將要涵蓋的不是每個人，這些文章可能會對自己評估是否適合您和您的項目。

WPGRAPHQL或GRAPHQL是Gatsby框架中使用的主要查詢語言API。 GraphQL中經常進行更新，通常需要專家知識並留意破壞變化。畢竟，GraphQL是由React專家為其他React專家設計的。也就是說，有一些故障排除說明和WPGraphQL鬆弛，其中WPGraphQL和Gatsby Source WordPress插件作者都積極參與並幫助回答問題。

本文不是有關如何使用Gatsby Source WordPress插件的分步指南。同樣，蓋茨比的文檔已經可以使用。相反，如果您碰巧是React，JavaScript，Node.js或GraphQl的專家，那麼我們在這裡涵蓋的內容可能是您已經知道的東西。本文是根據我的個人經驗的意見文章，我希望這對具有有關該主題的基本工作知識的普通WordPress用戶很有用。

而且，在開始之前，值得一提的是，蓋茨比源WordPress插件已在版本4中完全重寫，並使用WPGRAPHQL作為數據源。以前的版本3版是用REST API作為數據源構建的。由於該插件的穩定版本最近發布了，因此支持其的起動主題和演示的數量是有限的。

首先，我們需要WordPress

對於這個項目，我使用Flywheel的Local設立了一個新的WordPress網站，該網站使用默認的20個主題。如WordPress法典所述，我導入頁面和帖子的主題單元測試數據。雖然這是我正在使用的基線，但這很容易成為現有的WordPress站點，該網站要么在遠程服務器或本地安裝上。

現在我們已經建立了基線，我們可以登錄WordPress管理員，並安裝我們需要並激活它們的WPGRAPHQL和WPGATSBY插件。

正如我們在上一篇文章中所介紹的那樣，這是在WordPress Admin中揭示GraphQL和WPGraphiQl API，從而允許GraphIQL API創建一個基於WordPress數據測試GraphQl查詢的“遊樂場”。

現在我們需要蓋茨比前端

蓋茨比（Gatsby）以良好的文檔和固體起動模板而聞名。為了創建一個新的WordPress驅動的網站，Gatsby教程建議使用啟動器或從頭開始使用，這對我們正在做的事情就可以了。

蓋茨比還為圍繞特定技術構建的基本用例提供了示例網站庫。當前恰好有一種使用WordPress，並且將WordPress與高級自定義字段插件一起使用。請注意，庫中的示例站點仍然使用gatsby-source-wordpress插件3，並且在撰寫本文時尚未更新到版本4。

根據Gatsby教程，創建以WordPress為動力的Gatsby網站有三個選擇。讓我們看看每個人。

選項1：使用蓋茨比起動器

這些文檔有一個有關如何設置WordPress-Gatsby網站的分步指南，但這是要點。

在命令行中運行以下內容，以從GitHub存儲庫中獲取啟動器，並將其克隆到My-Wpstarter項目文件夾中：

 ＃！克隆起動器存儲庫
蓋茨比新的my-wpstarter https://github.com/gatsbyjs/gatsby-starter-wordpress-blog

然後，安裝NPM軟件包

＃！ NPM
NPM安裝

＃！或紗
紗線安裝

現在，將啟動器克隆起來，讓我們在代碼編輯器中打開gatsby-config.js文件，然後更新其URL選項以從我們的WordPress端點獲取數據（請參見上文）。

 // gatsby-config.js
{
  解決：蓋茨比詞法，
    選項： {
     // WordPress是GraphQl URL。
     URL：process.env.wpgraphql_url || https://wpgatsbydemo.wpengine.com/graphql，
  }，，
}，，

現在，我們將用我們自己的WordPress網站URL替換啟動器的數據源端點URL：

 // gatsby-config.js文件
{
  解決：“蓋茨比 - 蘇格爾”，
  選項： {
    URL：`http：// gatsbywpv4.local/graphql`，
  }，，
}，，

讓我們確保我們在My-Wpstarter項目目錄中。從項目文件夾中，我們將運行gatsby開發命令，以從WordPress數據源端點構建我們的新蓋茨比網站。在終端中，我們應該能夠看到蓋茨比源字插件的獲取數據，包括沿途錯誤和成功的站點流程。

如果我們在末尾看到成功的構建開發捆綁包消息，那意味著蓋茨比站點構建過程已經完成，並且可以在http：// localhost：8000上查看該站點。

這是一個帶有基本文件和一些組件的小型入門博客。它的文件結構與Gatsby-Starter-Blog非常相似，只是該文件具有一個模板文件夾，其中包括Blog-post.js和Blog-post-achive.js模板文件。

當我們在http：// localhost：8000/___ graphql上查看GraphIQL API資源管理器時，我們可以看到WPGRAPHQL公開的WordPress的所有數據，以及從UI中查詢和檢索特定數據。

你明白了！蓋茨比（Gatsby）認為其餘的要由我們構建，使用蓋茨比組件將WordPress數據吸入演示文稿。

選項2：從頭開始建造

Gatsby的文檔提供了有關如何使用Gatsby的默認入門主題從頭開始創建新的WordPress-Gatsby網站的詳細分步指南。

我們將從命令行旋轉一個新項目：

 ＃！創建一個新的蓋茨比網站
蓋茨比新的wpgatsby-from-scratch-demo

這為我們提供了一個包括入門主題的wpgatsby-from-scratch-demo文件夾。從這裡，我們將CD到該文件夾​​並開始開發：

 cd wpgatsby-from-scratch-demo
蓋茨比發展

現在，我們可以在瀏覽器中打開http：// localhost：8000，並獲取歡迎頁面。

現在，我們很高興開始從WordPress網站開始獲取數據。讓我們安裝蓋茨比源插件：

 ＃！使用RPM安裝
NPM安裝gatsby-source-wordpress

＃！使用紗線安裝
紗線添加蓋茨比源字

如果我們現在檢查瀏覽器，您會發現什麼也不會發生 - 我們仍然受到同樣的歡迎。要獲取我們的WordPress網站數據，我們需要將插件添加到gatsby-config.js文件中。打開文件並插入以下內容：

 // gatsby-config.js
Module.exports = {
  sitemetadata：{
    // ...
  }，，
  插件：[
  //添加gatsby-source-wordpress插件
  {
      解決：“蓋茨比 - 蘇格爾”，
      選項： {
        /*
         * WordPress網站的GraphQl API的完整URL。
         *示例：'https：//www.example-site.com/graphql'
         */
        URL：`http：// gatsbywpv4.local/graphql`，
       }，，
     }，，
    // Gatsby-Source-Wordpress不需要以下插件。
  ]，，
}

就像上次一樣，我們需要將WordPress數據端點源更改為WordPress站點的URL。讓我們在終端中開發蓋茨比以開始工作。

但是，當我們在瀏覽器中打開http：// localhost：8000時，似乎什麼都沒有發生。我們仍然看到相同的歡迎屏幕。但是，如果我們在瀏覽器中檢查GraphIQL（在http：// localhost：8000/___ graphql），那麼我們會看到所有WordPress數據暴露於我們的蓋茨比站點，我們可以根據需要查詢和顯示。

讓我們測試以下查詢，我在Graphiql Explorer中直接從Gatsby的教程中拉出：

詢問 {
  allwppost {
    節點{
      ID
      標題
      摘抄
      sl
      日期（格式化：“ mmmm dd，yyyy”）
    }
  }
}

當我們運行上述查詢時，我們將看到allwppost.nodes屬性值，具有ID，標題，摘錄等的子屬性。

現在，讓我們打開我們的src/components/pegages/index.js組件文件，然後用以下方式替換代碼：

 // src/components/pages/index.js
從“反應”導入反應
從“ gatsby”導入{graphql}
從“ ../components/layout”導入佈局
從“ ../components/seo”導入SEO

導出默認函數home（{data}）{
  返回 （
    
      <seo title="“" home></seo>
      <h1>我的WordPress博客</h1>
      <h4>帖子</h4>
      {data.allwppost.nodes.map（node =>）
        <div>
          <p> {node.title} </p>
          <div divallyseinnerhtml="{{{__html：node.excerpt}}}"></div>
        </div>
      ）}}
    
  ）
}

導出const pagequery = graphql`
  詢問 {
    allwppost（sort：{fields：[date]}）{
      節點{
        標題
        摘抄
        sl
      }
    }
  }
`

保存它，通過開發蓋茨比的開發重新啟動服務器，然後刷新頁面。如果構建成功，那麼我們網站的主頁應顯示WordPress的分類博客文章列表！

教程之後，讓我們為每個博客文章創建頁面，然後將帖子標題從列錶鍊接到帖子頁面。在蓋茨比基礎教程的第7部分中詳細描述了使用降價數據創建頁面的過程，我們也將在此處遵循。

如教程中所述，Gatsby使用CreatePages API或所謂的“ Workhorse” API，以從數據（從Markdown或WordPress）編程中創建頁面。與Markdown數據不同，我們不需要在此處創建一個slug，因為每個WordPress帖子都有其自己的獨特sl，可以從WordPress數據終點獲取。

為每個帖子創建頁面

Gatsby使用位於我們項目根源的Gatsby-Node.js文件來編程創建博客文章。讓我們在文本編輯器中打開gatsby-node.js文件，從教程中添加以下代碼。

 // gatsby-node.js 
const路徑= require（`路徑）

exports.CreatePages =（{graphQl，action}）=> {
  const {createpage} =動作
  返回GraphQl（`
    {
      allwppost（sort：{fields：[date]}）{
        節點{
          標題
          摘抄
          內容
          sl
        }
      }
    }
  `）。然後（結果=> {
    console.log（json.stringify（結果，null，4））
    process.exit（）
  }））
}

如Gatsby第7部分教程中指出的那樣，上述代碼是從WordPress數據源創建我們的POST頁面的第一部分。遵循指南，讓我們重新啟動我們的服務器，並隨著Gatsby開發開發我們的網站。

在構建頁面時，我們應該在終端中看到Console.Log輸出）。但是，我們的主頁看起來仍然一樣。要創建單個帖子，蓋茨比（Gatsby）需要模板來構建頁面，我們將在下一步中創建。

創建博客文章模板

讓我們在SRC/Directory中創建一個SRC/組件/模板文件夾，並通過從教程中粘貼以下代碼段來創建Blog-post.js文件：

 // src/templates/blog-post.js
從“反應”導入反應
從“ ../components/layout”導入佈局
從“ gatsby”導入{graphql}

導出默認函數blogpost（{data}）{
  const post = data.allwppost.nodes [0]
  console.log（帖子）
  返回 （
    
      <div>
        <h1> {post.title} </h1>
        <div divand drangeslysetinnerhtml="{{__html：post.content}}"></div>
      </div>
    
  ）
}
導出const查詢= graphql`
  查詢（$ slug：string！）{
    allwppost（filter：{slug：{eq：$ slug}}}）{
      節點{
        標題
        內容
      }
    }
  }
`

如教程中所述，上面的代碼片段創建了一個帶有react JSX和包裝帖子的帖子。在文件的底部，添加了GraphQl查詢，並根據Post Slug變量$ slug調用特定帖子。當在gatsby-node.js創建頁面時，此變量將傳遞給博客post.js模板。

接下來，我們還應使用教程中的以下代碼更新gatsby-node.js文件的第12-13行。

 // gatsby-node.js
const路徑= require（`路徑）

 exports.CreatePages =（{graphQl，action}）=> {
   const {createpage} =動作
   返回GraphQl（`
     {
       allwppost（sort：{fields：[date]，order：dec}）{
         節點{
           標題
           摘抄
           內容
           sl
         }
       }
     }
   `）。然後（結果=> {
    result.data.allwppost.nodes.foreach（node => {
        createpage（{
          路徑：node.slug，
          組件：path.resolve（`。
          情境: {
            //這是傳遞給blog-post.js的$ slug變量
            slug：node.slug，
          }，，
        }））
      }））
   }））
 }

讓我們停止使用Gatsby開發並查看網站的本地服務器。我們不會看到我們的主頁，其中包含博客文章鏈接的列表。但是，如果我們與http：// localhost：8000/abcdf核對，我們應該查看以下404頁，其中包含單個頁面和帖子鏈接的列表。

如果我們檢查http：// localhost：8000/hello-gatsby-world，我們應該在其所有榮耀中我們的“ Hello Gatsby WordPress World”帖子。

下一步是將帖子標題從主頁鏈接到實際帖子。

鏈接到主頁的帖子

將從主頁鏈接到帖子頁面的工作是通過用蓋茨比的鏈接組件包裝在index.js文件中的帖子標題來完成的。讓我們打開我們之前創建的index.js文件，並添加鏈接組件：

 // src/components/pages/index.js
從“反應”導入反應
導入{link，graphQl}來自“ gatsby”
從“ ../components/layout”導入佈局
從“ ../components/seo”導入SEO

導出默認函數home（{data}）{
  返回 （
    
      <seo title="“" home></seo>
     {/* <h1>我的WordPress博客</h1>
      <h4>帖子</h4> */}
      {data.allwppost.nodes.map（node =>）
        <div key="{node.slug}">
          
            <h2> {node.title} </h2>
          
          <div divallyseinnerhtml="{{{__html：node.excerpt}}}"></div>
        </div>
      ）}}
    
  ）
}

導出const pagequery = graphql`
  詢問 {
    allwppost（sort：{fields：[date]，order：dec}）{
      節點{
        標題
        摘抄
        sl
      }
    }
  }
`

我們從Gatsby導入了鏈接組件，然後用鏈接組件將帖子標題包裹起來，並引用了帖子的slug。讓我們通過評論頁面標題，將標題元素更改為

，然後在我們的GraphQl查詢中添加DEC以及gatsby-node.js文件來清理代碼。

正如我們之前所做的那樣，讓我們​​停止使用Gatsby開發並重新啟動開發服務器，並在http：// localhost：8000上查看我們的主頁。帖子標題應鏈接到單個帖子頁面。

就我們要採用第二種方法而言。我們涵蓋的其餘內容將描述如何獲取菜單項並查詢其他數據類型（例如自定義帖子類型），並配置增量構建和預覽等。

您可以將相同的過程應用於呼叫和創建頁面，自定義帖子類型，自定義字段，分類法以及所有有趣且靈活的內容WordPress眾所周知。這可以像您想要的那樣簡單或複雜，因此請探索並玩得開心！

- Gatsby教程文檔

選項3：使用Gatsby的WordPress二十二十個起動器

Henrik Wirth創建和維護了Gatsby的默認WordPress二十二十個主題的啟動模板，他還擁有一個非常詳細且詳盡的逐步指南，您可能會從我的上一篇文章中回憶起。與其他啟動器不同，該啟動器實際上已更新為蓋茨比源插件的版本4，並在文檔中描述的初始WordPress設置後開箱即用。它在Gatsby前端站點中保持了相同的二十二十種樣式，但幾乎沒有限制（包括評論，每月檔案頁面和標籤），這些限制是不支持的。

首先，讓我們在我們的22個啟動文件夾中克隆啟動器。

 ＃！克隆·蓋茨比（Clone Gatsby-Starter-Starter）二十千歲 
Gatsby New 22 Starter https://github.com/henrikwirth/gatsby-starter-parter-wordpress-wordpress-twenty

讓我們進入該文件夾，然後運行Gatsby開發以旋轉站點。它第一次無法正常工作，因為我們尚未在Env.example文件中更改WPGRAPHQL_URL值。如文檔中所建議的那樣，我們需要將文件重命名為.env.example簡單地為.env。

之後，隨著Gatsby開發重新啟動開發服務器。它應該成功構建網站。

菜單可能會取決於WordPress菜單的命名方式，也可能不會出現。入門菜單菜單菜單項是菜單中的主要菜單項（第8行）。因為我已經使用Main-Menu設置了WordPress網站，所以我必須相應地更新菜單。

由於啟動器已使用我們的工具的較舊版本進行了測試，因此我決定將插件撞到最新版本-WPGRAPHQL 1.2.6，WPGATSBY 1.0.6和GATSBY Source WordPress 4.0.1-並且它效果很好，沒有任何錯誤。

二十二十個起動器遵循了二十九十Gatsby主題的文件結構，以及Gatsby Starter WordPress Advanced。 Henrik Wirth描述了WordPress數據如何在他的分步指南中移植到Gatsby，而Muhammad Muhsin也在教程中也是如此。否則，創建頁面，頁面模板，移植菜單項是完全相同的。

該啟動器使用默認WordPress二十二十個主題的CSS，以及相同的資產文件夾，包括字體，圖像，SVG文件和默認主題中包含的其他文件。

如果您對WordPress二十二十種樣式感到滿意，就是這樣。享受您的新脫口蓋茨比網站！

但是，假設我們想使用自定義樣式。 CSS文件是通過gatsby-browser.js文件從資產文件夾導入的。

讓我們修改網站的標題，頁腳，帖子和頁面的樣式。蓋茨比（Gatsby）提供了不同的選項來設置其組件，在此項目中，我遵循CSS模塊進行樣式和修改的CSS標記，對二十二十個啟動器組件進行了相應的評價。

我們可以首先在SRC/組件/樣式上創建一個樣式文件夾，並在其中創建一個基本文件夾。這是我們目標的一般文件結構：

 ＃！ /樣式文件夾的部分結構
src
 |  - /組件
   |  - /樣式
     | -main.css          
     |  - /base
       |  -  reset.css
       |  -  variables.css
     |  - /scss
       | -HEADER.MODULE.CSS
       | -mainnav.module.css
       | -footer.module.css
       |  -  elements.module.css
       // 等等...

我們想為網站的標頭和頁腳設計樣式，因此讓我們打開啟動器中的header.js和footer.js組件，然後用以下內容替換代碼：

 // src/components/header.js
從“反應”導入反應
導入{graphQl，link，usestaticquery}來自“ gatsby”
從“ ./menu”導入菜單
從“ ../styles/scss/header.module.css”導入樣式
從'../images/gatsby-icon.png'導入徽標'

const header =（）=> {
  const {wp} = usestaticquery（graphql`
    {
      wp {
        將軍{
          標題
          描述
        }
      }
    }
  `）
  返回 （
    <header classname="{style.masthead}">
      <div classname="{style.masthead_info}">

      
        <img src="%7Blogo%7D" alt="“" logo    style="max-width:90%" height="“" display="“" inline-block marginbottom="“" classname="{style.site.site_logo}">
      
      <div classname="{style.site_header}">
        <div classname="{style.site_title}">
          
        </div>
        <div classname="{style.site_description}" dankinglysetinnerhtml="{{{__html：wp.generalsettings.description}}}"></div>  

      </div>
      
    
  ）
}

導出默認標頭<p>同樣，腳步器.js組件被修改如下：</p>
<pre rel="JavaScript" data-line=""> // src/components/footer.js
從“反應”導入反應

從“ ../styles/scss/footer.module.css”導入樣式

導出默認（）=>（
  
    <p>©{new Date（）。getlualear（）} |該站點由{''} <a href="%E2%80%9C" https:> gatsbyjs </a> {'and'}
  
）</p>

現在，讓我們重新啟動開發服務器。我們應該看到以下內容，包括一個新的定制標題和頁腳。我從Learning Gatsby中使用了相同的風格，該風格是Morten Rand-Hendriksen的在線課程（我是粉絲！）。

您可以在GitHub抓住我使用的所有代碼。

這對WordPress愛好者意味著什麼

有許多帖子比較了脫鉤的WordPress和Jamstack網站的優勢和缺點，例如我們涵蓋的蓋茨比示例。在我的研究中，我意識到，沒有一個像克里斯在“ WordPress和Jamstack”中所寫的那樣詳盡，在那裡他比較了從性能和功能到開發人員體驗和建立過程以及其他所有內容的所有內容。

我發現以下文章就各種主題得出了一些有用的結論，包括：

費用是多少？

總體假設是，jamstack託管價格便宜，並且比傳統的燈泡託管便宜。但是實際上有很多要考慮的事情，您的實際成本可能會有所不同。

• “如何免費在本地，蓋茨比和Netlify上運行WordPress網站！” （Nate Fitch）：Nate的看法是，如果項目是靜態博客或不需要任何交互的網站，則像這樣的無頭WordPress設置可能是一個不錯的選擇。例如，將託管在Cloudinary或其他CDN上託管的圖像並不需要太多工作，但是對於大型交互式站點而言。
• “ WordPress和Jamstack” （Chris Coyier）：在這裡有一個特定部分，克里斯在jamstack站點的不同類型的託管上分解了定價，以及為什麼像“ jamstack更便宜”這樣的毛毯語句，因為實際的成本依賴於該網站及其用途，因此不飛翔。
• （Zell Liew）：Zell討論了他選擇託管計劃的經驗， “在Netlify，Vercel和Digital Ocean之間進行選擇” 。他的看法：如果您有一個小項目，請與Netlify一起去；如果您有一個更大的項目，請使用數字海洋。

為什麼要靜態？

考慮到WordPress中“免費”的所有內容 - 考慮評論，插件，集成等 - 您可能會想知道它是否值得在服務器端設置中以用於客戶端解決方案進行交易。在他的“靜態？”中帖子，克里斯打破了您要選擇另一個選擇的原因。

我們如何獲得評論功能？

我們通過WordPress即將發表評論。但是，在靜態網站上對評論的支持有點像司令。在CSS-Tricks上的“ Jamstack評論”中，作者解釋瞭如何使用NetLify Services在Gatsby等靜態網站中實現動態評論。我在上一篇文章中簡要介紹了這一點。

SEO呢？

• “用於WPGRAPHQL和YOAST的Gatsby SEO” （Gatsby Community插件）：可以使用此插件將廣泛使用的用於WordPress的Yoast SEO插件集成到蓋茨比前端。
• “關於WordPress的JavaScript SEO的入門” （Jono Alderson）：該詳盡的指南包括有關如何將Yoast SEO集成到無頭體系結構中的部分，以及依靠JavaScript對SEO的含義。最重要的是，只要繼續遵循最佳實踐，主題和插件開發人員就不必擔心JavaScript和SEO的景觀不斷變化。同時，他們應該意識到發生了什麼變化和適應。

事情如何一起工作？

• “ Gutenberg和Decled應用程序” （Jason Bahl）：Jason是WPGRAPHQL的創建者和維護者，並且對在解耦應用中使用新的WordPress塊編輯器進行了深入的研究。
• “ Wpgraphql的Jason Bahl在網絡操作系統中的角色” （YouTube）：這一次是Jason，這次討論了模板。他涵蓋了WPGraphQL在WordPress生態系統和無頭蓋茨比站點中的作用，強調WPGRAPHQL與數據曝光有關，就像WordPress REST API一樣。 WPGRAPHQL如何在Gatsby中公開WordPress數據並在前端React組件中顯示其取決於開發人員。

目前，沒有針對非開發人員的Gatsby React模板，但是某些機構（例如Gatsby WP主題和ThemeForest Marketplace）開始填補空白。例如，Gatsby WP主題涵蓋了用於MailChimp Integration（MailChimp Integration）的動態內容的插件，並使用contack 7插件的表單，yoast SEO等。 ThemeForest列出了30個蓋茨比模板，包括蓋茨比 - WordPress電子商務主題，它使您了解我們可以使用這種設置多遠。請記住：這些都是商業網站，您發現的大部分內容都附有成本。

我不斷發展的個人看法

如果您還記得的話，我在上一篇文章中以個人的思考結束了我的旅程，以創建一個無頭的WordPress網站，該網站將Gatsby用作前端。我最初的看法還不是一份發光的評論：

根據我非常有限的經驗，我認為目前可用的蓋茨比WordPress主題還沒有為像我這樣的用戶準備黃金時間使用。是的，在許多WordPress用戶和開發人員腦海中顯然是在出血邊緣上嘗試一些東西是令人興奮的。同時，在WordPress塊編輯器，WPGRAPHQL和GATSBY SourcePress插件上不斷發展的工作使得很難預測事物的發展何方，並且何時將其安裝到其他情況下安全使用的狀態。

因此，在這一切之後，我漫長的前往無頭WordPress網站的旅程，我現在的看法是什麼？作為一個開放的學習者，我的想法仍在發展。但是我不同意克里斯在他的“靜態與否”中所說的話？郵政：

運行WordPress網站是一個完全可以接受且通常是聰明的選擇。我從魯棒性和功能準備方面考慮這一點。需要電子商務嗎？在那裡。需要表格嗎？有很棒的插件。需要增加CMS的工作原理嗎？您可以控制內容的類型以及其中的內容。需要auth嗎？那是一個核心功能。希望您有很好的編輯體驗？古騰堡很光榮。

我是WordPress的愛好者，我喜歡WordPress作為CMS。但是，作為一項技術學習挑戰，我還沒有放棄將脫鉤的WordPress網站作為個人項目。

我必須承認，學會用WordPress創建一個脫鉤的蓋茨比網站一直令人沮喪。我承認，對於許多WordPress用戶而言，任何現代技術堆棧都不是“一杯茶”。蓋茨比（Gatsby）具有陡峭的學習曲線，因為這些堆棧針對經驗豐富的React和JavaScript開發人員。

自我學習新技術可能是一種令人沮喪的體驗。如果我們（包括您的真正）缺乏節點，React，JavaScript以及最重要的是GraphQl的經驗，那麼學習Gatsby尤其令人沮喪。我的學習項目網站會因某種依賴性而破裂，並修復它可能需要花幾天的時間研究。有時我想知道麻煩是否值得結果。不要誤會我的意思；我的挫敗感是我自己缺乏經驗，而不是框架本身（因為它們很棒）。

甚至像大衛·克萊默（David Cramer）和賈里德·帕爾默（Jared Palmer）這樣的經驗豐富的開發人員，使用蓋茨比（Gatsby）和graphql令人沮喪，並回應了我們初學者使用GraphQl時面對的一些情感。我與寫道的大衛完全同意：

這是一個靜態網站發電機。從字面上看，它不需要graphql。儘管在現實世界中很少有有價值的實例，但它不應要求GraphQL API讀取已經在內存中的對象。

GraphQL是一種自以為是的查詢語言API，其規範經常更改。實際上，WPGraphQL鬆弛中的大多數討論都與查詢有關。

在進行這個項目時，我在閱讀有關CSS-Tricks的文章時越過了界面的React框架。它在不編寫單個查詢的情況下使用REST API獲取所有WordPress數據。至少對於我的用例，這似乎是一個更好的選擇。此外，這似乎是一種簡單得多的選擇。在我的簡短經驗中，我根本不必處理任何依賴性或圖書館問題。 Frontity的主題概念是如此的WordPress-Y，並提供了出色的教程。

我目前正在探索“前線框架”是否將是我脫鉤的項目網站的更好選擇，並將分享我在以後的文章中的經驗。

資源

蓋茨比（Gatsby）覺得它是針對經驗豐富的React和JavaScript開發人員的目標，而不是像我這樣的初學者！ Gatsby-source-wordpress和Gatsby-Source-WPGraphQL插件在將WordPress數據展示到Gatsby網站上做得非常出色，但是其餘的則由用戶使用您選擇的框架在前端顯示數據：React，vue，vue，vue，vue，next，etct，etct，ext。

缺乏對React和JavaScript的合理知識是初學者的主要障礙。蓋茨比社區填補了許多此類空白，並且有很多可供學習和探索的資源。

蓋茨比會議2021會談

最近2021年蓋茨比大會的兩個研討會與蓋茨比WordPress網站有關。在一個中，傑森·巴爾（Jason Bahl）舉辦了一個研討會，該研討會瀏覽瞭如何創建由WordPress數據提供動力的蓋茨比博客，包括支持Yoast SEO插件，以及如何將網站部署到Gatsby Cloud。

WP Engine的Matt Landers舉辦了另一個研討會，他演示瞭如何使用高級自定義字段插件來創建團隊成員頁面。

這兩個談話都很好，尤其是如果您通過實踐經驗更好地學到更好的話。我還發現了與傑森·巴爾（Jason Bahl）的馬特報告播客劇集，傑森（Jason）回答了針對初學者的基本問題。

教程課程

莫滕·蘭德·亨德里克森（Morten Rand-Hendriksen）在LinkedIn學習方面擁有出色的課程，該課程使用了Gatsby Source WordPress插件。如果您對更多的動手經驗感興趣，可以在我們涵蓋的兩個蓋茨比開始者上擴展自定義網站，那麼本課程很棒，因為在教學中，如何創建一個完整的工作網站，並配有下拉標頭導航，頁腳菜單，帖子，頁面，類別，類別，標籤和頁面導航。

該課程的練習文件可在GitHub LinkedIn學習存儲庫中獲得。

蓋茨比初學者

當時我寫這篇文章，WordPress有十個Gatsby首發。如前所述，只有Gatsby首發WordPress二十二十是基於Gatsby Source WordPress插件的最新版本。其餘的是版本3。

感謝您的閱讀。我總是很想知道缺乏像我這樣的大量技術經驗的WordPress用戶正在使用此插件。如果您有任何反饋，請隨時在評論中發布它們。