User Role Editor 替代方案：切换前要问的五个问题
寻找权限插件替代方案的人，大多并没有遇到错误，而是发现了漏洞：客户看到了与他无关的菜单项；一篇受保护的文章还是在某处露了出来；或者再也说不清谁在何时获得了哪项权限。五个问题能把这些理清楚。
问题 1：离开后台，规则依然有效吗？
这是最重要的问题，而且你自己一分钟就能回答。保护一篇文章，使其只对某个特定角色可见。退出登录。用这篇文章中的一个词访问 /wp-json/wp/v2/posts?search=。
如果响应中出现了该内容，说明你的规则只改变了视图。WordPress 的 REST API 默认可以访问，而且它查询的代码位置与后台的文章列表不同。Kakapo Roles 在那里明确地一并强制执行可见性规则——正因如此，这项测试是评判权限插件最快的方法。
在切换之前，也用你正在使用的插件做一下这项测试。有时漏洞在别处——比如某个通过自有端点提供内容的页面构建器。
问题 2：有人能给自己更多权限吗？
一款权限插件如果允许任何能访问其界面的人提升自己的角色，就违背了它存在的目的。WordPress 为此设有一个钩子——get_editable_roles()——它决定了一个人究竟可以编辑哪些角色。要问替代方案的问题是：它是否在每一处都遵循这个钩子？
在多站点网络中，还有第二道边界：在那里，角色有一部分是全网络共用的。从某个子站点覆盖它们的人，会改变整个网络中所有站点上的角色——包括那些不归他管的站点。
问题 3：能清理后台吗？
权限规定的是一个人“可以做”什么。对客户来说，他“能看到”什么同样重要。一个面前摆着十二个菜单项、其中十个被锁定的编辑，拥有的不是安全的后台，而是杂乱的后台。
因此要检查替代方案是否超越了角色和权限：按角色设置后台菜单、将媒体库限制为只显示自己的文件、小工具和导航菜单、允许使用的简码、登录后跳转。Kakapo Roles 内置了这些功能——而在许多同类插件中，这些需要单独的扩展或代码片段。
问题 4：能查到改动了什么吗？
权限很少改动，而且通常是在时间紧迫时改。半年后有人问起为什么某个角色能做某件事。没有记录的话，答案就只是猜测。
要问替代方案的问题：是否有变更记录，其中是否写明了“谁”在“何时”获得或失去了“哪项”权限？Kakapo Roles 提供变更记录，而且连通过分配和迁移产生的改动也会记录在内。
问题 5：必须在每个网站上重新搭建吗？
管理多个安装的人，会多次搭建同样的权限结构——而且每次都会有些许偏差。一年之后，五个网站就成了五个特例。因此要检查结构能否导出和导入，以及导入时现有角色会怎样：补充还是替换？
Kakapo Roles 两种方式都支持，并会在导入前说明选择的是哪一种。“替换”（德语：„Ersetzen“）是更危险的那一种——因此必须明确确认。
简版清单
| 标准 | 为何重要 | Kakapo Roles 的情况 |
|---|---|---|
| 在 REST API 中生效 | 否则规则只保护了视图 | 明确强制执行 |
| 防止权限提升 | 否则插件就等于自我否定 | 遵循 get_editable_roles，多站点网络中同样如此 |
| 清理后台 | 客户应当只看到与他相关的内容 | 后台菜单、媒体库、小工具、导航菜单、简码 |
| 按角色设置登录后跳转 | 客户直接进入自己工作的地方 | 内置 |
| 角色回收站 | 删除角色这种事，很少是从容不迫地完成的 | 可恢复 |
| 变更记录 | 半年之后，有据可查才算数 | 谁、何时、哪项权限 |
| 可沿用到其他网站 | 否则每个网站都会成为特例 | 导出和导入，补充或替换 |
| 一个许可证管理多个网站 | 一张账单代替五张 | 九款插件，一个账号 |
切换前你应该做什么
- 记录现状——现有哪些自定义角色，以及各自附带哪些权限。
- 做一次备份。权限存放在数据库中，一次失误会同时波及所有用户。
- 在新插件中重建该结构，并逐行进行对比。
- 为每个角色使用一个测试用户登录，查看该用户实际能看到什么。
- 进行问题 1 中的 REST 测试。
- 停用旧插件而不是删除它——保留两周。
同时使用的两款权限插件会写入相同的角色，谁最后保存，谁就说了算。在过渡期间，只在其中一款中进行改动。