DE{CODE}：古騰堡和無頭 WordPress

Gutenberg，又名 WordPress 塊，為內容製作者提供了在傳統 WordPress 網站中佈置內容的強大新方法。 但是無頭 WordPress 開發人員如何為營銷團隊賦予這些相同的能力呢？ 在此 DE{CODE} 會議中，GraphQL for WordPress (WPGraphQL) 的創始人 Jason Bahl 分享了在無頭站點上使用 WordPress 塊編輯器的新功能和最佳實踐。

會議幻燈片

全文抄本

傑森·巴爾：嗨。 歡迎來到我關於 Gutenberg 和 Headless WordPress 的演講。 我叫傑森·巴爾。 我是 WPGraphQL 的創建者和維護者。 我是 WP Engine 的首席軟件工程師。 您可以在 Twitter @jasonbahl 或 Twitter @wpgraphql 上找到我。

所以今天，我想和你談談古騰堡甚至是什麼，無頭 WordPress 是什麼，什麼時候以及為什麼你可能想要使用無頭 WordPress，如何使用古騰堡，特別是無頭 WordPress，以及無頭 WordPress 和古騰堡的時間和原因在一起可能對您的項目有意義。

所以 WordPress 歷史上有一個看起來有點像這樣的編輯器。 我們有一個 TinyMCE 文本區域，我們可以在其中編輯我們的內容。 我們可以插入媒體然後發布我們的內容，然後在 2018 年出現了基於塊的編輯器 Gutenberg，它允許我們將內容插入到這個空白畫布中並在塊級別與我們的內容進行交互。

所以每個段落都有設置。 每個圖像都有設置。 每個畫廊、標題——任何你能想到的內容都是所謂的塊。 我們現在可以真正細化我們如何控制我們的內容，我們可以拖放它並編寫我們的內容。 所以它現在是 WordPress 中非常豐富的編輯體驗，所以它是古騰堡是什麼的初級讀物。

那麼現在什麼是 Headless WordPress？ 所以要了解 Headless，讓我們看看傳統的 WordPress。 所以傳統的 WordPress，我們登錄到 WordPress，管理 UI，我們發布我們的內容，然後用戶訪問我們的網站，PHP，WordPress 內置的語言，呈現頁面。 因此它加載 CSS、HTML 和 JavaScript 並將頁面交付給用戶。 所以這是一種傳統的 WordPress。

使用 Headless WordPress，您仍然使用 WordPress 作為 CMS。 您仍然在 WordPress 中發佈內容、策劃內容、管理內容，但不是向瀏覽器提供 HTML 頁面，WordPress 通常以 JSON 格式提供數據，然後客戶端應用程序可以使用該數據，因此我們可以擁有原生 iOS 或 Android 應用程序甚至虛擬現實應用程序。

我的同事 Anthony 分享了有關他如何使用 WordPress 為虛擬現實應用程序提供支持的內容。 或者我在一家報紙工作，我們使用 WordPress 作為我們印刷報紙的入口點。 因此，如果您正在閱讀紙質報紙，那麼您正在閱讀 WordPress 製作的內容。

當然，我們仍然可以使用這些數據來呈現到網絡，但我們不必局限於 PHP 模板，我們可以靈活地選擇我們想要的任何前端技術。 因此，Headless 分離了後端、內容管理以及我​​們如何呈現在 WordPress 中管理的數據。

因此，我們可以通過兩種常見方式使用這些數據。 我們可以從 WP REST API 獲取 JSON 格式的數據，WP REST API 是 WordPress 的內置 API，還有另一個 API 稱為 WPGraphQL。 這是一個開源插件，您可以安裝它並從 WordPress 和 JSON 中獲取數據。 我們今天將討論 WPGraphQL。

那麼既然我們知道 WordPress 是什麼，您為什麼要構建 Headless WordPress 項目呢？ 就像我提到的，您在選擇前端技術方面有很大的靈活性。 對於某些人來說，能夠選擇如何構建前端項目是一件非常重要的事情。 有一些框架，如 Next、Gatsby 和 Svelte，真正針對改進的核心 Web 活力。 因此，您可以使用 WordPress 進行 Headless，並改進核心網絡生命力。

您可以從代碼中的代碼拆分等方面受益。 因此，您可以為前端應用程序構建組件。 並且基於為特定頁面構建的組件將向客戶端發送更少或更少的資產並加速您的頁面。 Headless 還使開發人員可以更好地控制前端用戶體驗，因此安裝在 WordPress 管理中的插件對前端的影響較小

