跳到主要内容

7 篇博文 含有标签「FSE」

查看所有标签

修复 FSE Block Theme 的风格预览单色块与首页白屏问题

· 阅读需 4 分钟

在为客户开发 WordPress FSE Block Theme 时,遇到风格预览显示异常和首页编辑白屏两个问题。记录根因与解法。

TL;DR

  1. Style variation 的 palette/gradients整体替换而非合并,只写 1 个颜色会丢失其余全部 -- 必须补全完整列表,只改需要变化的颜色。
  2. front-page.html 模板硬编码 pattern 会导致 Site Editor 编辑白屏,且用户无法在编辑器中调整布局 -- 应改为页面内容驱动。

坑一:Style Variation 风格预览只显示一个颜色块

问题现象

Site Editor > Browse Styles 中,默认风格显示 16 个颜色块,而第二个风格(Amber)只显示 1 个颜色块。切换到 Amber 风格后,所有引用 primarybasecontrast 等 CSS 变量的元素全部失去颜色。

根因

WordPress theme.json 的 style variation 机制中,settings.color.palettesettings.color.gradients 是**整体替换(replace)**父主题的对应声明,而非增量合并(merge)。

原始 styles/amber.json

{
"settings": {
"color": {
"palette": [
{ "slug": "accent", "color": "#b45309", "name": "Amber" }
]
}
}
}

这段配置的本意是"只把 accent 颜色换成琥珀色",但实际效果是"整个调色板只剩这一个颜色"。父主题 theme.json 中定义的 primarysecondarybasecontrastsurfaceneutral-50 ~ neutral-900 全部丢失。

gradients 同理,只声明 1 个就会替换掉父主题的 7 个渐变。

解决方案

在 variation 文件中补全完整的 palette 和 gradients 列表,只修改需要变化的值:

{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"title": "Amber",
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#0f172a", "name": "Primary" },
{ "slug": "secondary", "color": "#334155", "name": "Secondary" },
{ "slug": "accent", "color": "#b45309", "name": "Amber" },
{ "slug": "base", "color": "#ffffff", "name": "Base" },
{ "slug": "contrast", "color": "#f8fafc", "name": "Contrast" },
{ "slug": "surface", "color": "#0f172a", "name": "Surface" },
{ "slug": "neutral-50", "color": "#fafafa", "name": "Neutral 50" }
// ... 其余 neutral 色保持不变
],
"gradients": [
// 补全所有 7 个渐变,只修改 accent gradient 的目标色
]
}
}
}

关键原则:variation 中声明的任何数组类型配置项(palette、gradients、fontSizes、spacingSizes 等)都是整体替换,必须包含完整内容。

坑二:Site Editor 编辑首页白屏

问题现象

在 Site Editor 中通过 Pages > Home 打开首页编辑,画布完全空白。但在 Templates > Front Page 中能看到完整布局。

根因

这是两个不同的编辑入口,对应不同的数据源:

入口编辑对象数据来源
Templates > Front Pagefront-page.html 模板主题文件
Pages > Homepage_on_front 页面内容数据库 wp_posts.post_content

原始 front-page.html 在模板层面硬编码了三个 pattern:

<!-- wp:pattern {"slug":"cclee-theme/hero-centered"} /-->
<!-- wp:pattern {"slug":"cclee-theme/features-grid"} /-->

<!-- wp:group {"tagName":"main","align":"full"} -->
<main class="wp-block-group alignfull">
<!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:pattern {"slug":"cclee-theme/cta-banner"} /-->

post-content 块渲染 page_on_front 页面的数据库内容。该页面内容为空,所以 Pages > Home 画布空白 -- 这是 WordPress 预期行为。

问题在于:模板硬编码 pattern 导致用户无法在页面编辑器中调整首页布局顺序和内容。

解决方案

将首页布局从"模板硬编码"改为"页面内容驱动"。

1. 模板只保留骨架front-page.html):

