WordPress 加入區塊協議的意義

Matt Mullenweg（WordPress 的創建者）表示有興趣讓 WordPress 編輯器遵守塊協議，這是一個最近發布的規範，旨在讓“塊”可以跨應用程序移植。

當我得知馬特的興趣時，我非常激動，因為這樣的發展也可能對 WordPress 和其他參與者產生一些積極的影響。 我的興奮來自於 GraphQL 發生的事情，遵循通用規範的服務器、客戶端和工具的發布產生了一個豐富的生態系統； 以及我自己開發的一個可以通過協議支持新功能的插件。

在本文中，我將分析這些以及其他幾個潛在的結果。 但在此之前，讓我們探索一下這個故事的背景：什麼是塊，塊協議旨在實現什麼，以及它是如何連接到 WordPress 的。

什麼是塊？

在使用基於 JavaScript 的庫（例如 React 或 Vue）時，我們使用“組件”，它們是組合在一起的代碼片段（通常由 HTML、CSS 樣式和 JavaScript 組成）。 組件呈現定義的佈局或生成特定功能，例如圖像輪播、事件日曆或簡單標題。 為了呈現內容，組件可以通過 API 調用從服務器獲取數據，或者通過包裝它的某個祖先組件通過 props 提供數據。 通過注入數據，組件變得可重用，能夠為不同的上下文或應用程序產生不同的結果。

“塊”也是一個組件，但它是高級別的，聲明了明確的目的，並定義了產生所需佈局或功能的要求。 它是相互包裹的組件層次結構中最外層的組件，因此可以鳥瞰它們。

我們可以在使用 Notion 時使用組件，其中每個操作（無論是編寫文本、添加項目符號列表、創建表格還是其他任何操作）都是通過插入一個或另一個塊來完成的：

塊是一個概念，而不是一種技術。 它可以在任何語言上實現：不僅是為客戶端提供支持的 JavaScript，還可以是一種用於呈現佈局的服務器端語言。 塊不能與 Web 組件混淆，Web 組件是生產組件的技術集合。 它們也不是互斥的——我們可以使用 Web 組件來創建一個塊。

以敏捷世界為例：如果 MVP 或最小可行產品是啟動和營銷商業項目的最少工作，我們可以將塊視為 MUC 或最小可用組件，作為基本單元賦予應用程序連貫性和個性的工作。

什麼是區塊協議？

組件是相當可重用的。 例如，在 npm 上搜索“react 組件”將生成大量庫，這些庫提供了我們可以立即導入到我們的 React 應用程序中的組件。

然而，塊是另一回事，因為它們主要是為某些特定應用程序設計的。 雖然塊必須提供與之交互的方式（例如提供一個 API 來對其進行初始化和渲染，或者公開描述它需要哪些數據作為輸入的 JSON 模式），但這些方式通常取決於塊所在的應用程序，所以我們不能跨應用程序重用一個塊。

這就是塊協議的用武之地。它為要滿足的塊和應用程序提供規範，旨在允許塊嵌入到任何應用程序中，而不僅僅是為它們設計的應用程序。 與組件一樣，塊可以跨應用程序重用。

可重複使用的塊和 WordPress

自 2018 年 12 月的 5.0 版以來，WordPress 中創建內容的默認體驗一直是通過塊。 自最近發布的 5.9 版以來，這種體驗已擴展到通過全站點編輯 (FSE) 創建網站佈局。 為 WordPress 創建內容和主題的現代體驗現在是通過塊來實現的。

當 Joel Spolsky 最近向全世界介紹 Block Protocol 時，他是從他的 WordPress 驅動的博客中做到的。 當他解釋他如何使用塊來撰寫帖子時，他建議塊應該可以在網絡上重複使用。 這是一個直接的建議，即 WordPress 塊應該可以在網絡上重複使用，Matt Mullenweg 立即同意了。

接下來讓我們分析一下，如果發生這種情況，我們可以從這種發展中預見到什麼後果。

誰將使用區塊協議？

這是 Joel 對 Block Protocol 如何形成的描述：

“[由不同應用程序實現一個塊]是完全專有和非標準的。

我想，如果塊可以在網絡上互換和重複使用，那不是很酷嗎？

[...] 用戶可能想要使用他們在 WordPress、Medium 或 Notion 中看到的更高級的塊，但我的編輯器沒有。 塊不能很容易地共享或移動，我們的用戶僅限於我們有時間重新實現的特性和功能。”

