無頭 CMS：帶有 WordPress 的 Gatsby JS

已發表: 2020-05-04

眾所周知，WordPress 覆蓋了全球前 100 萬個網站中的大約三分之一，在內容管理系統中擁有超過 50% 的市場份額。就在 2016 年，WordPress 決定引入 REST API 來為其他應用程序提供改進的對 WordPress 數據庫中內容的訪問。結果，為開發人員提供了利用 WordPress 作為無頭 CMS 的能力。

這不可避免地意味著工程師將不再局限於使用 WordPress 的傳統表示層（前端），而是現在可以利用任何前端應用程序來傳遞他們的數據。鑑於此，本博客的大部分內容將探討 WordPress 和 Gatsby.js 在 Headless CMS 效果方面的關係。

CMS 簡史

當我們退後一步了解無頭 CMS 革命時，我認為回顧內容管理系統 (CMS) 的歷史是值得注意的。傳統上，在 90 年代初期，靜態網頁是執行網站的主要方式，網站管理員可以直接編輯 HTML 文件並通過 FTP 將它們上傳到服務器。最終，在 90 年代中期，Web 技術開始發展，內容變得更加動態，導致出現了第一個單一的內容管理系統。

從本質上講，Monolithic CMS 是一個軟件應用程序，其中包括在 Web 上編輯和發佈內容所需的一切。此類系統中的第一個僅限於 EpiServer 等企業，但是後來出現了 WordPress、Drupal 和 Joomla 等開源變體。其餘的都是歷史，因為 WordPress 隨著時間的推移獲得了最大的市場份額。

然而，在智能手機革命後期，移動設備開始影響 Web 內容的消費和交付方式。這對旨在為筆記本電腦和台式機提供 Web 內容的傳統單體 CMS 構成挑戰。

為了緩解這種情況，響應式設計應運而生，從而使網站佈局適應屏幕尺寸。因此，這也提供了將內容管理與顯示層分離的機會。這就是我們的無頭 CMS 的用武之地。

無頭 CMS

如前所述，無頭 CMS 是一種沒有表示層的 CMS。因此，內容通過 API（RESTful 或 GraphQL）傳遞到單獨的前端應用程序，然後再呈現它。 API 使用各種工具和編程語言，使內容可用於任何渠道和設備，具有更高級別的安全性和可擴展性。

從本質上講，CMS 與前端問題解耦，這反過來又使開發人員能夠使用可用的最佳技術為最終用戶構建豐富的體驗。目前大多數 CMS 都支持“無頭”或“解耦”模式，這為 Gatsby 網站鋪平了道路。

因此，要利用無頭 CMS，您必須先構建您的網站或應用程序，然後使用 CMS 的 API 插入您的內容。

WordPress Headless CMS 執行

關於上面分享的事件的年表，我們已經看到 WordPress 如何最終實現了無頭 CMS。 WordPress 包含一個 API（應用程序編程接口），允許您使用插件（本質上作為“應用程序框架”）對其進行擴展。具體來說，這是通過 REST API 實現的，我們稍後會介紹。

然而，WordPress API 的關鍵概念之一是鉤子。基本上，鉤子允許插件改變 WordPress 的核心功能。實際上，鉤子的工作方式是當 WordPress 中的某個事件發生時（例如，頁面加載或後期編輯），WordPress 調用某個鉤子來運行該函數。

具體來說，鉤子分為“動作”和“過濾器”。可以利用操作在某些事件中運行某些 PHP 函數，儘管這些函數不需要返回任何內容。而過濾器可用於運行 WordPress 在某些事件期間傳遞數據的函數，這些函數將數據作為參數並返回數據的修改版本。

WordPress 和 REST API

Representational state transfer (REST) 基於 HTTP 協議，並提供統一的接口語義來創建、讀取、更新和刪除數據 (CRUD)。