<!-- wp:template-part {"slug":"header-transparent","tagName":"header"} /-->

<!-- wp:group {"tagName":"main","align":"full","layout":{"type":"constrained"}} -->
<main class="wp-block-group alignfull">
<!-- wp:post-content {"layout":{"type":"constrained"}} /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer-columns","tagName":"footer"} /-->

2. 激活时自动注入默认内容functions.phpinc/setup.php):

add_action( 'after_switch_theme', function () {
$front_page_id = (int) get_option( 'page_on_front' );
if ( ! $front_page_id ) {
return;
}

$post = get_post( $front_page_id );
// 仅在内容为空时注入,不覆盖用户已有内容
if ( ! $post || ! empty( trim( $post->post_content ) ) ) {
return;
}

$default_content = '<!-- wp:pattern {"slug":"cclee-theme/hero-centered"} /-->' . "\n"
. '<!-- wp:pattern {"slug":"cclee-theme/features-grid"} /-->' . "\n"
. '<!-- wp:pattern {"slug":"cclee-theme/cta-banner"} /-->';

wp_update_post( [
'ID' => $front_page_id,
'post_content' => $default_content,
] );
} );

设计决策

  • 模板只负责 header / main(post-content)/ footer 骨架
  • 首页布局完全由页面内容驱动,用户可在页面编辑器中增删、排序 pattern
  • after_switch_theme 钩子保证主题首次激活时有默认内容
  • 内容为空判断确保不覆盖用户的自定义内容

对类似需求感兴趣?联系合作

修复通用 hover 选择器穿透嵌套 Group 导致的卡片悬浮错乱

· 阅读需 3 分钟

在为客户开发 WordPress FSE Block Theme 时发现:博客列表页的卡片悬浮时文字区域发生偏移,但卡片外框不动,视觉上非常违和。记录根因与解法。

TL;DR

通用卡片 hover 选择器 .wp-block-columns .wp-block-column > .wp-block-group:hover 会匹配到卡片内部嵌套的文字 group,导致悬浮时内层文字偏移而外层卡片不动。修复方式:用 .wp-block-post-template 前缀重置内层 group 的 hover 效果。

问题现象

博客列表页使用卡片式布局(外层 border group 包裹图片 + 文字 group)。鼠标悬浮卡片时:

  • 内部的标题和摘要文字产生 translateY(-4px) 位移
  • 外层卡片的 border 和 shadow 没有任何变化
  • 视觉效果像文字"飘出"了卡片

根因

FSE 中卡片 pattern 的 HTML 结构是嵌套的:

<!-- 外层卡片 group (有 border) -->
<div class="wp-block-group has-border-color ...">
<img ... /> <!-- 特色图片 -->

<!-- 内层文字 group -->
<div class="wp-block-group" style="padding:...">
<h2>文章标题</h2>
<p>摘要文字...</p>
</div>
</div>

主题中定义了一个通用 hover 特效:

.wp-block-columns .wp-block-column > .wp-block-group:hover {
transform: translateY(-4px);
box-shadow: 0 12px 32px rgba(0, 0, 0, 0.1);
}

这个选择器的本意是让整张卡片悬浮上移。但在博客列表页中,post-template 块内部的卡片也被 wp-block-columns 包裹,导致选择器同时命中了内层文字 group(它也是 .wp-block-column > .wp-block-group)。

由于内层 group 没有 border 和 shadow,只表现为文字位移,而外层卡片没有位移效果。

解决方案

分两步处理:重置内层 + 给外层单独加 hover

1. 重置内层 group 的 hover

.wp-block-post-template 前缀提高优先级,把内层 group 的所有 hover 效果清零:

/* Reset hover for inner groups inside post template cards */
.wp-block-post-template .wp-block-columns .wp-block-column > .wp-block-group {
transition: none;
}
.wp-block-post-template .wp-block-columns .wp-block-column > .wp-block-group:hover {
transform: none;
box-shadow: none;
}

2. 给外层卡片加独立的 hover

