DE{CODE}：適用於 WordPress 開發人員的 Headless 101

無頭開發可以比傳統的 WordPress 開發更強大，甚至更有趣。 然而，在這個新興堆棧中有如此多的新選擇，最好的入門方法是什麼？ 本次研討會將引導構建者安裝和優化無頭 WordPress 項目，一直到在分離的前端中模板化您的第一頁。

會議幻燈片

全文抄本

GRACE ERIXON ：歡迎來到 WordPress 開發人員的 Headless 101。 我的名字是 Grace Erixon，我是 WP Engine 的副開發倡導者。 加入我的是來自豪斯的史蒂夫。 今天，我們將向您快速介紹什麼是無頭 WordPress，以及如何開始使用它。

因此，為了了解什麼是無頭 WordPress 網站架構，重要的是要確保我們都在同一頁面上了解傳統 WordPress 架構的外觀。 傳統上，像 WordPress 這樣的 CMS 會同時處理網站的前端和後端。

在傳統架構中，發布者在 WordPress 中創建和管理博客文章和頁面等內容。 開發人員使用 PHP 和 WordPress 的主題 API 編寫代碼來控製網站的外觀和功能。 然後 WordPress 生成發送給訪問者的 HTML 頁面。

在這種耦合的 CMS 架構中，WordPress 為發布者提供了內容管理功能。 它還負責為網站訪問者提供 HTML 頁面。 無頭 CMS 使用分離架構，前端和後端分開管理。 在無頭架構中，發布者仍然在 WordPress 中創建和管理內容，這與在傳統 WordPress 架構中相同。

開發人員編寫代碼來控製網站在 JavaScript 中的外觀和功能，以及使用 WPGraphQL 或 REST API 從 WordPress 中提取數據。 Faust.js、Next.js、Nuxt.js 或 SvelteKit 等框架通常用於為該前端應用程序提供支持。 然後前端 JavaScript 應用程序生成並提供發送給網站訪問者的 HTML 頁面。

與傳統架構不同，WordPress 不再負責生成 HTML 頁面。 因此，WordPress 後端和前端 JavaScript 應用程序之間交換內容的交互是通過 API 層發生的。 API 層的兩個選項是 WordPress REST API 或 WPGraphQL。

REST API 與 WordPress 捆綁在一起。 但是，它所需的數據訪問模式可能會很慢，因為 REST 要求每個資源都有自己的端點。 例如，需要多次往返才能重建完全建模的帖子。 如果您想獲取帖子的內容、作者和類別，則需要三個單獨的 API 調用。

相比之下，WPGraphQL 允許我們在一次請求中詢問帖子的內容、作者和類別。 因此，WPGraphQL 是我們首選的 API 層。 WPGraphQL 是一個免費插件，可為您的 WordPress 站點提供可擴展的 GraphQL 架構和 API。 WPGraphQL 比 REST API 更快，因為它獲得了所要求的確切數據，並且通過查詢優化減少了執行的功能，減少了數據下載，提高了數據加載效率，並且在單個請求中包含了多個資源。

無頭架構讓開發人員可以自由選擇任何前端技術堆棧，其中 JavaScript 框架最為流行。 一些最流行的前端 JavaScript 框架包括 React、Vue.js 和 Svelte。 新框架一直在發布，所以這個列表遠非全面。

其中許多 JavaScript 框架與元框架結合使用，為路由、服務器端渲染等添加解決方案。 React與Next.js結合使用，Vue.js與Nuxt.js結合使用，Svelte與SvelteKit結合使用。 Gatsby 是另一個流行的元框架。

WP Engine 開發了 Faust.js，這是一個構建在 React 和 Next.js 之上的 JavaScript 框架。 Faust 是專門為支持無頭 WordPress Web 應用程序而創建的。 它支持開箱即用的身份驗證和發布預覽，提供方便的內置 React 掛鉤以訪問 WordPress 數據等。

所以我們已經討論了無頭 WordPress 架構的含義以及您將使用的技術種類。 但是讓我們快速談談為什麼你甚至會選擇無頭。 WordPress 本身是一個重量級的 CMS，它使用的是 PHP，這不是一種快速的語言。 Headless WordPress 通過 JavaScript 使用 foster 語言，並通過 API 調用僅加載必要的文件。 它更輕巧，因此您的網站加載速度會更快。

Headless WordPress 還可以最大限度地降低您的內容的風險，因為您的數據與前端交付是分開的。 它較少受到網絡攻擊。 主要好處是 headless WordPress 架構允許發布者繼續受益於 WordPress 提供的出色發布體驗，同時還允許開發人員和網站訪問者利用現代 JavaScript 應用程序帶來的技術功能。