通常，WordPress 中的 REST API 執行使開發人員能夠通過發送和接收 JSON（JavaScript 對象表示法）對象來遠程訪問 WordPress 數據庫中的數據。因此，這為開發人員提供了從非 WordPress 設計的其他應用程序創建、讀取、更新和刪除 WordPress 數據的機會。例如，JavaScript Web 應用程序或原生移動應用程序。

但是，隨著我們深入了解 Headless WordPress CMS 與 REST API 和 Gatsby 的關係，我們需要注意 WordPress API 的一些基本概念：

路由和端點：路由是您可以通過 HTTP 調用訪問的路徑，而端點是映射到該路由的 HTTP 方法（例如 get、post、put 或 delete）。
請求：當您向已註冊的 REST 路由發起 HTTP 請求時，WordPress 會自動創建一個請求對象。請求中指定的數據將決定您將得到什麼答案。
響應：響應對像是您在發出請求時收到的數據。它可以包含請求的數據或錯誤消息。
架構：架構是指端點中的數據結構。每個端點可以返回的數據結構可能略有不同或顯著不同。因此，模式將確定端點可以返回的所有可能屬性以及它可以接收的所有可能參數。
控制器類：控制器類使開發人員能夠管理和註冊端點和路由，同時還允許他們處理請求、利用模式和生成響應。

反應“框架”

當我們現在深入了解 Gatsby.js 和 WordPress 的關係時，為了獲得更多的背景信息，我們必須從更多的歷史基礎中解讀這種技術格局。 React 是這個故事的關鍵，因為它是增長最快的 JavaScript 前端庫/框架。因 Facebook（其核心開發人員）而聞名的其他大型網站使用 React 作為其前端，例如：Airbnb、Netflix、Dropbox、BBC、PayPal、Reddit、Salesforce、Squarespace 和 Tesla。

因此，由於 React 在實踐中是一個庫（因為它仍然缺乏成熟框架的顯著特徵），這意味著可以在它之上設計其他“框架”。結果，其中之一就是 Gatsby.js。

介紹蓋茨比

據其母網站介紹，Gatsby.js 是一個基於 React 的免費開源 JavaScript 框架，可幫助開發人員構建快速的網站和應用程序。原則上，Gatsby.js 從應用程序生成靜態 HTML 頁面以進行初始加載，然後作為單頁 React 應用程序 (SPA) 繼續執行。

Gatsby.js 屬性

在這種情況下，Gatsby 利用漸進式 Web 應用程序 (PWA) 原則僅獲取首先需要的元素，然後稍後在後台加載應用程序的其餘部分。此外，為了確保只加載所需的數據，Gatsby 利用 GraphQL 查詢語言（也由 Facebook）從源加載數據。它還保持出色的圖像優化。

所有這些功能的合併為開發人員提供了創建最快的網站和 Web 應用程序的必要工具，因為它只加載關鍵的 HTML、CSS、數據和 JavaScript。因此，一旦加載了頁面，Gatsby 就會為鏈接頁面預取資源，因此瀏覽網站感覺非常快。

此外，由於頁面是在編譯時生成的，在線放置之前，您不再需要強大的 PHP 服務器，並且可以提供靜態文件（HTML、JS 和 CSS，直接來自存儲桶）。此外，由於 Gatsby 由 React 提供支持，您將能夠使用組件很好地構建所有內容。這種模塊化方面允許開發人員輕鬆地重用組件。

其他重要的開箱即用 Gatsby 功能包括：

靜態站點生成器
離線訪問
預取鏈接頁面
頁面緩存
沒有多餘的代碼獲取
導出為代碼
熱重載內容
熱重載代碼
組件化
單向數據綁定
聲明式 API 數據查詢 (GraphQL)
聲明式用戶界面
漸進式圖像加載
響應式圖像加載
關鍵 CSS 的內聯
字體自託管
無服務器
資產管道
CSS 擴展 (SaSS)
高級 JavaScript 語法
React 組件生態系統

蓋茨比插件