雖然我 100% 同意 Joel 的動機，但我認為期望 Notion 或 Medium 使用公開共享的協議來實現他們的區塊是不現實的。 他們為什麼會？ 當然，他們希望他們的區塊是專有的。 如果 Medium 讓任何應用程序都可以嵌入它自己的塊，那麼任何人都可以在一夜之間提供一個 Medium 克隆並從他們那裡轉移流量。 概念也一樣。 作為商業平台，旨在通過其先進的功能和出色的用戶體驗來獲得用戶，他們沒有任何東西可以放棄他們的技術（也就是說，他們仍然可以遵守協議供自己內部使用，但是我們，外人，不會從中受益）。

那麼，除了 WordPress 之外，還有誰可能想要遵守 Block Protocol？ 誰將從中受益？

我的印像如下：

• 沒有大預算的團隊
  與其從頭開始開發自己的塊（這很費力，因此需要專門的團隊），可以使用其他人開發的塊來構建網站； 然後，該團隊可以為自己的應用程序定制這些塊，並可能回饋這些塊的開源代碼。
• 需要迎頭趕上以提供引人注目的用戶體驗的應用程序
  Medium 和 Notion 很受歡迎，因為它們的用戶體驗很吸引人。 如果我們可以為我們的網站提供類似的用戶體驗（並且只需很少或沒有成本），我們為什麼不呢？
  這不一定限於小型網站，也可能是在塊競賽中落後的流行網站的情況。 例如，前段時間我注意到 Mailchimp 正在嘗試使用現代的基於塊的編輯器來撰寫新聞通訊（我再也找不到這個新編輯器了……他們把它拿走了嗎？）。 我試過了，但它有問題，所以我恢復到經典的拆分窗格編輯器（它也支持塊，但類型不同，不能就地編輯）。 Mailchimp 可能會從使用 WordPress 提供的塊中受益嗎？

• 內容管理系統
  與 WordPress 類似，其他 CMS 也可以從提供即用型塊來構建應用程序中受益。 事實上，Drupal Gutenberg 已經嘗試將 WordPress 編輯器引入 Drupal。 多虧了塊協議，這項任務可能更容易完成。
• 開源項目
  與通過 npm 獲得的組件類似，如果塊是可重用的，那麼社區開始構建塊並將它們作為開源免費提供（無論是通過 GitHub、Block Hub 還是其他地方）只是時間問題每個人。

其他人將如何從 WordPress 加入塊協議中受益？

我們剛剛探討了誰可能受益，因此可能想要加入 Block Protocol。 但除此之外，我們可以問自己：如果 WordPress加入 Block Protocol，他們將如何受益？

這是我的印象：

• 訪問 WordPress 塊
  最明顯的答案是，當前可用於 WordPress 的所有塊（通過編輯器和 FSE）也可用於它們自己的應用程序，無論它們是否基於 WordPress。
• 加入社區主導的創建區塊的過程
  創建塊是一個耗時耗力的過程。 Gutenberg 項目花了 5 年時間製作完整的站點編輯器，並且仍在進行中。 任何新版本的 WordPress 涉及的人數都在數百人之內，最新的一個超過 600 名貢獻者。
  WordPress 社區不斷投入大量資源進行溝通，以確保此過程盡可能順利進行，甚至包括召開回顧會議以分析問題所在，並針對即將發布的版本進行改進。
  有多少組織可以與這種管理數百人以生產公共資源的完善過程相媲美？ 出於這個原因，加入由 WordPress 社區領導的生產區塊的努力，而不是單獨行動，可以使每個人受益。
• 一個大的採用者為協議提供了可信度和吸引力
  區塊協議剛剛發布，它仍然是一個草案。 誰會使用它？ 該項目將如何獲得潛在利益相關者的支持？ 讓 WordPress 支持它會發出強烈的信號，並通過知道該項目將有貢獻者和長期支持來為其他人加入建立信心。

WordPress有什麼用？

為了讓 WordPress 在未來 15 年保持相關性，它需要在現代、高度動態的應用程序世界中生存下來。 為此，從 5.0 版本開始，WordPress 已經開始了現代化進程，它已經從一個相當靜態的應用程序轉變為一個基於服務器端 PHP 模板的佈局，它仍然是靜態的，但更少 -所以應用程序從 REST API 獲取數據，並使用 JavaScript 塊來呈現內容，以及 - 從最新版本 5.9 開始 - 佈局。

注意：它仍然不是很動態，因為佈局是預先在wp-admin中生成並保存到數據庫中的，而不是在客戶端對用戶的某些操作做出反應時生成的。

這種轉變需要一段時間才能實現，從 2015 年開始，當時 Matt Mullenweg 要求 WordPress 社區“深入學習 JavaScript”。 加入 Block Protocol 將是 WordPress 現代化之旅的又一站。

讓我們看看它可以從中獲得什麼好處。

保持市場份額的增長

