5.3 KiB
区块类型的更新传播
本文旨在为需要更新内容的用户提供指导，无论是更新主题模板、模式还是整个网站的区块。由于每种内容类型允许或禁止特定类型的同步，在创建前了解可能性的范围对简化未来维护至关重要。
更新管理建议
预先明确需要更新的内容
从宏观角度来看，需认识到并非所有内容都能在全站范围内更新，且创建方式会极大影响可操作性。因此，在创建前花时间确定需要更新的内容并将其置于合适的格式中至关重要。这将显著影响未来的维护效率。
拥抱区块级主题设计
区块主题设计需要从传统设计思维转变——不再局限于设计大版块并通过更新控制。虽然整体设计视角在创建自定义主题项目时仍然重要，但区块要求设计师以更原子化的方式进行设计。这意味着从区块本身出发，通常通过 theme.json 自定义实现。核心目标是让每个独立“原子”（即区块）可自由移动、编辑、删除和重组，而不会破坏整体设计。
越倾向于区块级设计，就越不需要在全站范围内向模式和模板等元素传播更新。只要原子化部件到位，其布局不应成为问题。
内容类型（及其正确更新方式）
区块
区块更新的管理方式取决于区块本身的性质。若区块依赖外部数据，建议从一开始就通过 render_callback 函数将其设为动态区块，这样能提供更多控制权。若区块结构预计会随时间变化，则推荐从使用 save() 方法定义默认输出的静态区块开始。后续可逐步采用混合方案，加入能使用 save 输出作为备选的 render_callback 以处理替代输出。需注意，这种灵活性和控制力是以渲染时的额外处理为代价的。另一种方案是使用依赖区块弃用机制管理更新的静态区块，但这需要手动更新现有区块。根据需求和使用习惯，两种方案皆可适用。若要快速开始创建区块，可使用 Create Block 工具。
模式
对于后续需要更新的内容，请勿使用模式，应改用可重用区块或模板部件。 模式插入站点后无法更新。可以将其理解为示例/样板/初始内容。虽然插入器中展示的模式会随时间演进，但这些变更不会自动应用到当前使用的模式实例上。一旦插入，模式就会与原始模式完全脱离（这点与可重用区块或模板部件区块不同）。
如需为自定义样式的模式设置解决方案，可考虑在包装区块中添加类名。例如以下代码为群组区块添加 themeslug-special 类：
<!-- wp:group {"className":"themeslug-special"} -->
<div class="wp-block-group themeslug-special">
<!-- 嵌套的模式区块 -->
</div>
<!-- /wp:group -->
这种方法并非万无一失，用户仍可通过编辑器界面修改类名。但由于该设置位于“高级”面板下，大多数情况下会保持原样。这为主题开发者提供了一定程度的CSS控制权，使其能更新现有使用实例，但无法阻止用户进行无法更新的重大修改。
同步模式
顾名思义，这类模式天然支持全站同步。需注意，依赖同步模式处理特定更新目前存在局限——更新时内容、HTML结构和样式将保持同步。若需要更精细的控制，这是需要考量的关键因素，此时动态区块可能是更优选择。
模板部件与模板
由于区块主题允许用户直接编辑模板和模板部件，管理变更的方式需根据用户更高权限进行调整。具体来说，当用户修改模板或模板部件后，主题更新提供的新模板将不会对已修改用户显示。只有新主题用户或未编辑过模板的用户会体验到更新后的模板。若用户未修改文件，您在文件系统中的变更将直接体现在用户站点上——只需更新文件即可生效。但若用户已修改模板，则更新其模板的唯一方式是：
- 回滚所有用户修改
- 更新数据库中的模板和模板部件
一般而言，若用户已修改模板，建议维持现状（除非在代理场景中与用户达成共识）。
更新模板时需注意对新增或不同模板部件的引用。例如 page.html 模板在1.0版本中引用 parts/header.html，而在2.0版本中改为引用 parts/header-alt.html。某些开发者可能将此视为用户修改原 header.html 时的“解决方案”，但这很可能破坏用户的定制设计，因为 page.html 模板将不再引用正确部件（除非用户也修改并保存了页面模板）。
同样地，在主题更新中删除模板部件通常不可取。这种情况下，用户可能创建了引用该部件的自定义顶层模板，并预期其持续存在。