因此，管理員用戶不能只安裝插件並將任意腳本或任意標記添加到 Headless 站點的前端。 更多的是開發人員在前端定義約束，WordPress 獲取發送過來的數據，然後我想強調的一件事是開發人員體驗。

使用 Headless WordPress，由於您可以靈活地使用任何您想要的技術堆棧，因此在某些情況下會有更好的開發人員體驗的好處。 我將要涉及的其中一個案例稱為基於組件的開發，我們稍後會詳細討論它。

這就是為什麼的一些原因。 那麼當你想要使用 Headless WordPress 時，你可能處於什麼情況？ 好吧，如果您需要構建非 Web 應用程序，例如原生移動應用程序，您可能想要使用 Headless。 同樣，如果您的 WordPress 網站、您當前的 WordPress 網站上的核心網絡活力很差，或者它們還可以，但保持它們良好的成本變得非常高，您可能需要考慮 Headless。

如果您的組織中有多個應用程序需要從 WordPress 獲取數據，您可能也需要使用 Headless。 如果您已經為您的組織投資了一個組件庫或基於組件的設計系統，並且您需要來自 WordPress 的數據，您可能想要投資於 Headless。 如果一個團隊更喜歡 JavaScript 而不喜歡用 PHP 構建東西，那也是考慮 Headless 的一個原因。

不過，您可能不想使用 Headless 的某些原因——目前，它確實需要一點額外的開發時間。 因此，如果您的預算較低或縮減時間，並且您已經在傳統 WordPress 中擁有解決方案，那麼您可能還沒有採用 Headless。 如果您的站點管理員確實需要控制安裝修改前端的插件，您可能還沒有使用 Headless。

如果您的團隊真的更喜歡 PHP 而不想學習 JavaScript 或其他前端，您也可以堅持使用傳統的 WordPress。 如果您沒有投資於基於組件的開發或基於組件的庫，如果您對此不感興趣，您可能會堅持使用傳統的 WordPress 開發工作流程。

如果您在傳統 WordPress 上的核心 Web Vitals 非常好，並且您的維護成本非常低以保持您的網站運行非常快，那麼您可能會堅持使用傳統 WordPress。 所以你不必去無頭。 但我將向您展示為什麼我認為採用 Headless 對某些團隊有好處。

因此，如果我們再次審視 WordPress 開發人員的體驗，我們會在一個生成大量 HTML 的字段中發布我們的內容。 即使我們使用具有這些細粒度塊的古騰堡編輯器，最終結果也是一大塊 HTML。 因此，無論我們是在古騰堡還是傳統的經典編輯器中發布，這一塊 HTML 都會通過 PHP 發送到我們的主題，我們有一個全局頁面可以加載我們的 HTML、CSS 和 JavaScript。 這些資產在全球範圍內應用於頁面。

所以 WordPress 開發人員通常會根據文件類型來解耦我們的開發，所以我們會將我們的 CSS 放在單獨的文件中，這些文件全局應用於頁面，或者 HTML 將用 PHP 編寫，並從 WordPress 中提取我們需要的數據，然後 JavaScript 將經常用 jQuery 寫在單獨的文件中。 因此，這三件事將一起構建頁面。

問題是這些不是孤立的，它們應用於整個頁面。 所以有時候你可以做出改變。 就像這件事發生在我身上。 有一次我應我的經理的要求更改了網站頁腳的樣式，三天后，據報導該網站其他地方的樣式由於通過代碼審查而發生了變化。 我們通過了。

突然間，網站上的其他東西壞了，這是因為 CSS 是全球應用的，可能會影響你沒有意識到的事情。 不過，過去有一種新趨勢——我不知道——七八年可能被稱為基於組件的架構。 這使我們能夠在所謂的組件中構建應用程序的特定部分。

我們可以將我們的 JavaScript、我們的 HTML、我們的 CSS 組合成小塊，我們可以單獨測試它們，這樣我們就可以構建我們的應用程序的各個部分。 關注點、標記、JavaScript、樣式，我們可以將這些組件組合在一起以構建更複雜的應用程序。

因此，基於組件的開發允許我們將復雜的功能分解成更小的獨立部分，我們可以單獨測試它們，確保它們正常工作，然後我們可以耦合我們應該耦合的關注點。 UI 的每一部分都有特定的責任。 如果它是圖像卡片，它可能會負責以特定大小呈現具有特定 URL 的圖像。