本質上，Gatsby 插件基本上是使用 Gatsby API 的 Node.js 包。這些插件可以添加數據源、將數據轉換為其他格式並添加第三方服務。雖然 Gatsby.org 維護了一個插件庫，其中包含許多由核心 Gatsby 團隊或第三方製作的插件。理想情況下，要為 Gatsby 項目安裝插件，開發人員在其 UNIX 終端上使用節點包管理器 (NPM) 並運行命令 npm install。

GraphQL 的來歷與蓋茨比有關。

GraphQL 圍繞這樣一個想法，即您可以向 API 準確地描述您想要的數據，並且您會收到準確的數據。因此，它比 REST 更有效。為此，Gatsby 採用了 Webpack 和 GraphQL。更重要的是，使用 GraphQL 作為查詢語言，一切都在客戶端執行查詢時定義，客戶端不知道應用程序的底層工作。

這種獨特的實現使開發人員能夠將任何數據源連接到 Gatsby。例如，博客文章可以來自 Markdown 文件、Google 表格，甚至是另一個 WordPress 網站。因此，通過內容交付提供增強的靈活性。

Gatsby-WordPress 機制（源碼插件）

隨著我們進一步解開這種關係，我們需要了解源插件。源插件是在 Gatsby 的數據系統中工作的特殊插件。顧名思義，它們從不同位置（本地或遠程）獲取數據。因此，數據隨後被轉換為 Gatsby 所說的節點和節點字段。基本上，節點字段代表一個節點內的單個數據，最終，這些節點可以通過 GraphQL 查詢訪問。

在同樣的廣度上，通過源插件，Gatsby 支持數十種無頭 CMS 選項，為工程和內容團隊提供其首選管理界面的舒適度和熟悉度，以及使用 Gatsby、GraphQL 和 React 構建一個改進的開發人員體驗和性能優勢前端。

“Gatsby-source-WordPress”插件由 Gatsby 核心團隊構建和維護，並從自託管的 WordPress 站點或 WordPress.com 中提取數據。它還需要對 Word-Press.com API 進行 OAuth 身份驗證，並且還允許開發人員查詢響應式圖像。

本質上，該插件支持 WordPress REST API 上的所有實體，例如帖子、頁面、標籤、類別、媒體、類型、用戶、狀態、分類、站點元數據和自定義帖子類型。此外，除了註冊到 REST API 的其他帖子元之外，還支持高級自定義字段 (ACF) 實體和 Polylang 和 WPML 語言信息。

因此，使用此插件，開發人員可以選擇要獲取的路由，儘管它默認獲取 wpjson 的所有端點。因此，開發人員可以使用上述機制使用 GraphQL 從 WordPress 中獲取數據。

在實踐中，“Gatsby-source-WordPress”工具為所有帖子和其他實體提供了一個 slug。因此，工程師需要做的就是創建頁面調用'createPage'函數。這是在 Gatsby-node.js 文件中執行的，通常首先對數據源運行查詢，然後為每個找到的節點調用“createPage”，然後設置一個模板文件用作組件。

CI/CD 和應用程序發布自動化。

在使用 Gatsby 實現無頭 WordPress CMS 時，如何執行部署非常關鍵。通常，此類執行需要使用應用程序發布自動化 (ARA) 自動部署應用程序。

通常，ARA 需要主要功能：

數據、應用程序代碼和工件的部署。
為每個環境部署特定配置
用於自動化任務和部署步驟的流程工作流設計。
最後，環境建模和/或配置二進製文件

由於 Gatsby 生成靜態站點，因此必須設置 ARA 管道，以便在 WordPress 中更新內容時，可以在 Gatsby 站點中相應更新。通常，持續部署僅在代碼更改時觸發，但是，對於這種情況，最好在數據更改時觸發它。因此，為此，我們建議使用 Netlify 因為它具有出色的內置持續部署功能，並且易於設置。

使用 GraphQL 和 gatsby-source-WordPress 從 WordPress 查詢

例如，gatsby-source-WordPress 的工作方式是首先使用 REST 獲取端點上的所有內容。然後它將基於該數據生成一個內部 GraphQl API。隨後，它將通過您的查詢並從該內部 GraphQL API 收集數據。因此，基本上，您的構建僅以您要求的數據結束，沒有別的。