外层卡片有 .has-border-color 类,用它做精确匹配:

/* Blog card (outer bordered group) -- hover lift + shadow */
.wp-block-post-template .wp-block-group.has-border-color {
transition:
transform 0.3s ease-out,
box-shadow 0.3s ease-out;
}
.wp-block-post-template .wp-block-group.has-border-color:hover {
transform: translateY(-4px);
box-shadow: 0 12px 32px rgba(0, 0, 0, 0.08);
}

为什么不直接缩小通用选择器范围?

通用选择器被多个 pattern 共享(features-grid、pricing、testimonial 等),这些 pattern 的 group 只有一层,不存在嵌套穿透问题。缩小通用选择器反而会破坏其他 pattern 的 hover 效果。

重置内层比限制外层更可靠,因为:

  • 不影响其他使用通用 hover 的 pattern
  • 精确针对有嵌套问题的场景
  • CSS 层面完全隔离,不需要修改任何 HTML/PHP

经验总结

在 FSE Block Theme 中添加 hover 特效前,务必:

  1. 检查 pattern 的实际 HTML 嵌套结构
  2. 确认选择器只命中目标元素(外层容器),不会穿透到内部 group
  3. 如果多个 pattern 共享同一选择器,优先用"重置内层"而非"限制外层"

对类似需求感兴趣?联系合作

修复 WooCommerce FSE Cart Block 空车白屏与商品无图塌陷

· 阅读需 4 分钟

在为客户开发 WooCommerce FSE Block Theme 时遇到这两个问题:Cart Block 空车时页面白屏、商品无特色图片时卡片高度塌陷。记录根因与解法。

TL;DR

  1. Cart Block 必须显式声明 filled-cart-blockempty-cart-block 子块,否则空车时无任何内容输出。
  2. 商品无特色图片时,FSE 的 post-featured-image 块渲染为空字符串,导致卡片高度塌陷。通过 post_thumbnail_html filter 补上 WooCommerce 占位图。

问题一:Cart Block 空车白屏

问题现象

购物车页面在有商品时正常显示,清空购物车后整个页面内容区变成空白 -- 没有提示文案,没有"继续购物"按钮,用户无法自助返回。

根因

WooCommerce Cart Block (wp:woocommerce/cart) 的设计要求开发者显式声明两个子块:

  • wp:woocommerce/filled-cart-block -- 有商品时显示
  • wp:woocommerce/empty-cart-block -- 空车时显示

如果只写了 Cart Block 本体而没有嵌套这两个子块,WooCommerce 在空车状态下不知道该渲染什么,输出为空。

这个问题在经典主题中不存在,因为经典主题使用 PHP 模板 cart.php,其中已经内置了空车处理逻辑。但 FSE 的 HTML 模板是声明式的,必须完整声明所有状态。

解决方案

cart.html 模板的正确结构:

<!-- wp:woocommerce/cart {"className":"cclee-cart"} -->
<div class="wp-block-woocommerce-cart alignwide is-loading">

<!-- wp:woocommerce/filled-cart-block -->
<div class="wp-block-woocommerce-filled-cart-block">
<!-- 有商品时的完整布局:商品列表 + 汇总 -->
<!-- wp:columns -->
<div class="wp-block-columns">
<!-- wp:column {"width":"65%"} -->
<div class="wp-block-column" style="flex-basis:65%">
<!-- wp:woocommerce/cart-items-block -->
<div class="wp-block-woocommerce-cart-items-block"></div>
<!-- /wp:woocommerce/cart-items-block -->
</div>
<!-- /wp:column -->
<!-- wp:column {"width":"35%"} -->
<div class="wp-block-column" style="flex-basis:35%">
<!-- wp:woocommerce/cart-totals-block -->
<div class="wp-block-woocommerce-cart-totals-block">
<!-- wp:woocommerce/cart-order-summary-block /-->
<!-- wp:woocommerce/proceed-to-checkout-block /-->
</div>
<!-- /wp:woocommerce/cart-totals-block -->
</div>
<!-- /wp:column -->
</div>
<!-- /wp:columns -->
</div>
<!-- /wp:woocommerce/filled-cart-block -->

