Adminimize 精简 WordPress 后台：按角色隐藏菜单、元框与字段

引言：后台太复杂，客户只会用”添加文章”

WordPress 后台对开发者来说是熟门熟路，对客户来说是一屏陌生的英文菜单：文章、媒体、页面、评论、外观、插件、用户、工具、设置，再加上 SEO 插件、表单插件、缓存插件各挂几个菜单，一共二十多个入口。客户真正要用的往往只有两三个。

后果是两类：要么客户不敢点，什么都来找你；要么客户乱点，改了主题设置、停了插件，然后说”网站自己坏了”。

精简后台的思路有两条：一是权限层面收口，让客户根本没有能力改（那是 User Role Editor 权限控制 的事）；二是界面层面收口，把用不到的入口藏掉，降低认知负担。Adminimize 做的是第二件事，而且做得很彻底——它能按角色分别控制主菜单、子菜单、仪表盘小工具、编辑页元框、甚至发布框里的单个字段。

原理分析：后台界面由哪些”挂载点”组成

要理解 Adminimize 的能力边界，得先看后台界面是怎么拼出来的：

Adminimize 的本质是在 admin_menu、admin_init、do_meta_boxes 等钩子上，按当前用户角色批量执行这些”移除”函数。它提供了图形界面，让你勾选”某个角色看不看某个菜单”，并把配置存进 wp_options。

这里有一条必须记住的安全边界：隐藏 ≠ 禁止。 菜单没了，URL 还在；客户如果知道 /wp-admin/options-general.php，照样能打开设置页。所以 Adminimize 只能用来降低误操作概率，不能用来做权限隔离。真正的安全控制必须在能力（capability）层面完成。

保姆级实操

第一步：规划”每个角色该看到什么”

动手前先列一张表，别边点边想：

第二步：配置 Adminimize 的菜单选项

后台「设置 → Adminimize」，进入后是按区域分块的配置区：

• Menu Options：主菜单，每个菜单项后面是一排角色复选框（Administrator / Editor / Author / Contributor / Subscriber），勾选表示”隐藏”；
• Submenu Options：子菜单，粒度更细，例如保留”设置”但隐藏其中的”常规”与”permalink”；
• Global Options：全局开关，例如是否显示”屏幕选项”、是否显示管理员栏的部分节点。

配置完点「Update Options」。注意它是按角色而非按用户配置的，所以要先把角色体系定好。

第三步：精简文章编辑页的元框

Adminimize 提供 Metabox Options 区域，可以选择在 post / page / 自定义类型的编辑页上隐藏哪些元框（如”自定义字段””讨论””引用通知””修订版本”）。

如果只想对部分角色隐藏，用代码更灵活：

add_action( 'add_meta_boxes', function () {
    if ( current_user_can( 'manage_options' ) ) {
        return;   // 管理员看全部
    }
    $post_types = array( 'post', 'page', 'product' );
    foreach ( $post_types as $pt ) {
        remove_meta_box( 'postcustom',    $pt, 'normal' );   // 自定义字段
        remove_meta_box( 'commentsdiv',   $pt, 'normal' );   // 评论
        remove_meta_box( 'trackbacksdiv', $pt, 'normal' );   // 引用通知
        remove_meta_box( 'slugdiv',       $pt, 'normal' );   // 别名
        remove_meta_box( 'authordiv',     $pt, 'normal' );   // 作者
    }
}, 99 );

第四步：按角色收掉菜单与工具栏

add_action( 'admin_menu', function () {
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }
    remove_menu_page( 'tools.php' );
    remove_menu_page( 'options-general.php' );
    remove_menu_page( 'themes.php' );
    remove_menu_page( 'plugins.php' );
    remove_menu_page( 'users.php' );
    remove_submenu_page( 'themes.php', 'customize.php' );
    remove_submenu_page( 'options-general.php', 'options-permalink.php' );
}, 999 );

add_action( 'admin_bar_menu', function ( $wp_admin_bar ) {
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }
    $wp_admin_bar->remove_node( 'customize' );
    $wp_admin_bar->remove_node( 'updates' );
    $wp_admin_bar->remove_node( 'new-content' );
}, 999 );

第五步：去掉屏幕选项与帮助标签

这两个区域对客户毫无用处，却经常带来”为什么我的页面少了一列”的疑问：

add_filter( 'screen_options_show_screen', '__return_false' );
add_filter( 'contextual_help', function ( $help ) {
    return '';
} );

第六步：导出配置，避免重装丢失

Adminimize 界面底部提供配置的导入/导出（Im-/Export），把配置以序列化字符串或文件保存下来。重装站点时贴回去即可，省得重新勾几百个复选框。更稳的做法是把稳定的隐藏规则写成代码（如上面几段），界面只用来做临时试验。

常见踩坑

1. 把自己也锁住了。 配置时用的是管理员账号，如果顺手把”设置”和”插件”对管理员也勾了隐藏，就看不到 Adminimize 的入口了。补救办法是直接访问 /wp-admin/options-general.php?page=adminimize 或改数据库。
2. 隐藏了菜单但客户仍能通过 URL 访问。 前面说过，隐藏不是权限。想真正挡住，必须收回对应的 capability。
3. 插件更新后菜单 slug 变了，规则失效。 例如某些插件改版后菜单从 edit.php?post_type=x 变成别的，规则要同步更新。
4. 隐藏了”自定义字段”元框，客户以为字段丢了。 如果站点用 ACF，字段组有自己的元框，隐藏原生的”自定义字段”是正确的，但要提前跟客户说明。
5. 多语言插件的菜单被误藏，导致客户切不了语言。建议把多语言切换放到前台，而不是依赖后台。
6. 配置保存在 options 里，重装站点全丢。 一定要导出，或写成代码。
7. 案例： 某站给”编辑”角色用 Adminimize 隐藏了”外观”与”插件”，以为万事大吉。后来编辑在浏览器地址栏里直接输入了 /wp-admin/themes.php（从同事那儿抄来的链接），发现居然能打开并切换主题，站点前台当场错乱。补救方案是在能力层面把 edit_theme_options、switch_themes、activate_plugins 从该角色移除。教训：界面精简用来”防呆”，权限控制用来”防人”，两者必须叠加，不能互相替代。

总结

Adminimize 的正确定位是”界面减负工具”：把每个角色不需要的菜单、子菜单、元框、字段收掉，让客户打开后台就能直奔目标。配置顺序建议：先规划角色清单 → 再配菜单与子菜单 → 再配元框 → 最后补屏幕选项与工具栏节点。

三条纪律：管理员永远保留全部；稳定的规则写成代码进版本控制，临时的用界面；任何涉及安全的收口都不要指望它，权限部分交给能力体系。配合 User Role Editor 与 Members 权限控制 做双层收口，效果最好；如果站点还要跑多人协作的审核流程，可以再叠一层 PublishPress 内容审核流程。