客户端JavaScript修改的挑战
在wordpress区块编辑器中，开发者有时需要根据主题或特定需求，动态调整编辑器的默认设置，例如允许的区块类型。一种常见的尝试是使用客户端javascript来监听编辑器状态变化，并在适当的时机修改设置。然而，这种方法往往面临时序问题，尤其是在编辑器加载过程中。
考虑以下使用JavaScript尝试修改allowedBlockTypes的示例：
async function blockEditorSubHandler() {
console.log("callback fired")
if (!select(blockEditor).getBlocks().length) return
if (!wp.data.select("core/block-editor").getSettings().allowedBlockTypes.includes("foo")) {
await dispatch(blockEditor).updateSettings({ allowedBlockTypes: ["foo"] })
console.log("passed")
}
}
subscribe(blockEditorSubHandler, "core/block-editor")上述代码尝试通过订阅core/block-editor的状态变化，在设置尚未包含“foo”区块类型时，将其添加到允许列表中。然而，实际操作中会发现，在编辑器完全加载并稳定之前，subscribe回调可能会被多次触发。这意味着设置可能在不完全加载的状态下被多次检查和修改，导致：
- 效率低下： 重复执行不必要的检查和更新操作。
- 时序问题： 尽管最终设置可能被正确应用，但由于多次异步操作，用户可能无法在编辑器加载伊始就看到期望的设置，或者在加载过程中出现短暂的配置不一致。
- 复杂性增加： 需要额外的逻辑来判断何时是“最终”的加载完成状态，增加了代码的复杂性和出错的可能性。
这种客户端修改的根本问题在于，JavaScript在浏览器中执行，而区块编辑器的初始设置是在服务器端生成并发送到客户端的。在编辑器初始化和渲染过程中，其状态会经历多次变化，导致监听器被频繁触发。
推荐方案：利用PHP过滤器预设编辑器设置
为了避免客户端JavaScript修改可能带来的时序和效率问题，最可靠且推荐的方法是在服务器端，通过PHP过滤器来预先配置区块编辑器的设置。WordPress提供了一个强大的过滤器block_editor_settings_all，允许开发者在编辑器设置被发送到浏览器之前对其进行修改。
立即学习“PHP免费学习笔记（深入）”；
block_editor_settings_all过滤器在区块编辑器初始化时执行，它接收两个参数：$editor_settings（当前编辑器设置数组）和$editor_context（编辑器上下文，包含例如文章类型等信息）。通过这个过滤器，我们可以直接修改allowedBlockTypes或其他任何编辑器设置，确保这些修改在编辑器加载到客户端时即刻生效。
以下是使用block_editor_settings_all过滤器来允许“foo”区块类型的PHP代码示例：
/**
* 允许在区块编辑器中使用 'foo' 区块类型。
*
* @param array $editor_settings 区块编辑器的所有设置。
* @param WP_Block_Editor_Context $editor_context 编辑器上下文。
* @return array 修改后的区块编辑器设置。
*/
function so_76324559_allow_foo( $editor_settings, $editor_context ) {
// 可以在此处添加额外的检查，例如根据 $editor_context 来判断是否应用此设置
// 例如：if ( 'post' === $editor_context->post_type ) { ... }
// 直接设置允许的区块类型数组，如果 'foo' 是唯一允许的，则替换整个数组。
// 如果需要保留现有允许的区块并添加 'foo'，则应合并数组。
$editor_settings['allowedBlockTypes'] = ['foo'];
return $editor_settings;
}
add_filter( 'block_editor_settings_all', 'so_76324559_allow_foo', 10, 2 );将上述PHP代码添加到主题的functions.php文件或自定义插件中，即可实现：
- 即时生效： 当区块编辑器加载时，allowedBlockTypes将立即显示为["foo"]。通过浏览器控制台运行wp.data.select('core/block-editor').getSettings().allowedBlockTypes，会发现结果立即是["foo"]。
- 避免时序问题： 由于设置是在服务器端完成的，不存在客户端异步加载和状态变化带来的时序不确定性。
- 性能优化： 避免了客户端不必要的监听和多次更新操作。
- 清晰的逻辑： 设置逻辑集中在服务器端，更易于管理和维护。
注意事项与最佳实践
- 条件判断： 在so_76324559_allow_foo函数内部，可以根据$editor_context参数进行更精细的控制。例如，只在特定文章类型或模板下应用这些设置。
-
合并而非替换： 如果目标是添加特定的区块类型而不是完全替换所有允许的区块类型，应该将'foo'合并到现有的$editor_settings['allowedBlockTypes']数组中，而不是直接覆盖它。例如：
if ( is_array( $editor_settings['allowedBlockTypes'] ) ) { $editor_settings['allowedBlockTypes'][] = 'foo'; $editor_settings['allowedBlockTypes'] = array_unique( $editor_settings['allowedBlockTypes'] ); // 避免重复 } else { $editor_settings['allowedBlockTypes'] = ['foo']; } - 优先级： add_filter函数的第三个参数是优先级。默认是10。如果需要确保你的修改在其他插件或主题之后执行，可以设置一个更高的优先级数字。
- 适用场景： block_editor_settings_all过滤器主要用于在编辑器加载时进行初始配置。对于用户在编辑器内部进行交互后产生的动态设置变化（例如，根据用户操作切换某个区块的可用性），仍然可能需要结合客户端JavaScript来实现。
总结
在WordPress区块编辑器中修改主题提供的设置时，优先考虑使用PHP的block_editor_settings_all过滤器。这种服务器端的方法能够确保设置在编辑器加载时即刻生效，有效避免了客户端JavaScript异步操作可能带来的时序问题和复杂性。它提供了一种更稳定、高效且易于维护的解决方案，是配置区块编辑器初始行为的最佳实践。
