理解区块编辑器设置加载的挑战
在wordpress区块编辑器中，开发者经常需要根据主题或插件的需求，动态调整编辑器的行为，例如限制允许使用的区块类型（allowedblocktypes）。一个常见的场景是，我们希望在编辑器加载完成后，立即应用这些自定义设置，以确保用户体验的一致性。
然而，当尝试使用JavaScript在客户端（浏览器）修改这些设置时，会遇到一个棘手的时序问题。区块编辑器的加载过程是异步的，涉及到多个状态更新。如果使用wp.data.subscribe监听状态变化来触发设置修改，可能会发现回调函数在设置完全加载之前被多次调用，导致代码逻辑复杂且难以精确控制修改的时机。
例如，以下JavaScript代码片段尝试在区块编辑器加载时修改allowedBlockTypes：
async function blockEditorSubHandler() {
console.log("callback fired")
// 检查是否有区块，避免在编辑器完全加载前操作
if (!select(blockEditor).getBlocks().length) return
// 如果 "foo" 不在允许的区块类型中，则添加
if (!wp.data.select("core/block-editor").getSettings().allowedBlockTypes.includes("foo")) {
await dispatch(blockEditor).updateSettings({ allowedBlockTypes: ["foo"] })
console.log("passed")
}
}
// 订阅 core/block-editor 存储的状态变化
subscribe(blockEditorSubHandler, "core/block-editor")这段代码的问题在于，subscribe回调可能会在编辑器加载过程中被触发多次。即使最终设置被正确应用，但这种多余的执行和对异步操作的依赖，使得代码不够健壮，且设置的实际生效时间可能比预期晚。开发者需要精确判断何时“所有”主题设置都已加载完毕，这在异步环境中是一个挑战。
推荐方案：使用PHP block_editor_settings_all 过滤器
为了避免JavaScript客户端修改带来的异步加载和时序问题，最推荐且最可靠的方法是在服务器端使用PHP的block_editor_settings_all过滤器。这个过滤器允许我们在区块编辑器设置被发送到前端（浏览器）之前，对其进行拦截和修改。这意味着，当编辑器加载时，它接收到的设置已经是我们修改过的版本，无需任何客户端的异步操作。
过滤器的工作原理
block_editor_settings_all过滤器接收两个参数：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- $editor_settings：一个关联数组，包含所有将传递给区块编辑器的设置。
- $editor_context：一个包含编辑器上下文信息的关联数组，例如当前编辑的帖子类型等。
通过修改$editor_settings数组，我们可以直接更改编辑器的默认行为。
示例代码：使用PHP修改允许的区块类型
假设我们希望将允许的区块类型限制为只包含名为 "foo" 的区块，可以在主题的 functions.php 文件或自定义插件中添加以下PHP代码：
<?php
/**
* 使用 block_editor_settings_all 过滤器修改区块编辑器设置。
*
* @param array $editor_settings 传递给区块编辑器的设置数组。
* @param WP_Block_Editor_Context $editor_context 区块编辑器的上下文信息。
* @return array 修改后的设置数组。
*/
function so_76324559_allow_foo( $editor_settings, $editor_context ) {
// 可以在此处添加条件判断，例如根据 $editor_context->post->post_type
// 来决定是否应用这些设置。
//
// 如果您只想添加 "foo" 而不是替换所有允许的区块类型，
// 可以先获取现有设置，然后合并或修改：
// if ( ! in_array( 'foo', $editor_settings['allowedBlockTypes'] ) ) {
// $editor_settings['allowedBlockTypes'][] = 'foo';
// }
// 此处示例是直接替换所有允许的区块类型为 'foo'
$editor_settings['allowedBlockTypes'] = ['foo'];
return $editor_settings;
}
// 注册过滤器，优先级为10，接受2个参数
add_filter( 'block_editor_settings_all', 'so_76324559_allow_foo', 10, 2 );代码解析与注意事项
- 函数定义：so_76324559_allow_foo 是一个自定义函数，用于处理过滤逻辑。它接收 $editor_settings 和 $editor_context 作为参数。
- 修改设置：在函数内部，我们直接修改 $editor_settings['allowedBlockTypes'] 的值。在这个例子中，我们将其设置为只包含 'foo'。
- 条件判断：在实际应用中，您可能不希望无条件地替换所有允许的区块类型。例如，您可能只想为特定的文章类型（$editor_context->post->post_type）应用此限制。在这种情况下，您应该在修改前添加条件判断。如果只是想在现有允许的区块类型中添加一个新类型，而不是完全替换，则需要先获取现有数组，然后进行合并或追加操作。
- 注册过滤器：add_filter( 'block_editor_settings_all', 'so_76324559_allow_foo', 10, 2 ); 将我们的函数挂载到 block_editor_settings_all 过滤器上。10 是优先级（数字越小越早执行），2 表示我们的函数接受两个参数。
验证结果
应用上述PHP代码后，当您在浏览器控制台中运行 wp.data.select('core/block-editor').getSettings().allowedBlockTypes 时，会立即看到 ["foo"] 作为结果，这证明设置已在编辑器加载之初就已生效。
总结
对于在WordPress区块编辑器加载时需要修改其初始设置的场景，使用PHP的block_editor_settings_all过滤器是最佳实践。它通过在服务器端预处理设置，确保了设置的即时可用性和一致性，避免了客户端JavaScript异步加载可能带来的复杂性和不确定性。虽然JavaScript在编辑器加载后进行动态交互和修改仍有其用武之地，但对于初始配置，PHP过滤器提供了更可靠、更高效的解决方案。