現在，讓我們深入研究一個真正的無頭站點的代碼。 我預先錄製了新的 Atlas Blueprints 無頭 WordPress 網站的演練。 Atlas 中的新藍圖功能提供了一種非常簡單的方法來啟動和運行完整的無頭 WordPress 站點。 它們帶有起始代碼、插件、內容模型和頁面結構，可以讓您的應用程序更快地啟動。

因此，讓我們創建一個新的藍圖站點，以便我們可以深入研究代碼。 從 WP Engine 的儀表板內部，我們將轉到 Atlas。 單擊創建應用程序。 選擇從藍圖開始。 然後我們將選擇我們想要使用的藍圖。 我要選擇投資組合藍圖。

然後將您的 WP Engine 帳戶連接到您的 GitHub 帳戶，並將該藍圖克隆到一個新的存儲庫中。 這將需要幾秒鐘的時間來構建。 最後，您只需選擇剛剛創建的存儲庫的名稱、離您最近的區域，然後單擊“創建應用程序”。

現在，如果您單擊 Atlas URL，我們可以查看我們的 headless WordPress 網站的外觀。 我們對 Posts 頁面特別感興趣。 如您所見，該站點正在將所有最新帖子拉入此“我們的博客”頁面。 每個帖子也有自己的個人視圖頁面。 但是所有這些數據來自哪裡？

如果我們回到 WP Engine 儀表板，我們會看到一個 WP Admin 按鈕。 這是我們的無頭 WordPress 網站的後端。 如果我單擊“帖子”，您將看到與 Web 應用程序拉入的列表相同的列表。現在，我們可以打開我們的藍圖被克隆到的 GitHub 存儲庫。 讓我們將該 repo 克隆到我們的​​本地環境中。

然後，我將在我最喜歡的代碼編輯器 Visual Studio Code 中打開此存儲庫。 深入到項目目錄，可以在 SRC、pages、posts、Index.js 找到博客頁面的文件。 該項目是使用 React、Next.js、Faust.js 和 WPGraphQL 構建的。 如果您不熟悉 React 甚至 JavaScript，那麼乍一看可能會感到困惑。

在第一部分中，文件只是從內部和外部源導入它需要的東西。 定義後節點預傳遞字段的第二部分是列出我們需要的每條數據的地方。 通過 prepass 運行它可以確保數據在我們需要的時候就在那裡，並且不會發生級聯請求。

然後我們有頁面功能。 起初，它只是將我們需要的數據收集到幾個不同的變量中，即常規設置和分頁的帖子列表。 返回語句中的標記是將在網頁上可視化呈現的代碼。 首先，我們有標題組件。 然後，在這個主要組件內部，我們有一個條目標題組件，這就是在頁面頂部顯示“最新帖子”的大標題。

最後，我們到達 post 組件，它接受分頁的帖子列表作為參數。 讓我們看看 post 組件如何處理這些信息。 在這裡它循環遍歷它收到的帖子列表中包含的每個帖子。 對於每個帖子，它會在最新帖子的頁面上顯示類似卡片的視圖。 這首先包含一個包含在單個博客文章頁面鏈接中的特色圖像組件、帖子標題的標題以及由帖子的日期和作者組成的帖子信息組件。

回到顯示所有帖子的 Index.js 文件，我們通過在頁面底部顯示加載更多組件來完成此操作，以在請求時檢索更多帖子和頁腳。 最後一個函數 getStaticProps 是一個 Next.js 靜態站點生成函數，它告訴它在構建時使用該函數返回的道具預渲染此頁面。 就是這樣。

感謝 Blueprints 為我們處理 Headless 設置。 使用 WPGraphQL 分解進入帖子頁面的內容以從 WordPress 後端獲取數據並使用 React 組件顯示帖子是很簡單的。 感謝收看。您可以在 Twitter @graceerixon 上找到我。

查看 developers.wpengine.com 了解有關 Headless WordPress 的更多內容。 我們有一個教程，介紹如何使用 Faust.js 從頭開始構建您的第一個 Headless WordPress 網站，我們現在正在處理 Headless 101 系列內容。 如果您註冊一個免費的 Sandbox 帳戶，您可以獲得 Atlas 提供的所有工具。 現在，我將把它傳遞給史蒂夫，讓他更多地談談為什麼 Haus 選擇 Headless WordPress 作為他們的 leoburnett.com 項目。

史蒂夫·斯卡沃： 謝謝，格蕾絲。 大家好，我是 Haus 的首席技術官 Steve Scavo。 我們是一家位於加利福尼亞州洛杉磯的創意技術工作室和代理機構。 本次演講的標題恰如其分地命名為 WordPress 開發人員的無頭 101。 坦白說，我不是 WordPress 開發人員，但我認為這是無頭架構之美的一部分。

