EP216. “为什么以前要自己发明轮子：block.json 时代前的三个痛点”

这一章的开场，回答一个贯穿上一章的疑问：既然 WordPress 官方后来有了这么干净的标准化 Block 开发方式，为什么上一章（Block Theme）要费劲自己写 JSXBlock/PlaceholderBlock 这类手搓的 PHP 类？答案是历史时间线问题——作者从 2018 年底 Block 刚进入 WordPress 核心时就开始用，当时官方标准做法还没成型,只能自己发明一套。这一讲梳理了三个关键的时间节点,解释了「为什么以前必须自己造轮子」，也是为了让读者接手真实项目时,能看懂并理解那些仍在用旧写法的既有代码库。

涉及文件

本讲是纯历史/概念背景介绍，不涉及代码改动。

核心概念

• 痛点一：block.json 直到 2021 年年中才成为官方标准——Block 本身早在 2018 年底就进入 WordPress 核心，但当时没有一份标准化的文件能集中声明「这个 Block 叫什么名字、脚本/样式/渲染文件分别在哪」，也没有清晰整洁的资源加载方式——于是大家各显神通,自己发明各自的文件组织习惯（也就是上一章的 our-blocks/ 文件夹 + 手写 PHP 类）
• 痛点二：@wordpress/scripts 这个官方构建工具包，早期不能优雅地处理「一个主题/插件里有多个 Block」的场景——不会自动扫描多个子文件夹、不会自动识别每个子文件夹里的 block.json；这也是为什么上一章要在 package.json 里手动罗列每一个 Block 的入口文件（our-blocks/banner.js our-blocks/genericheading.js ...），新增一个 Block 就要手动多加一项
• 痛点三：Interactivity API 直到 2024 年 4 月才进入 WordPress 核心——在这之前，如果想让前台的 JavaScript 访问到某个 Block 实例的属性数据，开发者必须自己发明一套「PHP → HTML → JS」的传递机制（这门课在插件章节学过的、把 attributes 编码成 JSON 藏进隐藏 <pre> 标签的手法，正是这类「手工搭桥」的典型代表）
• 这三个痛点叠加的结果：早期开发者几乎必然要自己发明一整套样板代码来管理多个 Block——上一章的 JSXBlock（可选 PHP 渲染回调）和 PlaceholderBlock（纯 PHP、无需构建）正是这种历史遗留做法的缩影
• 现状：以上三个问题目前都已经被官方彻底解决——block.json 已经是注册 Block 的标准方式；@wordpress/scripts 现在能自动扫描识别多个 Block 子文件夹；Interactivity API 让「前台 JS 访问 Block 数据」变成官方标准流程,不再需要手工搭桥
• 为什么依然要学上一章那套「过时」的做法：现实中大概率会接手别人几年前写的 WordPress 项目，这些项目大概率还在用类似上一章的手搓写法——理解这段历史，能让人一眼看懂那些代码「为什么长这样」，而不是看到陌生的自定义类就一头雾水
• 这一章的目标：把上一章已经搭好的 Block Theme，逐个 Block 改造/迁移成 2024 年官方推荐的现代标准做法（block.json + 自动化的多 Block 构建流程），体验一次「同样的功能，用官方标准工具实现起来能有多清爽」

延伸 / 后续讲座会用到

下一讲开始动手：复制一份 Block Theme 主题文件夹，先拿最简单的 Footer Block 练手，迁移到 block.json 标准做法。

Sources

Udemy：

• Become a WordPress Developer: Unlocking Power With Code — Section 29, EP216