必须同时正确设置wp_capabilities和wp_user_level两条记录，且wp_capabilities需为合法序列化字符串，否则会导致权限异常、菜单错乱或登录跳转；推荐用update_user_meta()而非手动SQL操作。

直接改 wp_usermeta 表能加管理员权限，但必须同时写对两条记录

不能只改一条 wp_capabilities 就完事。wordpress 判断用户角色时，会检查两个 meta_key：一个是 wp_capabilities，另一个是 wp_user_level（虽已废弃但部分插件或旧主题仍会读取）。漏掉任意一个，可能导致后台菜单错乱、某些管理功能不可用，甚至登录后立即跳转回登录页。

实操建议：

• wp_capabilities 的值必须是序列化数组字符串，例如 a:1:{s:13:"administrator";b:1;}，不能手写 JSON 或 PHP 数组语法
• wp_user_level 建议设为 10（对应管理员），避免兼容性问题
• 表前缀不一定是 wp_，请先查 $table_prefix 配置，比如可能是 myblog_，对应字段就是 myblog_capabilities
• 操作前务必备份 wp_usermeta 表，误写序列化字符串会导致该用户无法登录

用 update_user_meta() 比手动 SQL 更安全

直接执行 SQL 容易因序列化格式错误导致用户元数据损坏；而 update_user_meta() 会自动处理序列化，且触发相关 action 钩子（如 added_user_meta），降低后续权限逻辑异常风险。

常见错误现象：用 phpMyAdmin 手动更新后，用户能进后台但看不到「仪表盘」或「设置」菜单——大概率是 wp_capabilities 字符串反序列化失败。

实操建议：

• 在主题的 functions.php 或临时插件中运行一次即可：

  update_user_meta(123, 'wp_capabilities', array('administrator' => true));

  （把 123 换成目标用户的 ID）
• 接着补上 user_level：

  update_user_meta(123, 'wp_user_level', 10);

• 执行完立刻删掉这段代码，避免重复运行覆盖其他角色
• 不要在 init 钩子中无条件调用，否则每次请求都重写，影响性能

为什么改了权限却没生效？检查用户是否被其他插件锁定

有些安全插件（如 Wordfence、iThemes Security）或多站点配置会主动拦截或覆盖角色变更。即使数据库里写对了，前端也可能显示“您没有权限访问此页面”。

使用场景：你确认 wp_capabilities 值正确、也刷新了缓存，但用户登录后仍只有编辑者权限。

实操建议：

• 临时停用所有安全类插件，再测试是否生效
• 检查是否启用了「强制角色同步」类插件（如 Members 插件勾选了 “Lock roles”）
• 查看 wp_options 表中是否有 wp_roles 选项被篡改（极少见，但发生过）
• 用 WP-CLI 快速验证：wp user get 123 --field=roles，它绕过插件钩子，直接读数据库值

别忽略缓存和对象缓存的影响

WP-CLI 或数据库改完后，用户可能仍看到旧权限，不是数据库没改对，而是 WordPress 把用户角色缓存在内存或 Redis/Memcached 里了。

性能影响：对象缓存未失效时，current_user_can() 等函数返回的仍是旧结果，持续几分钟甚至更久。

实操建议：

• 如果是本地开发环境（无持久化对象缓存），只需清空浏览器 Cookie 并登出重登
• 如果启用了 Redis/Memcached，执行 wp cache flush（WP-CLI）或联系主机商清空对象缓存
• 不要依赖「禁用插件→改库→启用插件」这种流程，插件激活时可能重新同步角色，覆盖你的修改

事情说清了就结束。最常踩的坑是：以为改了 wp_capabilities 就够了，结果 wp_user_level 没同步，或者序列化字符串手写错了，然后花半天排查权限逻辑。