所以它具有標記依賴性。 它具有樣式依賴性。 它可能有狀態交互。 這些都與該特定組件有關。 所以我們可以將我們的標記、我們的 JavaScript 和我們的 CSS 結合在一個地方，測試它，並確保它運行良好。 因此，我們可以在整個應用程序中重用這些組件，甚至可以跨項目重用我們的組件。

所以出現了一種叫做組件庫的趨勢。 有像 Material UI 或最終設計組件這樣的項目，或者 Chakra UI 也是一個流行的項目。 我們可以跨項目使用這些組件。 我們可以解決諸如可訪問標記之類的核心問題。 我們可以對這些進行更新，並立即將它們應用到我們組織的多個項目中，正因為如此，我們可以更有信心地更快地迭代和交付。

那麼我們如何使用 Headless WordPress 呢？ 就像我之前提到的，有兩種方法可以將數據從 WordPress 中獲取到組件中。 一個是 REST API。 一個是 WPGraphQL。 我的朋友 Drake 已經建立 Headless 網站有一段時間了，所以我問了他，他是這麼說的……

他更喜歡 WPGraphQL。 這就是我們今天要討論的內容。 那麼什麼是 WPGraphQL？ 你可能會問。 好吧，它是一個免費的開源 WordPress 插件，可為任何 WordPress 站點提供可擴展的 GraphQL 模式和 API。 那麼 GraphQL 是什麼？ 好吧，這是一種圖形查詢語言。

好吧，傑森。 我還是不明白你在說什麼。 好吧，讓我給你看。 所以 GraphQL，它的工作方式是客戶端應用程序發送一個請求，指定他們想要從服務器獲得什麼。 請求看起來像這樣。 它看起來像沒有值的 JSON 鍵。 所以在這種情況下，請求是在詢問查看器，而在查看器上，我們希望返回“名稱”字段。

來自 GraphQL 服務器的響應可能如下所示。 它的實際 JSON 數據、鍵和值以及它與請求的形狀相匹配。 所以在這種情況下，我們得到了名字，或者我們得到了名字為 Jason Bahl 的觀眾。 所以 GraphQL 讓我們的客戶端應用程序從應用程序數據圖中採摘樹。

視覺上看起來像這樣。 我們可以輸入圖形，比方說，添加查看器或用戶字段或節點。 那個節點可能有一個屬性，比如名字 Jason。 並且該節點可能與圖形中的其他節點有連接，例如頭像，它可能具有圖像 URL 等屬性。

並且該用戶可能與其他節點有連接，例如該用戶創作的帖子。 這些帖子本身可能具有標題、你好世界或再見火星等屬性。 這些帖子可能與圖中的其他節點有聯繫，例如具有自己標題的類別，如新聞或體育。 這些類別可能與其他節點有聯繫以及更多帖子。 這些帖子可能有特色圖片等等。 所以我們有了這個大數據圖，我們可以使用 GraphQL 請求其中的片段。

因此我們可以在 GraphQL 管理員或 WordPress 管理員中使用工具。 有一個名為 GraphiQL 的工具，我可以在其中編寫查詢。 在這裡，我選擇了帶有子選擇、名稱、頭像、URL 的查看器字段，當我們執行它時，我們得到了我們要求的字段，因此在視覺上查詢看起來有點像這樣。

我們輸入了圖表並詢問了一個用戶。 我們詢問了用戶名，頭像 URL 中連接的頭像。 我們擁有所有可用的數據圖表，但我們只要求一組特定的數據，作為回應，我們得到了特定的挫折。 然後我們就可以採取——我們現在可以使用組件了。

所以我談到了基於組件的開發的好處，我想向您展示這一點。 所以這就是我所說的展示組件。 所以這是一個負責的卡片組件。 它有責任渲染這張帶有圖像和標題的卡片。

我們可以查看代碼，發現我們有一些樣式控制。 我們可以設置寬度，我們可以將我們想要的圖像傳遞給它，我們可以將標題傳遞給它。 所以我們可以在整個項目中重用這個組件。 並且該組件具有我們需要的所有依賴項。 它具有要呈現的 HTML。 它有風格。 我們在這裡有一些樣式控制。 它有一些有狀態的組件，比如懸停狀態等等。

所以這是一個我們可以重用的獨立組件，現在使用 GraphQL，我們可以使用 GraphQL 獲取我們剛剛在 WordPress 管理中編寫的查詢，我們可以將其引入並現在擁有一個查看器卡組件。 所以我們可以編寫我們的查詢，將它與我們的卡片組件結合起來，現在它完成了該組件。