因此，對於需要利用 WordPress 的非 WordPress 開發人員，我們可以輕鬆地將其稱為 Headless 101。 這可能是一個恰當的標題。 這就是無頭的美妙之處。 正如您將看到的那樣，這是各方的雙贏。

那為什麼是無頭的呢？ 我們可以談論很多高層次的原因，但我認為談論真實的生產例子和現實世界的例子真的很有幫助。 我想展示一個我們為 Leo Burnett 在無頭架構下使用無頭的項目。 就上下文而言，李奧貝納 (Leo Burnett) 是一家位於芝加哥的傳奇廣告公司，但他們在全球和全球設有許多辦事處。 所以他們有很多內容，很多工作。

舊站點在單個 WordPress 主題上運行。 它真的很零散，有點慢，表現不佳。 它很難更新，也沒有完全展現李奧貝納想要傳達的那種聲望和品牌。 這就是我們從設計角度出發的工作。 我們選擇了 headless 來真正實現他們的堆棧現代化。

我們只是希望它給人以活力和新鮮感，並具有我們需要的那種能力，才能真正將美妙的用戶體驗和 UI 組合在一起。 我們想提高他們的出版能力。 我們希望提高他們發佈內容的節奏。 我們想重新建立品牌標識並擁有用戶界面和交互，網站的感覺真的有點像李奧貝納，以及他們想要傳達的所有這些小細節和編輯、排版和交互點。

我們想為將來準備代碼庫和網站。 我們不只是希望該站點在接下來的 12 個月內具有相關性。 也許，我們希望它與下一個十年相關。 而且我認為這種無頭架構，這種無頭堆棧確實可以做到這一點。

所以 headless 的最初問題之一是總是有很多關於託管、部署和基礎設施的決定，這一直是一個巨大的痛點。 所以這些堆棧決定一直留給開發人員。 你四處尋找，思考，好吧，你需要使用什麼第三方，也許是 CI/CD 應用程序？ 我們要在 AWS 上託管它嗎？ 我們該怎麼做？ 什麼服務？ 然後你可以圍繞該流程實施這些潛在的臨時解決方案。

嗯，Atlas 和 WordPress Engine Atlas 平台確實解決了這個問題。 這就是它發揮作用的地方。 出於所有這些原因，我們選擇了 Atlas，他們擁有這種託管服務基礎設施。 他們標準化了 CI/CD 管道。 你真的不必考慮它。

環境之間存在數據遷移，本質上是一鍵式流程。 從歷史上看，這一直是從 QA 到暫存到生產的一個大問題。 本質上，WordPress 引擎和 Atlas 平台已將其簡化為一次單擊。

然後就是圍繞微服務和 DevOps 的這種疲勞。 作為開發人員，您必須考慮和支持並意識到這一點並保持其正常運行，這只是一個沉重的認知負擔。 這些都是 Atlas 平台真正從你手中拿走並以有益的方式解決的事情。

那麼讓我們談談我認為無頭真正促進和強調的一些動態。 這裡的第一根柱子——共有三根。 第一個支柱是開發者體驗。 它使我們能夠為工作選擇合適的工具。 當我說我們時，我指的是開發人員。

它允許我們選擇我們想要編寫代碼的堆棧。對我們來說，那是在 Haus，那是 Next.js 和 React。 Next.js 只是一個很棒的框架，它圍繞著路由、性能和應用程序架構的一些非常好的約定。 我們還想實現一個設計系統，不僅僅是一個視覺設計系統，而是一個代碼化的設計系統。 這是使我們的應用程序保持一致、經過測試和美觀的東西。

交互是一致的。 它允許我們在未來的生態系統中構建新的頁面和功能，並保持並保持這種一致性。 它還允許我們編寫聲明式表達代碼，並且 React 認可它作為一個庫。 但我們也相信這種寫作風格作為一個團隊。 它允許我們在前端為我們選擇那個堆棧，而也許是一個傳統的基於主題的 WordPress 網站，我們並沒有真正擁有同樣的奢侈。

我們還需要大量的創意空間。 當您訪問 leoburnett.com 時，您會看到漂亮的頁面轉換。 有——我們不受限於傳統的 WordPress 堆棧如何呈現事物。 WordPress 不再負責呈現前端。

我們的淨空幾乎是無限的。 我們可以選擇我們的動畫庫。 我們可以選擇我們的組件相互交互的方式。 這在 DX 方面是一個巨大的好處。

