PublishPress Capabilities 与 Kakapo Roles 对比
权限插件表面上大同小异：一个矩阵，角色排成列，权限排成行。有意思的是它的左右两侧——也就是在单纯的权限之外还能控制什么，以及当没人在后台点击时规则是否依然有效。
简短的回答
PublishPress Capabilities 是一款扎实的角色与权限工具，可以免费上手，对自定义内容类型处理得很好，矩阵也清晰明了。补充功能则通过同一系列的其他插件提供。
Kakapo Roles 同样涵盖权限矩阵，此外还自带了通常要靠扩展才能实现的功能：后台菜单、媒体库、小工具、导航菜单、简码、登录后跳转——外加变更记录、角色回收站以及导出/导入。
两者的区别在哪里
| 问题 | PublishPress Capabilities | Kakapo Roles |
|---|---|---|
| 价格 | 免费，有 Pro 版本 | 付费插件，一个许可证涵盖九款 |
| 权限矩阵 | 是 | 是 |
| 在 REST API 中生效 | 需核实 | 明确强制执行 |
| 按角色设置后台菜单 | 需借助其他插件 | 内置 |
| 媒体库仅显示自己的文件 | 需借助其他插件 | 内置 |
| 小工具和导航菜单 | — | 内置 |
| 按角色设置简码 | — | 内置 |
| 角色回收站 | — | 可恢复 |
| 变更记录 | 取决于套餐 | 内置 |
| 导出和导入 | 取决于套餐 | 内置，可补充或替换 |
| 防止权限提升 | 需核实 | 遵循 get_editable_roles，多站点网络中同样如此 |
一分钟就能完成的测试
为某个特定角色保护一篇文章。退出登录。用文章中的一个词访问 /wp-json/wp/v2/posts?search=。如果响应中出现了该内容，说明规则只改变了视图——数据仍然是公开的。
这项测试适用于任何同类插件，包括你正在使用的那一款。Kakapo Roles 会在 REST API 中一并强制执行规则；对于其他工具，值得问个清楚，因为“隐藏”和“锁定”是两回事。
另外还要检查你的页面构建器。有些页面构建器通过自己的端点提供内容，而角色插件的权限检查覆盖不到这些端点。
权限之外还有什么要紧
权限矩阵回答的是一个人可以做什么。对于客户每天使用的后台来说，第二个问题同样重要：他能看到什么？一个面对十二个菜单项、其中十个被锁定的编辑，拥有的不是安全的后台，而是杂乱的后台。
- 按角色精简后台菜单，而不只是锁定菜单项
- 将媒体库限制为只显示自己的文件——否则每位作者都能看到每位客户的文件
- 隐藏与使用者无关的小工具和导航菜单
- 按角色允许使用简码，以免每个人都能随意嵌入任何内容
- 登录后直接跳转到开始工作的地方
在 Kakapo Roles 中，这些都是标配。而在大多数同类工具中，这需要单独的附加插件或 functions.php 中的代码片段——虽然可行，但下次更换主题时又会成为问题。
记录权限，而不只是设置权限
权限很少改动，而且通常是在时间紧迫时改：有人加入团队，有人离开，某个客户临时需要更多权限。半年后有人问起为什么某个角色能做某件事——没有记录的话，任何回答都只是猜测。
Kakapo Roles 提供变更记录和已删除角色的回收站。两者听起来都是小事，直到第一次有人删掉一个挂着二十个用户的角色。
权限结构一旦定型，就把它导出。这样它就是一个文件——可以备份、做版本管理、导入到下一个网站。没有导出，到第五个项目时你就得第五次搭建同样的结构，而且每次都会有些许不同。
何时 PublishPress Capabilities 是更好的选择
- 你需要的是权限矩阵，其他需求不多
- 预算为零
- 你已经在使用同一系列的其他插件
何时 Kakapo Roles 是更好的选择
- 你想为客户清理后台，而不只是设置权限
- 你需要一份权限变更记录
- 你想一次搭建好结构，再沿用到其他网站
- 你本来就在使用其他 Kakapo 插件