我們有我們的 HTML、CSS 我們的 JavaScript。 由於有了數據，我們現在可以用我們要求的數據來呈現一些東西。 所以現在我們可以在整個應用程序中使用它，並且有一個稱為片段的 GraphQL 特性，這允許我們獲取 GraphQL 查詢並將其分解為可重用的片段。

因此，在這種情況下，我正在創建一個用戶個人資料卡片片段，我正在指定名稱、頭像和 URL，然後我在更大的查詢中使用該片段。 當我們執行時，我們會得到我們期望的結果。 我們現在可以獲取該片段，將其放入組件中。 現在我們有一個不同的組件，稱為用戶配置文件卡。

此用戶個人資料卡指定任何時候我們查詢用戶時，我們都應該獲取名稱、頭像和頭像的 URL 以在組件中使用。 所以現在我們有了這個可重用的組件，我們可以在應用程序的任何地方請求用戶，我們可以獲得必要的數據來渲染這個可重用的卡片，其中包含頭像和用戶名。

因此，現在可以將其引入並用於我們應用程序的更大部分。 這是我們在查看器查詢之前使用我們從可重複使用的用戶資料卡組件導入的片段進行的查詢。 然後我們將它輸出到查看器卡組件，現在我們可以在我們的應用程序中重用它。

我們可以製作依賴於此用戶卡或作者卡的應用程序的更大部分。 所以我們現在可以有多個組件，比如負責標題的博客標題組件。 我們可以有一個我們剛剛創建的用戶個人資料卡來呈現用戶的個人資料。 我們可以有一個內容或摘錄組件來負責我們應用程序這部分的標記和數據。

是的，我們可以構建這些負責標記、CSS 和構建此應用程序所需的數據的小組件。 我們可以將它們組合在一起。 我們可以單獨測試它們，也可以將它們作為更大的單元進行測試。 所以我們也可以在各種模板中使用它。

我們可以將這些可重用組件用於博客文章或我們擁有不同作者的博客角色，但我們可以使用相同的組件來呈現它們。 我們可以將它用於其他存檔頁面。 與 WordPress 模板部分非常相似，我們可以將 Headless 應用程序分解成小塊，但我們可以獲得將我們的技術耦合在一起的好處。

所以這就是 Headless WordPress 開發人員體驗基於組件的設計及其好處的一點點。 那麼現在談到古騰堡時，為什麼要特別考慮使用古騰堡的 Headless WordPress？ 好吧，如果您的團隊已經在使用 Headless WordPress，可能使用高級自定義字段和彈性域，並且您想要更新編輯器體驗以使用 Gutenberg，這顯然是您可能會使用 Gutenberg 的 Headless 的原因之一。

如果您想從構建在管理中使用的組件和在前端使用的組件中受益，那麼考慮使用 Gutenberg 進行 Headless 是一個很好的理由，因為塊編輯器的 Gutenberg 後端編輯器都是基於組件的。 您可能想利用結構化輸入。 管理員中的每個塊都有結構化的字段。

您具有可以在字段級別控制的特定屬性。 您可能也想從將結構化輸出傳送到您的組件中獲益。 就像我提到的，您可能希望跨項目重用組件和塊。 例如，您可能希望擁有您的機構構建的塊庫，以解決您希望跨項目使用的可訪問性和特定標記問題等問題。 然後你可以在你的項目中更新這些，而不僅僅是在一個單獨的項目中。

因此，這是 WordPress 中的子主題難以擴展的部分，因為您必須訪問每個站點並更新每個站點上的標記和諸如此類的東西。 那麼，在這裡，您可以使用塊庫作為 NPM 依賴項並在整個組織中更新它們。

所以目前，使用 Gutenberg 進行 WordPress 開發的狀態是我們在後端有塊，這些塊是基於組件的。 我們可以構建自己的自定義塊或使用核心 WordPress 塊。 但是 PHP 的輸出，就像我提到的那樣，是一大塊 HTML，那麼我們如何才能從獲取這一塊 HTML 過渡到在後端擁有組件，這些組件也會傳輸到我們前端的組件？

因此，我們將研究一些將 Gutenberg 數據從 WordPress 提取到組件中的選項。 因此，一種選擇是將內容作為 HTML 獲取。 所以我們可以將我們的 WordPress 內容查詢為 HTML，然後將該 HTML 解析為組件。 或者我們可以將塊查詢為 GraphQL 類型。 所以我們可以——這允許我們查詢塊列表，每個塊都是我們可以映射到組件的 GraphQL 類型。