<!-- wp:woocommerce/empty-cart-block -->
<div class="wp-block-woocommerce-empty-cart-block">
<!-- 空车提示 + 继续购物按钮 -->
<!-- wp:paragraph {"align":"center","textColor":"neutral-500"} -->
<p class="has-text-align-center has-neutral-500-color has-text-color">Your cart is currently empty.</p>
<!-- /wp:paragraph -->
<!-- wp:buttons {"layout":{"type":"flex","justifyContent":"center"}} -->
<div class="wp-block-buttons">
<!-- wp:button {"backgroundColor":"accent","textColor":"base"} -->
<div class="wp-block-button"><a href="/shop/" class="wp-block-button__link has-base-color has-accent-background-color has-text-color has-background wp-element-button">Browse Products</a></div>
<!-- /wp:button -->
</div>
<!-- /wp:buttons -->
</div>
<!-- /wp:woocommerce/empty-cart-block -->

</div>
<!-- /wp:woocommerce/cart -->

关键点filled-cart-blockempty-cart-block 必须是 wp:woocommerce/cart 的直接子块,WooCommerce 通过这两个子块实现有货/空车的条件渲染。

问题二:商品无特色图片时卡片塌陷

问题现象

在商品列表页(archive-product)中,没有设置特色图片的商品卡片只显示文字部分,没有图片区域。与有图卡片混排时,布局高度不统一,视觉上非常突兀。

根因

FSE 的 wp:post-featured-image 块在文章/商品没有缩略图时直接渲染为空字符串,不会输出占位图。经典主题中通常在 PHP 模板里手动处理这种情况(has_post_thumbnail() 判断),但 FSE HTML 模板无法嵌入这种条件逻辑。

解决方案

在主题的 functions.php 或 WooCommerce 集成文件中添加 filter:

/**
* Product placeholder image when no featured image is set.
*
* FSE post-featured-image block renders empty when no thumbnail,
* causing card height collapse. This filter injects the WooCommerce
* placeholder image for product post type.
*
* @param string $html The post thumbnail HTML.
* @param int $post_id The post ID.
* @return string
*/
add_filter( 'post_thumbnail_html', function ( $html, $post_id ) {
// Already has image or not a product -- skip.
if ( $html || get_post_type( $post_id ) !== 'product' ) {
return $html;
}

// Use WooCommerce's built-in placeholder.
$src = function_exists( 'wc_placeholder_img_src' )
? wc_placeholder_img_src()
: '';

if ( ! $src ) {
return '';
}

return sprintf(
'<img src="%s" alt="%s" loading="lazy" decoding="async" style="width:100%%;height:100%%;object-fit:cover;">',
esc_url( $src ),
esc_attr( get_the_title( $post_id ) )
);
}, 10, 2 );

注意

  • wc_placeholder_img_src() 依赖 WooCommerce 插件激活,用 function_exists() 做防护
  • object-fit: cover 确保占位图和正常特色图片的裁剪行为一致
  • 只针对 product 类型生效,不影响博客文章等其他 post type

对类似需求感兴趣?联系合作

修复 Gutenberg Gradient Class 命名变更导致的 Block 验证失败

· 阅读需 2 分钟

在为客户开发 WordPress FSE 主题时遇到此问题,记录根因与解法。

TL;DR

Gutenberg 升级后,gradient 的 CSS class 命名规则从 has-{slug}-gradient 变为 has-{slug}-gradient-background。手写 Pattern HTML 中的旧 class 与 Gutenberg 验证逻辑不匹配,导致 Site Editor 报错。解决方案是批量替换 class 名称。

问题现象

所有历史 Pattern 在 Site Editor 中显示错误:

Block contains unexpected or invalid content
  • 新建 Pattern 无此问题
  • 前台渲染正常
  • 点击 "Attempt Recovery" 可恢复显示

根因分析

通过 DevTools Console 查看 Block validation failed 日志,对比 Expected 与 Actual:

Expected(Gutenberg 生成)

<div class="wp-block-group has-accent-gradient-background has-background">

Actual(Pattern 中手写)

<div class="wp-block-group has-accent-gradient has-background">

Gutenberg 版本升级后,gradient class 命名规则变更:

旧命名新命名
has-{slug}-gradienthas-{slug}-gradient-background

Block 验证时,Gutenberg 会根据块注释中的 JSON 属性(如 "gradient":"accent-gradient")重新计算期望的 HTML,与实际 HTML 比对。class 不匹配即报验证失败。

解决方案

1. 确认影响范围

# 查找使用旧 class 的文件
grep -r "has-[a-z0-9-]*-gradient " patterns/ --include="*.php"

2. 批量替换

# macOS/Linux 通用
sed -i '' 's/has-\([a-z0-9-]*\)-gradient /has-\1-gradient-background /g' patterns/*.php

# Linux (GNU sed)
sed -i 's/has-\([a-z0-9-]*\)-gradient /has-\1-gradient-background /g' patterns/*.php

注意

  • 只替换 HTML 标签中的 class 属性
  • 块注释中的 "gradient":"accent-gradient" 声明不需要改动
  • 正则末尾有空格,避免误匹配 has-accent-gradient-background

3. 验证修复

  1. 清理 WordPress 缓存:wp cache flush
  2. 刷新 Site Editor,确认错误消失
  3. 抽查几个 Pattern,验证前后台显示正常

预防措施

  1. 优先使用块注释属性:通过 JSON 属性(如 "gradient":"accent-gradient")设置样式,让 Gutenberg 自动生成 class,避免手写
  2. 关注 Gutenberg 更新日志:升级前检查 Breaking Changes
  3. 开发环境先验证:升级后在开发环境测试所有 Pattern,确认无验证错误再部署

对类似需求感兴趣?联系合作

修复 FSE Group 块 layout 属性覆盖自定义 CSS 的问题

· 阅读需 3 分钟

TL;DR

WordPress FSE Group 块的 layout 属性会自动生成 is-layout-* CSS 类,这些类的样式优先级高于普通自定义 CSS,导致尺寸设置失效。解决方案:1) 块注释中使用 "layout":{"type":"default"} 避免生成额外布局类;2) CSS 中使用 !important 强制覆盖;3) 关键:添加 padding: 0 !important 清除 Group 块默认内边距。

问题现象

Timeline 组件的年份圆点应显示为 80px 正圆,实际却呈现为椭圆:

<!-- 块注释中的尺寸设置 -->
<!-- wp:group {"style":{"dimensions":{"width":"80px","height":"80px"}},"layout":{"type":"flex",...}} -->
/* 自定义 CSS */
.cclee-timeline-dot {
width: 80px;
height: 80px;
border-radius: 50%;
}

无论调整 CSS 还是块属性,圆点始终被拉伸变形。

根因

WordPress FSE 的 Group 块会根据 layout 属性自动添加布局相关的 CSS 类:

<div class="wp-block-group cclee-timeline-dot is-layout-flow">

这些 is-layout-* 类来自 WordPress 核心样式表,其样式规则会覆盖自定义 CSS。同时,Group 块存在默认 padding,会撑大元素导致尺寸计算偏差。

关键问题点:

  1. layout: {"type": "flex"} 生成 is-layout-flex 类,子元素受 flexbox 拉伸影响
  2. 块注释中的 style.dimensions 转为 inline style,但被布局类样式覆盖
  3. Group 块默认 padding 增加了元素实际尺寸

解决方案

1. 修改块注释,使用 default layout