截至今天，WordPress 為 43% 的網站提供支持。 雖然它的成功是不可否認的，但對於 Matt Mullenweg 來說仍然不夠，他表示希望 WordPress 達到 85% 的市場份額。 （判斷這種立場是對是錯不在本文討論範圍內。）

現在，我們可以問自己，究竟什麼是 WordPress 網站？ 過去，憑藉其基於 PHP 的整體架構，響應非常明確。 但是現在我們基於包含多種技術的堆棧構建網站。 我們可能有一個 WordPress 後端為 React 前端提供動力，通過 WP REST API 為其提供數據。 那是一個WordPress網站嗎？

答案是：我不知道，但也可能無關緊要。 如果 WordPress 是堆棧中的技術之一，那麼它將繼續增長。 到目前為止，WordPress 只能承擔 CMS 的角色，管理數據以提供給客戶端。 但是現在，多虧了塊協議，WordPress 可以承擔一個新角色：提供塊來支持任何應用程序的前端。

在這種情況下，WordPress 將在網站創建中發揮更大的作用。 這將導致 WordPress 仍然獲得市場份額，並在 Web 開發工具包中變得更加根深蒂固，使其變得無關緊要變得更加困難。

更大的貢獻者池

通過使用 WordPress 提供的塊，通常不使用 WordPress 的開發人員將熟悉它，並希望能夠欣賞它，並成為開源代碼的貢獻者。 這一點很重要，因為貢獻者池將變得更大（例如，JavaScript 的專業開發人員數量大約是 PHP 的 3 倍），並將帶來更多樣化的技能。

塊的進一步可用性

不用說，塊集線器將以兩種方式工作：WordPress 將使其塊可供其他所有人使用，而且為其他人編碼的塊也可用於為 WordPress 網站提供動力。

例如，如果 Mailchimp 決定加入使用 WordPress 塊來為其新聞通訊編輯器提供動力，然後它改進它們或生成並發布自己的塊，那麼這些將可用於創建和發送新聞通訊的 WordPress 插件。

將 WordPress 編輯器與 Gutenberg 解耦

Gutenberg 是為 WordPress 中的塊編輯器奠定基礎的項目。 它提供了一個能夠與塊交互的引擎。 例如，它從塊的edit和save方法中獲取輸出，以便在編輯器中呈現 HTML 並將其保存到數據庫中。

但是，塊編輯器不需要與 Gutenberg 耦合。 畢竟，“塊”是一個概念，而 Gutenberg 是一個具體的實現。 塊協議可以完美地放置在它們之間，充當概念和實現之間的鏈接。

因此，現在 Gutenberg 可以被拿走，任何其他實現引擎都可以取而代之，提供仍然由相同模塊驅動的不同體驗。

一個有趣的結果是 WordPress 本身可以從這種架構中受益，因為 Gutenberg 並不存在於 WordPress 網站上的任何地方，而只存在於wp-admin上。 換句話說，我們使用 WordPress 構建的面向公眾的網站本身並不依賴古騰堡； 相反，它只是在後端打印使用 Gutenberg 創建的 HTML。 這就是我之前提到的 WordPress 網站仍然不是很動態的原因。

通過使用塊協議與塊進行通信，我們不需要在客戶端安裝 Gutenberg 來使用塊。 相反，我們可以有一個 React 應用程序，它直接基於用戶交互呈現塊，使網站更加動態。

同樣的想法可以在wp-admin中起作用，在 Gutenberg 仍然不可用的任何頁面中（至少在它可用之前）。 例如，如果我們想為我們的插件提供一個完全由塊驅動的設置頁面，通過塊協議，我們可以使用 React 來呈現所需的配置塊（日曆、交互式地圖、滑塊、帶有選項的下拉菜單，或者任何合適的輸入）並添加一些 PHP 邏輯以將數據保存在wp_options表中。

在面向公眾的網站上嵌入塊

更進一步，實際塊可以嵌入到面向公眾的站點中，供用戶與之交互。

這種功能有無窮無盡的用例，包括：

• 顯示日曆供用戶預訂會議時段，如 Calendly 所做的那樣；
• 允許用戶畫一些東西，就像 Brush Ninja 所做的那樣，或者玩遊戲，就像 Block-a-saurus 一樣；
• 讓用戶操縱圖像，這將在即將改進的 FSE 媒體體驗中實現。

另一個例子來自我自己的 WordPress 插件，能夠支持它是我對 Block Protocol 感到興奮的原因。 用於 WordPress 的 GraphQL API 附帶一個 GraphiQL 客戶端塊，它允許編寫 GraphQL 持久化查詢：

同時，我在文檔站點上嵌入了 GraphiQL 客戶端，供訪問者使用，並了解 GraphQL 服務器的工作原理：

