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 是应该在这个新港口的现代化之旅中停下来加油，还是跳过它继续前进的时候了。