<!-- wp:group {"className":"cclee-timeline-dot","style":{"border":{"radius":"50%"}},"backgroundColor":"accent","textColor":"base","layout":{"type":"default"}} -->
<div class="wp-block-group cclee-timeline-dot has-base-color has-accent-background-color has-text-color has-background" style="border-radius:50%">

移除 style.dimensions 和复杂的 flex layout,改用 "layout":{"type":"default"}

2. CSS 强制覆盖 + 清除默认 padding

/* Timeline: Fixed circle dot */
.wp-block-group.cclee-timeline-dot {
width: 80px !important;
height: 80px !important;
min-width: 80px !important;
min-height: 80px !important;
flex-shrink: 0 !important;
aspect-ratio: unset !important;
border-radius: 50% !important;
display: flex !important;
align-items: center !important;
justify-content: center !important;
align-self: center !important;
box-sizing: border-box !important;
text-align: center !important;
padding: 0 !important; /* 关键:清除默认 padding */
}

.wp-block-group.cclee-timeline-dot p {
margin: 0 !important;
white-space: nowrap !important;
line-height: 1 !important;
overflow: visible !important;
}

3. 使用 :has() 控制父容器

防止父级 Column 被 flexbox 拉伸:

.wp-block-columns .wp-block-column:has(.cclee-timeline-dot) {
flex-shrink: 0 !important;
flex-basis: 100px !important;
width: 100px !important;
}

关键发现

padding: 0 !important 是最终解决方案。Group 块的默认 padding 会撑大元素,即使设置了 width/height,实际渲染尺寸仍会超出预期。


对类似需求感兴趣?联系合作

修复 WordPress FSE 主题 Footer 文字不可见的 WCAG 对比度问题

· 阅读需 3 分钟

在为客户开发 WordPress FSE 企业主题时,发现 Footer 区块在多个 Style Variation 下文字几乎不可见。本文记录从 WCAG 对比度诊断到引入语义色、处理全局样式覆盖的完整修复过程。

TL;DR

问题:FSE 主题的 contrast 颜色 token 语义混乱,浅色主题中 contrast ≈ 浅灰 ≈ base(白色),导致 Footer 对比度仅 1.05:1。

解法

  1. 引入 surface 语义色,专用于深色区块背景
  2. 删除 wp_global_styles 中的覆盖样式
  3. 所有 Style Variations 同步添加 surface 定义

结果:对比度从 1.05:1 提升至 15.8:1(WCAG AAA 级)。

问题现象

Footer 区块使用 backgroundColor="contrast" + textColor="base"

<!-- wp:group {"backgroundColor":"contrast","textColor":"base"} -->
<div class="has-base-color has-contrast-background-color">
Footer 内容
</div>

在默认主题下,Footer 文字几乎不可见:

组合前景色背景色对比度WCAG
Footer 文字#ffffff (base)#f8fafc (contrast)1.05:1❌ 失败
Footer 链接#f59e0b (accent)#f8fafc (contrast)1.78:1❌ 失败

WCAG AA 标准要求普通文字对比度 ≥ 4.5:1,当前状态远不达标。

根因分析

1. contrast 语义混乱

contrast 的设计意图是"与 base 形成对比的背景色",但在不同主题模式下语义矛盾:

Variationbasecontrast期望 vs 实际
默认(浅色)#ffffff#f8fafc 浅灰期望深色,实际浅色
Tech(深色)#0f0f1a 深黑#1e1e2e 深紫期望浅色,实际深色

Footer Pattern 假设 contrast 是深色背景,但 5/6 的 Style Variations 中它是浅色。

2. 颜色语义缺乏明确用途定义

原设计系统只有 contrast 一个"对比色",没有区分:

  • 浅色对比区块(CTA Banner 等强调区域)
  • 深色对比区块(Footer、暗色 Hero 等)

解决方案

Step 1:引入 surface 语义色

theme.json 中新增 surface token,专用于深色区块背景:

{
"slug": "surface",
"color": "#0f172a",
"name": "Surface"
}

Step 2:更新所有 Style Variations