管理員體驗得到了提升，我認為我們已經優化了它，因為我們從未擺脫他們過去的熟悉。 沒有後端切換。 我們從 WordPress 轉到 WordPress。 我們不必導出數據和編寫腳本來轉移到另一個專有系統。 所以熟悉度很高。 我們希望為 leoburnett.com 的當前管理員保持這種流程。

採用和文檔——如果您在網絡上花費五分鐘，您可能已經接觸過 WordPress 後端，這簡直不能被誇大。 李奧貝納還有很多非常具體的內容點和自定義字段。 WordPress 提供並賦予您這種能力，但我們能夠實施 Advanced Custom Fields 插件，這是一個關於調整管理 UI 以使其真正友好和可用的非常好的約定。 所以這是管理體驗的勝利。

現在，第三個支柱當然是用戶體驗。 這才是真正重要的。 用戶，我認為就像我們認為 Haus 的 Web 應用程序應該感覺像本機應用程序一樣，不應該有下降。 我認為用戶也很欣賞這一點。

它們是無縫的。 他們反應靈敏。 他們只是感覺良好。 而且我認為我們希望 Leo Burnett 和我們所有的應用程序都有這種感覺。 能夠在前端選擇我們想要的堆棧使我們能夠做到這一點。

本機應用程序本質上與其後端內容基礎架構分離，我們的網絡應用程序也是如此。 這就是阿特拉斯所提倡的。 這就是無頭架構通常所提倡的。 它還可以促進性能。 我們可以普遍呈現我們的 UI。 這意味著初始負載在服務器端。 之後，客戶接管。

這裡有很多好處。 一是它讓搜索引擎高興。 它們是服務器端內容。 它很快。 它還允許我們幾乎即時地預渲染下一頁，並根據視口中的內容一次性發出這些請求。

對於 Leo Burnett，就我們選擇使用的內容 API 而言，我們設置了一個 GraphQL 端點。 這意味著有更精簡的有效載荷返回。 我們明確定義了我們需要的內容。 在服務器端渲染到客戶端渲染之後水合作用較少。

通過線路傳輸的代碼更少、響應更少、響應時間更快。 這絕對是一場胜利，我建議，如果您打算進入 Atlas 工作流或無頭工作流，那麼您應該認真考慮使用 GraphQL API 與 REST API 之類的東西。

從用戶的角度來看，他們看到的是新鮮、及時的內容。 這是為預覽內容而優化的發布流程。 它針對暫存和預覽方面的快速內容獲取進行了優化，然後將其推廣到生產中。 李奧貝納 (Leo Burnett) 的管理員對更新內容的輕鬆程度感到非常滿意，這讓用戶很高興。

結果如何？ 這只是把它全部捲起來。 它啟發了開發人員、高效的管理員和快樂的用戶。 這是三合會，也是我認為所有 Web 開發團隊真正為之奮鬥的希望。

當開發人員受到啟發時，他們正在使用一組優化的工具。 感覺很好。 他們很開心。 他們寫出更好的代碼。

管理員知道他們正在將內容製作到一個美麗的生態系統中。 它很快。 它發貨很快。 用戶正在看到更新的內容，他們正在體驗一個現代、美觀、功能良好、優化的前端。

我想把它總結一下——我希望你記住一些最後的想法。 我認為簡報本身總是缺少語言。 我認為我們經常談論的只是，嘿，為我建立一個漂亮的網站。 為我建立一個了不起的網站。 我想要它的外觀和感覺——我們已經與客戶進行了所有這些評論。

每個人都很興奮，然後 V1 來了，它發布了。 然後需要接管該網站的人就像，你把我弄得一團糟。 我該如何處理？ 這是您設想的一些臨時流程嗎？

你不想建立一個漂亮的網站並交出一個負擔。 在 Haus，我們為不這樣做而感到非常自豪。 我認為 Atlas 和 Atlas 作為一個平台的美妙之處在於它解決了這個問題。

它讓您相信您正在運送一個生態系統和一個網絡發布系統，從基礎設施的角度和代碼部署的角度來看，它們實際上是有意義的。 它向 IT 團隊和工程團隊或營銷團隊提供書面證據，證明您知道自己在做什麼，並且他們現在可以很好地使用您為他們構建的這個新網站。

因為請記住，我們不僅僅是在構建網站。 我們正在建立一個內容髮布系統，從第一天開始理解和承認這一點至關重要。 再一次，這就是 Atlas 發揮作用的地方。

所以我希望這個小花絮能幫助你從戰略上構想你的無頭堆棧向前發展。 如果那是您想採取的方向，我強烈建議您看看 Atlas。 我希望你喜歡這次會議，非常感謝你。