EP178. “自定义 Block 的理念：何时不该只用核心 Block”

在正式动手写自定义 Block 之前，先讲清楚「为什么不能只靠 WordPress 官方核心 Block 和 Block Pattern 搭完整个主题」。用官方 2022 默认主题举例：翻遍它的所有模板文件，找不到一行 PHP、HTML、CSS 或 JavaScript——全部由核心 Block 注释和 theme.json 里几个精心选择的默认值拼成，这类主题本身没有值得专门开课教的技术含量,直接在编辑器里拖拽组合就够了。但只要你的项目有下列任何一种诉求，就不能 100% 依赖核心 Block：想用自己的 CSS 框架（Bootstrap/Tailwind/自己写的 Sass）而不是被 WordPress 设计系统绑死；需要按 meta 值或关联关系做复杂查询，query-loop 这类核心 Block 完全做不到；网站规模一旦到几千上万个页面，希望「改一次代码全站生效」而不是每个页面各自存一份写死的 HTML（Block Pattern 插入后就和原始预设彻底脱钩，插入 700 次以后想统一微调一处细节，没有办法批量生效）。

涉及文件

本讲不写代码，用官方 2022 主题源码和 Block Pattern 的实际数据库存储结果作为分析对象。

核心概念

• 官方 2022 默认主题几乎不含自定义代码：templates/ 目录下的每个 .html 文件基本只有核心 Block 的注释语法，真正的「工作量」大多落在 inc/patterns/ 这个文件夹里——里面注册的是一批 Block Pattern（区块图案/预设组合）
• Block Pattern 本质是什么：就是「预先排列组合好的一批 Block」，概念上类似代码编辑器里的代码片段（snippet）——插入时只是把这批 Block 的 HTML 注释一次性贴进当前内容里，背后没有任何动态机制
• Block Pattern 一旦插入就和原始预设彻底断开联系：亲自实测过——在一篇新文章里插入某个官方内置 Pattern（比如「带描述的纯色图片」），保存后去数据库里看 wp_posts.post_content，存的就是这批 Block 的原始 HTML，没有任何字段记录「这段内容是从哪个 Pattern 插入的」。这意味着如果同一个 Pattern 被用在 700 篇文章/页面里，以后想统一调整这批内容的某个细节，没有办法「改一处、全站生效」，必须一篇一篇手动修改
• 這不是缺点，是不同项目诉求下的取舍：如果项目本身就是「让非技术客户完全自己拼装页面」这种诉求（更像设计工具而不是内容管理系统），核心 Block + Pattern 完全够用，甚至是优点；但如果项目是「作为内容管理系统管理成百上千篇结构统一的内容」，Pattern 这种「一插入就定死」的模式反而是隐患
• query-loop 核心 Block 的能力上限（EP177 已提过，这里再次强调）：只能按文章类型/排序方式/分类做基础筛选，没法处理 Fictional University 网站上「近期活动」这种「按 meta 值里的活动日期是否晚于今天来筛选」的自定义查询需求
• 接下来这一章的方向：把 Fictional University 传统主题按视觉区域拆解成一个个「自己写的自定义 Block」（而不是全部改用核心 Block 拼凑），从最上方的首页 Banner 区块开始，逐步转换成 Block Theme。用自定义 Block 不是因为核心 Block 做不出相似的视觉效果（作者承认这个简单的 Banner 用核心 Block 组合也能拼出差不多的样子），而是为了在遇到「视觉更复杂、需要自定义查询」的场景时，已经掌握了「自己接管 HTML 输出」这条路子该怎么走

延伸 / 后续讲座会用到

下一讲开始动手写第一个自定义 Block——首页顶部的 Banner 区块。

Sources

Udemy：

• Become a WordPress Developer: Unlocking Power With Code — Section 28, EP178