使用 Gatsby.js 開發無頭 WordPress 的優勢

由於我們已經通過 Gatsby 接觸了 Headless WordPress 開發，我們現在可以分解這種技術方法的優點。這應該基本上指導您決定是否採用 Gatsby！

第一個好處是能夠擁有一個靜態的、預呈現的站點。 這是呈現網頁的最有效方式，並且由於 Gatsby 使用 GraphQL 來執行所需的最少數據量，這為初始加載後的時間提供了一些額外的效率。
改進的 SEO 可見性：靜態頁面易於搜索引擎閱讀，因為所有內容都是預渲染和可索引的。這是一個積極的方面，與其他無頭機制相比，使用 JavaScript 呈現頁面是關於搜索引擎優化 (SEO) 的問題。
相對較快的開發速度：與其他無頭方法相比，Gatsby 具有一種統一、易於理解的數據獲取方式，無論來源如何。這使得開髮變得相當簡單，因為您可以專注於您的實際站點並讓 Gatsby 完成大部分繁重的工作。
更便宜的託管：您可以在任何地方託管 Gatsby 應用程序，因為它只提供靜態文件，從而減少託管費用。此外，由於 WordPress 僅在構建過程中被調用，而不是在用戶會話期間被調用，因此它也可以託管在負擔得起的託管解決方案上。
增強的安全性：一般來說，靜態站點生成器非常安全，因為沒有直接連接到數據庫、依賴項、用戶數據或其他敏感信息。
無插件：從非開發人員的角度來看，WordPress 非常容易操作，因為有可用的插件。但是，這限制了自定義功能的實現。不幸的是，太多的插件也會減慢網站的速度，因為它變得沉重且難以呈現。 Gatsby 執行基本上繞過了所有這些瓶頸。

使用 Gatsby.js 開發無頭 WordPress 的缺點

更新限制：當內容從頭開始更改時，它會限制您的網站可以更新的頻率。此外，如果您的站點包含大量數據，則運行 Gatsby 構建可能需要長達 10 分鐘，這對於頻繁更新的站點來說可能是一個問題。
定期更新 Hustle：此外，由於 Gatsby 是一個靜態站點生成器，它不能只是“編輯”，因為即使是很小的文本更改也需要新的部署。因此，如果您的頁面需要許多動態的每日內容更改，這可能會變得耗時且繁瑣。
延遲：您通常需要等待幾分鐘才能看到內容上線時的變化。
缺乏預覽：與傳統的 WordPress 應用程序不同，您在 Gatsby 中沒有任何類型的預覽。可悲的是，這是內容創作者在 Gatsby 中發現的最大問題。您將需要編譯所有內容，可能使用編譯網站並將所有內容放到網上的 Gitlab CI/CD 管道。
陡峭的學習曲線：一般來說，如果你想同時使用 Gatsby 和 WordPress，你需要對 PHP 和 JavaScript 語言都比較熟悉。由於 Gatsby 合併了 React 和 GraphQL，這對許多人來說可能是一個陡峭的學習曲線。

最後的想法。

總之，由於 Gatsby 的性能和業務優勢，越來越多的公司將 Gatsby 作為其技術堆棧的一部分。儘管重要的是要記住，通過將 Gatsby 與 WordPress 合併，WP 僅成為後端，這意味著您將失去它的一些功能和能力。

此外，具有 WordPress 開發經驗的開發人員會發現 Gatsby 是一款出色的工具，具有現代性能、可擴展性、安全性和開發速度優勢。所有這一切同時允許他們保留 WordPress 提供的熟悉的內容創建用戶界面。

但是，在啟動這項技術之前，應該始終考慮他們的項目規範和目標。例如，如果重點是可擴展性、性能、開發速度、長生命週期，Gatsby 就可以。但是，如果重點是為非程序員內容創建者提供更高的靈活性和工具，並以秒或分鐘為基礎更新內容，那麼您可以考慮另一種方法。