使用塊協議，在文檔站點上公開 GraphiQL 客戶端的想法也可以授予我插件的用戶。 然後，他們可以簡單地將 GraphiQL 塊嵌入到自己面向公眾的網站上，以記錄如何從自己的 GraphQL API 中為自己的訪問者檢索數據。

協助古騰堡的“合作”階段

能夠在面向公眾的網站上嵌入塊對於塊編輯器的第 3 階段也很有用，該階段旨在簡化協作以產生類似於 Google Docs 或 Dropbox Paper 的共同創作體驗。

當我收到指向 Dropbox Paper 的鏈接時，無需登錄即可查看其內容：

類似地，我們可以有一個能夠渲染塊並與塊交互的客戶端，以便未登錄的用戶也可以提供反饋。 這些訪問者不需要訪問網站的wp-admin ，因此我們將最大限度地利用合作機會。

進一步完善“Single API for Everything”概念

引入塊概念是為了統一在 WordPress 網站上添加內容的所有不同方式。 過去，當使用“經典”編輯器時，我們可以通過小部件或短代碼添加動態代碼，並通過定制器來操作網站的外觀。 該塊通過提供“單一 API”來生成和自定義網站上的所有內容來替換所有這些不同的機制。

這種簡化已經發生在 UI 中。 但是，塊本身並不總是提供一種處理它們的方法，因為動態塊需要在 JavaScript 和 PHP 中呈現相同的輸出（前者用於為編輯器呈現 HTML，後者用於將其打印到面向公眾的網站）。 這種情況讓開發人員感到焦慮，並為新的貢獻者增加了障礙。

已經有幾個解決這個問題的建議（在這個討論中進行了精彩的總結），但沒有一個具有足夠的說服力。 WooCommerce 插件也處理了類似的問題，但它的解決方案（在我看來）有點複雜。 理想情況下，CMS 應該提供一種創建 DRY 代碼的機制，而無需 hack。

塊協議可以提供更好的選擇。 如果開發人員不想在 PHP 中再次編寫相同的邏輯，則可以使用相同的塊在前端完成塊的呈現。 這將基於客戶端渲染 (CSR) 而不是服務器端渲染 (SSR)，這並不總是推薦的（因為它可能會影響搜索引擎對內容的索引），但選擇其中任何一個的選項將依靠開發商。

作為一個附帶的好處，這個解決方案還可以吸引更多的 React 開發人員使用 WordPress。

使用 WordPress 領域之外的開發

正如我之前提到的，遵守共享協議可能會導致不協調的開發，從而產生豐富的生態系統，就像 GraphQL 發生的那樣。

例如，SpectaQL 是 GraphQL API 的文檔生成器。 只需遵守 GraphQL 規範，該項目就可以自動記錄 API，開發人員只需很少的努力。

遵守區塊協議可能會產生類似的效果。 我們可以預見，一些項目可能會自動從block-metadata.json中提取信息，並生成一個靜態站點，記錄所有塊。 古騰堡目前正在實施同樣的想法。 如果某個項目已經為 Block Protocol 解決了這項工作，那麼 Gutenberg 可以搭上它，並讓其貢獻者騰出時間來處理其他任務。

改進了對 GraphQL 的支持

另一個讓我特別興奮的原因是 WordPress 的 GraphQL 服務器（WPGraphQL 和我自己的 WordPress GraphQL API）目前無法為 Gutenberg 提供最佳支持，因為block.json沒有聲明對像或數組屬性的實際類型。 例如，Gutenberg 中的一個塊可以聲明一個屬性為array類型，但 GraphQL 需要知道它是一個String類型的array 。

塊協議強烈鼓勵定義屬性的最終類型：

如果可用，塊應該期望並處理一個entityTypes字段，該字段包含發送到塊的任何實體的實體類型定義。

因此，如果 WordPress 塊遵守塊協議，它們的 JSON 模式將被升級以提供此信息，然後 GraphQL 插件將能夠檢索塊數據而無需求助於黑客。

包起來

在本文中，我討論了 WordPress 加入塊協議的一些潛在後果，表明它將產生積極的結果。 但是，我還沒有談到實現它的可行性。

技術上可行嗎？ 可以在不破壞向後兼容性的情況下完成嗎？ 潛在的好處是否超過所需的努力？ 區塊協議首先存在是否有意義，或者不同應用程序的不同要求無法在區塊級別協調？

在決定是否加入區塊協議之前，所有這些問題（以及許多其他問題）都需要得到回應。 正如馬特·穆倫韋格（Matt Mullenweg）所表達的那樣，現在是社區參與並決定 WordPress 是應該在這個新港口的現代化之旅中停下來加油，還是跳過它繼續前進的時候了。