所以內容是HTML。 這是我們今天可以在 WPGraphQL 核心中做的事情。 如果你想查詢塊作為單獨的 GraphQL 類型，目前有兩個選項。 我們有用於 Gutenberg 擴展的 GraphQL，這是社區擴展，然後我們有 WPGraphQL Block Editor，這是我個人正在開發的 beta 插件。

因此，讓我們看看這些選項。 在 WPGraphQL 核心中，我們可以將內容查詢為 HTML 並解析為組件。 這看起來像是我們查詢類似帖子的內容，我們可以請求 ID 和標題或內容等字段。 內容將返回一個大字符串，一大塊 HTML，然後我們可以解析該 HTML 並將不同的 DOM 節點映射到不同的組件。

就像 wpgraphql.com 上的這種情況一樣，左側的鏈接指向實際發生這種情況的代碼。 我獲取從 WPGraphQL 返回的標記，然後解析它，查找特定的 HTML 節點並將其轉換為 React 組件。 所以我可以有像這個代碼塊這樣的交互式東西，它會突出顯示語法並允許用戶單擊複製，然後我還可以解析和創建目錄，例如。 所以這是一種方法。 我今天在 wpgraphql.com 的生產環境中使用它。

如果你走這條路，你可能需要考慮一些事情，HTML 有效負載可能是不可預測的。 服務器中的更改，例如安裝新的塊庫或編輯器可以放入內容中的各種 HTML，它們是不可預測的。 所以它可能很難解析。 您無法檢查更改。 作為客戶端開發人員，您看不到發生了什麼變化，所以只需要考慮一些事情。

我會說這種方法最適合對 WordPress 管理員和前端有非常嚴格控制的團隊。 因此，如果您是一個人或一個在 WordPress 後端和前端工作的小團隊，它可能適合您，因為您可以更好地控制輸入和輸出。

其他選項之一，WPGraphQL for Gutenberg，這是一個社區維護的插件。 這將允許您查詢內容塊，每個塊都有自己的 GraphQL 類型。 它的工作方式是一個設置頁面，你必須進入作為模式的塊，所以這會在一個不可見的 iframe 中打開 Gutenberg，從 JavaScript 客戶端獲取塊註冊表並將其發送到服務器。

然後我們可以使用 GraphQL 來查詢我們的塊作為特定類型，我們可以使用我之前展示的片段，我們可以使用這些片段映射到我們前端的組件。 所以這是一種選擇。 這個插件的一些注意事項，對塊註冊表的更改是可自省的，所以這是一件好事。

在前端應用程序上工作的團隊可以使用 GraphQL 內省來查看架構如何隨時間變化，並且他們可以知道是否存在重大更改或他們可以使用的新字段。 我會說這種方法對於多人或多團隊項目效果更好一些。 如果您有一個團隊負責 WordPress 管理員工作，而另一個團隊負責前端工作，那麼這種方法可能會更好。 他們可以使用 GraphQL 模式作為雙方使用的塊之間的契約。

一件有點有趣的事情是它像我提到的那樣在 iframe 中加載塊。 正因為如此，它並不總是適用於所有情況。 因此，如果您將塊註冊到特定頁面或特定模板或特定帖子類型，這種將塊註冊表映射到模式的方法可能會錯過某些塊。 所以它可能無法擴展到每個項目。

所以下一個項目，WPGraphQL Block Editor，這是我目前正在開發的測試版插件。 這也允許您將內容塊查詢為它們自己的 GraphQL 類型，因此與 Gutenberg 的 WPGraphQL 非常相似，我們可以編寫返回我們指定數據的片段。 然後我們可以在前端將這些片段與我們的組件一起使用。

對此的一些考慮，它是一個測試版插件，就是這樣。 您確實受益於結構化輸入和結構化輸出。 因此，作為前端開發人員，這無疑是一場胜利。 它確實適用於在 block.json 文件中註冊的塊。 所以核心 WordPress Gutenberg 塊確實有這個文件，所以這將適用於該方法。 許多第三方不會以這種方式註冊他們的塊，因此您必須手動映射這些塊。

塊不被視為單獨的節點。 我想將塊視為單獨的節點，但沒有全局 ID，因此您必須將這些塊作為更大對象（如海報頁）的一部分進行訪問。

因此，我希望您了解了一些有關 Headless WordPress、Headless WordPress 的好處以及將 Headless WordPress 與 Gutenberg 結合使用的知識。 今天我邀請您試用 WPGraphQL。 您可以在 wpengine.com/atlas 註冊一個免費的 Atlas Sandbox 帳戶。 感謝您參加我的演講。 同樣，您可以在 Twitter、jasonbahl 或 Twitter @wpgraphql 上找到我。 謝謝。