需求在何處?
確實,這方面有需求。我知道很多人正在進行這方面的工作。例如,Gatsby 提供了一個 gatsby-source-wordpress
插件,允許你從 WordPress 網站提取內容。這方法利用 WordPress 的 REST API,並將其轉化為 GraphQL,以供在 React 驅動的 Gatsby 網站上使用。我寫這篇文章時,這個插件這個月已被下載了 59,000 次,總計下載次數達到 851,000 次。對於特定的網站建設技術,這是一個健康的數字。每一個使用情境在技術上都是以無頭方式使用 WordPress。如果你對此感興趣,Ganesh Dahal 有一篇深入的研究。
無頭化的意義和優勢是什麼?
Gatsby 的整合提供了一個堅實的理由,解釋了為什麼有人會考慮使用無頭的 WordPress 網站。我會談到這一點。
很多人認為主要的原因是架構。它將後端和前端分開。它打破了單一體系。作為一個解耦的系統,後端和前端可以獨立發展。但隨著時間的推移,我對這個觀點有些保留。例如,我認為在這種無頭設置中,簡單地替換 WordPress 並使用另一個 CMS 是說起來容易,但實際操作起來困難。此外,我計劃使用 WordPress 的 API 來驅動一個網站,並使用一個原生的閱讀應用,以及一些數字連接的廣告牌等,但據我所知,這不是一個快速增長的使用情境。
我認為人們使用 Gatsby 驅動的前端和 WordPress 後端的真正原因基本上是:他們喜歡 React。他們喜歡使用組件來構建。他們喜歡快速的頁面轉換。他們喜歡在 Jamstack 的環境中托管,有所有那些漂亮的開發者預覽功能。他們喜歡熱模塊重載、Prettier 和 JSX。他們就是喜歡這樣,我不怪他們。當你享受這樣的開發者體驗時,回到需要手動刷新瀏覽器和維護某種手動構建過程的 PHP 模板中並不那麼吸引人。
Frontity 是另一個希望在 React + WordPress 上發展的產品。Geoff 和 Sarah 去年分享了在 Vue/Nuxt 上如何實現這一切。
但是,與傳統的基於 PHP 模板的 WordPress 主題相比,無頭的 WordPress 會變得更受歡迎嗎?不會。如果 WordPress 本身推廣這個觀念,並提供指導、培訓和文檔,使開發者更容易採用這種方法,那麼也許會。但這些都還沒有發生。因此,到某種程度,它仍然是一個小眾的選擇。
無頭架構真的那麼小眾嗎?
WP Engine 是一家大型的 WordPress 主機公司,它有一個名為 Atlas 的產品。這種努力確實顯示他們正認真看待這個小眾市場。我不完全確定 Atlas 是什麼,但它看起來像是一個用於啟動網站的儀錶盤,有一些有趣的程式碼配置功能。在無頭 WordPress 的討論中,一個大問題是,現在你有兩個網站要管理。你有一個托管和運行 WordPress 的地方,還有一個托管和運行使用 WordPress API 的網站的地方。也許這在某種程度上將這兩者結合了。從 Git 提交部署的功能很吸引人,我認為這也是現代主機的基礎。
人們喜歡無頭 WordPress 的另一個原因是,最終的結果可以是靜態的,例如預先生成的 HTML 頁面。這意味著你的網站伺服器可以高度使用 CDN,因為它實際上只有靜態資源可以立即下載。沒有用於伺服器端渲染的 PHP 或資料庫,這可能會很慢,因為它在渲染前增加了一個步驟。
什麼是 "WordPress 的方式" 來實現無頭化?
我認為任何為你的 WordPress 網站建立靜態版本的服務都可以歸入無頭的 WordPress 類別。因為最終,這些網站是使用 WordPress 的 API 來建立這些靜態文件,就像 Gatsby 或其他工具會做的那樣。
這就是 Strattic 所做的。他們為你提供了一個 WordPress 網站,他們認為是暫存的。你在那裡進行你的 WordPress 工作,然後使用他們的發布系統將你的網站的靜態版本推送到生產環境。這很有吸引力,因為它解決了其他無頭 WordPress 解決方案所不能解決的問題:就是按照 WordPress 的方式工作。
例如,定制的 WordPress 區塊或插件可能產生的輸出不僅包含定制的 HTML,還包含 CSS 和 JavaScript。想像一下一個 "旋轉木馬" 區塊或插件。如果你只是從 API 中提取文章內容,然後將其放入一個頁面,那麼這個旋轉木馬就不會運作。你要麼需要從其他地方提取 CSS 和 JavaScript 並將其包含在內,要麼就是知道你不再這樣做。你可能會以某種方式將圖片作為元數據附加,然後在客戶端提取它們,並進行你自己的旋轉木馬實現。通過 Strattic,理論上,它可以運作,因為 HTML、CSS 和 JavaScript 仍然存在於靜態網站上。但值得注意的是,你沒有 PHP,所以 Strattic 必須手動建立表單集成,他們使用客戶端的 Algolia 進行搜索,使用 Disqus 進行評論,等等,因為沒有伺服器端語言可用。
Shifter 是另一個參與者。它與 Strattic 類似,你在 WordPress 管理界面中管理你的網站,然後發布到一個靜態網站。我相信 Shifter 甚至可以在你的 WordPress 網站不使用時將其關閉,這是有道理的,因為輸出是靜態的,沒有理由需要運行一個帶有 PHP 和 MySQL 的伺服器。作為一個替代方案,Shifter 有一個無頭的 WordPress 設置,它可能一直在運行,以供外部 API 使用。
結語
我意識到大多數關於無頭 WordPress 的討論和想法都集中在開發者上。WordPress 有一個龐大的市場,那就是那些不是開發者的人。他們管理一個 WordPress 網站,並充分利用插件和主題的生態系統。這很酷,而且令人印象深刻的是,WordPress 能夠為這兩個市場提供如此出色的服務。我估計很多 WordPress 網站的擁有者不是開發者,所以這一點可能使無頭的 WordPress 在一段時間內仍然是一個小眾的概念。但是 Headless CMS 無疑是未來的趨勢,所以未來應該會有越來越多開發者加入。