每个 variation 定义自己的 surface 色(通常等于 primary):

// styles/commerce.json
{ "slug": "surface", "color": "#1f2937", "name": "Surface" }

// styles/nature.json
{ "slug": "surface", "color": "#14532d", "name": "Surface" }

// styles/tech.json(深色主题)
{ "slug": "surface", "color": "#1e1e2e", "name": "Surface" }
<!-- wp:group {"backgroundColor":"surface","textColor":"base"} -->
<div class="has-base-color has-surface-background-color">
Footer 内容
</div>

Step 4:删除全局样式覆盖

修改 theme.json 后颜色仍不生效?检查全局样式:

# 检查是否存在全局样式
docker exec wp_cli wp post list --post_type=wp_global_styles --fields=ID,post_title --allow-root

# 删除全局样式
docker exec wp_cli wp post delete <ID> --force --allow-root
docker exec wp_cli wp cache flush --allow-root

原因wp_global_styles 中的 color.palette完全覆盖(非合并)theme.json 的调色板。

修复结果

Variationsurface + base 对比度WCAG 级别
默认15.8:1✅ AAA
Commerce13.1:1✅ AAA
Industrial12.6:1✅ AAA
Professional9.9:1✅ AAA
Nature10.8:1✅ AAA
Tech11.5:1✅ AAA

颜色语义总结

Token用途
primary品牌主色(Logo、主按钮)
secondary次要元素
accent行动召唤(CTA、链接)
base页面主背景
contrast浅色对比区块背景
surface深色区块背景(Footer、暗色 CTA) ← 新增

对类似需求感兴趣?联系合作

解决 WordPress FSE Pattern 块验证失败的 5 种原因

· 阅读需 5 分钟

在为客户开发 WordPress FSE 主题时,频繁遇到 Block Pattern 验证失败问题。本文总结 5 种常见原因与解决方案。

TL;DR

块验证失败通常是以下原因之一:颜色 slug 未定义JSON 重复 keyStyle Variation 调色板覆盖HTML 属性与块注释不一致全局样式覆盖 theme.json。逐一排查即可解决。

问题现象

编辑器中 Pattern 显示红色警告:

Block contains unexpected or invalid content

尝试恢复块内容后,可能暂时正常,但刷新后问题复现。


原因一:颜色 slug 未定义

根因

Pattern 块属性引用了 theme.json 中不存在的颜色 slug:

<!-- 错误:neutral-text 不存在 -->
<!-- wp:paragraph {"textColor":"neutral-text"} -->
<p class="has-neutral-text-color">...</p>

解决方案

  1. 打开 theme.json,检查 settings.color.palette 定义的所有颜色
  2. 将 Pattern 中的无效 slug 替换为有效值
# 批量替换示例
cd patterns/
sed -i 's/"neutral-text"/"neutral-500"/g' *.php
sed -i 's/has-neutral-text-color/has-neutral-500-color/g' *.php

有效 slug 参考: primary, secondary, accent, base, contrast, neutral-50 ~ neutral-900


原因二:JSON 重复 key

根因

块注释 JSON 中同一层级出现重复 key(常见于复制粘贴):

// 错误:两个 style
{"style":{"typography":{...}},"style":{"spacing":{...}}}

JSON 规范不允许重复 key,解析器行为未定义。

解决方案

合并为单一 key:

// 正确
{"style":{"typography":{...},"spacing":{...}}}

排查命令:

# 搜索可能重复的 key
grep -n ',"style":{' patterns/*.php | head -20

原因三:Style Variation 覆盖调色板

根因

styles/*.json 中的 color.palette完全覆盖(非合并)父主题调色板。

当 Pattern 引用 neutral-500,但当前 Style Variation 未定义该颜色时,验证失败。

解决方案

每个 Style Variation 必须包含完整的 neutral 系列:

// styles/ocean.json
{
"version": 3,
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#0d9488", "name": "Primary" },
{ "slug": "secondary", "color": "#0f766e", "name": "Secondary" },
{ "slug": "accent", "color": "#f59e0b", "name": "Accent" },
{ "slug": "base", "color": "#f8fafc", "name": "Base" },
{ "slug": "contrast", "color": "#0f172a", "name": "Contrast" },
{ "slug": "neutral-50", "color": "#fafafa", "name": "Neutral 50" },
{ "slug": "neutral-100", "color": "#f5f5f5", "name": "Neutral 100" },
{ "slug": "neutral-200", "color": "#e5e5e5", "name": "Neutral 200" },
{ "slug": "neutral-300", "color": "#d4d4d4", "name": "Neutral 300" },
{ "slug": "neutral-400", "color": "#a3a3a3", "name": "Neutral 400" },
{ "slug": "neutral-500", "color": "#737373", "name": "Neutral 500" },
{ "slug": "neutral-600", "color": "#525252", "name": "Neutral 600" },
{ "slug": "neutral-700", "color": "#404040", "name": "Neutral 700" },
{ "slug": "neutral-800", "color": "#262626", "name": "Neutral 800" },
{ "slug": "neutral-900", "color": "#171717", "name": "Neutral 900" }
]
}
}
}

关键: neutral 系列色值必须与 theme.json 完全一致,只改变品牌色。


原因四:HTML 属性与块注释不一致

根因

这是最隐蔽的问题。WordPress save 函数对生成的 HTML 有严格要求。

问题 4.1:class 顺序错误

WordPress 生成 class 的固定顺序:

has-border-color has-{slug}-border-color has-{slug}-background-color has-background

手写 HTML 时顺序错误会导致验证失败。

问题 4.2:背景色属性混用

背景色只能用 backgroundColor 属性,不可在 style.color.background 中声明:

<!-- 错误:混用导致 inline style 生成非法 CSS -->
<!-- wp:group {"style":{"color":{"background":"#f5f5f5"}}} -->

<!-- 正确 -->
<!-- wp:group {"backgroundColor":"neutral-100"} -->

问题 4.3:border style 属性顺序

border-width 必须在 border-style 之前:

<!-- 正确 -->
<div style="border-width:1px;border-style:solid;border-radius:8px;">

解决方案

最佳实践:从编辑器复制块代码,不要手写 HTML class 和 style。

  1. 在编辑器中配置好块
  2. 切换到代码编辑器视图
  3. 复制完整的块注释 + HTML
  4. 粘贴到 Pattern 文件

正确示例:

<!-- wp:group {"backgroundColor":"accent","borderColor":"neutral-200","style":{"border":{"radius":"8px","width":"1px","style":"solid"}}} -->
<div class="wp-block-group has-border-color has-neutral-200-border-color has-accent-background-color has-background" style="border-width:1px;border-style:solid;border-radius:8px;">
<!-- content -->
</div>
<!-- /wp:group -->

原因五:全局样式覆盖 theme.json

根因

Site Editor 保存的自定义样式存储在 wp_global_styles CPT 中,优先级高于 theme.json

修改 theme.json 后前端仍显示旧值,是因为全局样式覆盖了主题默认设置。

排查

# 检查是否存在全局样式
wp post list --post_type=wp_global_styles --fields=ID,post_title --allow-root

# 查看全局样式内容
wp post get <ID> --fields=post_content --allow-root

解决方案

# 删除全局样式
wp post delete <ID> --force --allow-root

# 清除缓存
wp cache flush --allow-root

预防: 开发阶段避免使用 Site Editor 自定义样式,所有配置通过 theme.json 管理。


排查流程总结

块验证失败

├─→ 检查颜色 slug 是否在 theme.json 中定义

├─→ 检查 JSON 是否有重复 key

├─→ 检查所有 Style Variation 是否包含完整调色板

├─→ 检查 HTML class/style 是否与块注释一致

└─→ 检查 wp_global_styles 是否覆盖了 theme.json

对类似需求感兴趣?联系合作