找到出问题的插件目录名（看错误日志或者凭记忆）

用WP-CLI把WordPress主题开发中的“鬼问题”逐个击破**

我盯着屏幕上那个只渲染出半截导航栏的页面,手指在键盘上敲出wp theme list --status=inactive，然后叹了口气，这是本周第三个“安装后样式全乱”的主题了，作为靠WP-CLI吃饭的WordPress开发者，我早就学会不跟浏览器斗气——直接钻进数据库和文件系统里解决问题。

主题安装后样式错乱，怎么定位罪魁祸首？

找到出问题的插件目录名（看错误日志或者凭记忆）

场景：我刚上传了一个从GitHub拉下来的主题，启用后首页头图变成全屏拉伸，字体惨不忍睹，这不是主题本身的bug，八成是缓存或者数据库里的旧选项在作祟。

排查步骤：

先强制刷新缓存：wp cache flush，如果用了对象缓存插件，再执行wp redis flush或wp memcached flush。
检查主题是否激活了错误的自定义izer值：wp option get stylesheet和wp option get template，确认两个选项都指向当前主题。
如果主题自带customize设置，但样式依旧错乱，直接暴力重建默认值：
```
wp option delete theme_mods_你的主题slug
wp option delete mods_你的主题slug
```
然后重新加载页面,如果正常了，说明是旧配置残留，如果还乱，看下一步。

插件激活后网站直接白屏，怎么用命令救回来？

场景：我刚才激活了“超级页面构建器Pro”，然后整个站点变成纯白，别慌，这是典型的插件致命错误，WP-CLI在这里是你的救命稻草。

操作：

如果不知道是哪个插件,就全部禁用再逐个启用：

wp plugin deactivate --all
wp plugin activate --all --skip-plugins

如果白屏依旧,检查wp-config.php里是否开了WP_DEBUG，然后看debug.log，大多数时候，问题出在插件调用了不存在的函数或类，

if ( ! function_exists( 'some_function' ) ) {
    // 用函数存在性检查包裹
}

修复方法是找到插件主文件,用defined('ABSPATH') || exit;包裹开头，并注释掉可疑的require或include。

古腾堡编辑器兼容性——为什么块加载不出样式？

我最近在开发一个块主题,客户反馈“编辑器里块排列正常，前端全成堆叠”，这通常是块样式未被正确排队，用WP-CLI检查：

wp block show my-block/hero --fields=render,style

如果输出显示style为空，说明你的块注册时没指定style_handles，修复代码，在你的块注册函数里：

register_block_type( __DIR__ . '/build', array(
    'style' => 'my-block-style', // 确保前面已用wp_register_style注册
) );

还要清一下编译缓存：wp block regenerate --all，如果编辑器里正常，但前台没加载，检查wp_enqueue_style是否被误加条件判断。

页面构建器插件冲突——Elementor和我的自定义meta盒干架

最烦的是这俩,一个写入_elementor_data，一个用add_meta_box存自定义字段，冲突结果：页面内容被覆盖或显示双重内容。

检测：

wp post get 123 --field=meta --format=json | grep -i elementor
wp post get 123 --field=meta --format=json | grep -i my_custom_field

如果都有值,那就写个过滤器，让构建器不输出我的meta：

add_filter( 'elementor/frontend/section/should_render', function( $should_render, $element ) {
    if ( get_post_meta( $element->get_id(), 'my_hide_from_elementor', true ) ) return false;
    return $should_render;
}, 10, 2 );

或者干脆用wp post meta update 123 my_hide_from_elementor 1紧急隐藏。

子主题创建与修改——别再把父主题当试验田

我见过太多人直接改父主题的functions.php，正确做法用WP-CLI生成子主题：

wp scaffold child-theme my-theme-child --parent_theme=my-theme --theme_name="My Child" --author="Me"

然后修改子主题的style.css（记得Template: my-theme必须写对），更关键的是，子主题里覆写父主题的钩子要小心：

// 在子主题的functions.php里，用优先级覆盖
add_action( 'init', 'override_parent_behavior', 20 );
function override_parent_behavior() {
    remove_action( 'init', 'parent_theme_setup' ); // 先移除
    // 再添加自己的
}

用wp eval 'do_action("init");'测试钩子是否正常触发。

常用函数调用报错——比如get_field未定义

这个太常见了,你启用了ACF，但某个模板里直接调用get_field()导致致命错误，用WP-CLI检查函数存在性：

wp eval 'var_dump( function_exists( "get_field" ) );'

如果返回false,说明ACF没加载，修复方式：

// 用条件包裹
if ( function_exists( 'get_field' ) ) {
    $value = get_field( 'something', $post_id );
} else {
    // 回退到默认文章meta
    $value = get_post_meta( $post_id, 'something', true );
}

更保险的,在主题functions.php里定义兜底函数：

if ( ! function_exists( 'get_field' ) ) {
    function get_field( $field, $post_id = false ) {
        return get_post_meta( $post_id ?: get_the_ID(), $field, true );
    }
}

用wp eval 'echo get_field("test", 1);'验证。

最后记住,当你像热锅上的蚂蚁时，WP-CLI就是你的手术刀——别怕删除选项或禁用插件，数据库备份在wp db export里躺着呢，把这些命令练熟，那些“鬼问题”其实都是逻辑和顺序的产物。

正文

找到出问题的插件目录名（看错误日志或者凭记忆）

相关阅读

发表评论取消回复

目录[+]