Members 与 Kakapo Roles 对比：管理真正靠得住的权限

衡量一款权限插件只看一个问题：即使没有人在后台点来点去，这项权限是否依然有效？许多名为“隐藏”的功能只改变了视图——数据依然公开，只差一次 REST API 调用。本次对比就按这一点来梳理 Members 和 Kakapo Roles。

简短的回答

Members 是一款成熟的免费权限插件：创建和编辑角色、分配权限、按角色保护内容。它轻量、普及，足以应付大多数简单场景。

Kakapo Roles 从更深一层入手。它不仅管理角色和权限，还管理用户在后台究竟能看到什么——后台菜单、媒体库、小工具、简码——并且明确地在 REST API 中同样强制执行可见性规则。此外还有变更记录、已删除角色的回收站以及导入/导出。

简而言之：只想创建角色、保护内容的人，用 Members 就能走得很远，而且分文不花。想给客户一个整洁的后台、以可追溯的方式记录权限，或者想避免规则只作用于界面的人，选 Kakapo Roles 更合适。

两者都能做到的

• 创建、重命名和删除自定义角色
• 按角色设置权限，包括自定义内容类型的权限
• 为单个用户额外授予或撤销权限
• 将内容限制为仅特定角色可见
• 每位用户多个角色

到这里为止，选哪个都只是个人偏好。再往下才有意思。

两者的区别在哪里

真正要紧的区别：隐藏不等于锁定

如果一篇文章应当“仅对特定角色”可见，有两种实现方式。一种是在列表和前台中将其隐藏。另一种是拒绝访问——在任何地方，包括没人点击的地方。

这一区别绝非细枝末节。WordPress 的 REST API 默认可以访问；调用 /wp-json/wp/v2/posts 无需登录即可获得 JSON 格式的文章。只改变视图的规则在那里毫无作用——原本“仅限会员”的内容，会以明文形式出现在响应中。

因此，Kakapo Roles 在 REST API 中同样强制执行可见性规则。正是这一点，让权限插件变得可以检验：在退出登录的状态下，以 JSON 形式访问一次你受保护的地址。如果内容出现在那里，这条规则就什么也没保护。

这项测试适用于任何插件，包括你正在使用的那一款：保护一篇文章，退出登录，访问 /wp-json/wp/v2/posts?search=…。只需一分钟，它能回答的问题比任何功能清单都多。

第二个陷阱：谁可以分配权限？

一款权限插件如果允许任何能访问其界面的人给自己更多权限，就等于自我否定。WordPress 为此设有一个钩子：get_editable_roles() 决定了一个人究竟可以编辑哪些角色。绕过它的插件，恰恰打开了它本应关闭的那条路。

在多站点网络中，还多了一个问题：在那里，角色有一部分是全网络共用的。从某个子站点覆盖它们的人，会改变所有站点上的角色。Kakapo Roles 两者都会顾及——这个钩子，以及站点与网络之间的边界。

何时 Members 是更好的选择

• 你只需要角色和权限，别的都不需要
• 预算为零
• 你只管理一个网站，用户也不多
• 你想要一款只专注做一件事的插件

何时 Kakapo Roles 是更好的选择

• 你要把后台交给客户，并希望把它清理干净——菜单、媒体库、小工具
• 受保护的内容通过 REST API 访问时也应受到保护
• 你必须能够证明谁在何时获得了哪项权限
• 你想一次搭建好权限结构，再沿用到其他网站
• 你本来就在使用其他 Kakapo 插件，希望只付一张账单而不是五张

切换：需要做什么

1. 记下现有哪些自定义角色以及各自附带哪些权限——截一张权限矩阵的图就够了。
2. 做一次备份。权限存放在数据库中，一次失误会同时波及所有用户。
3. 安装 Kakapo Roles 并填入许可证密钥。
4. 重建这些角色，并将权限矩阵与你的记录逐行对比。
5. 为每个角色使用一个测试用户登录，查看该用户实际能看到什么。
6. 对一项受保护的内容进行 REST 测试。
7. 在此之后再停用旧插件——不要删除，保留两周。

同时使用两款权限插件是一种糟糕的状态：两者会写入相同的角色，谁最后保存，谁就说了算。尽量缩短过渡期，并且在此期间只在其中一款中进行改动。

常见问题