Roles
后台客户账号：真正需要哪些权限
客户需要能够维护文本。最快的办法是给一个管理员账号——也是代价最高的办法。并不是因为有人会使坏，而是因为在插件区域的一次误点，代价远超建立一个规范角色所需的那十分钟。
WordPress 自带的角色
| 角色 | 可以做 | 适合谁 |
|---|---|---|
| 贡献者 | 撰写自己的文章，但不能发布 | 客座作者 |
| 作者 | 撰写并发布自己的文章 | 个别撰稿人 |
| 编辑 | 所有文章和页面，包括他人的 | 大多数客户 |
| 管理员 | 一切，包括插件和用户 | 你自己 |
在大多数情况下，编辑是正确的答案。这个角色完整覆盖内容，又把技术层面排除在外。
编辑角色仍会碰壁的地方
编辑经常缺少三样东西，而每一样都有比“那就给管理员吧”更好的解决办法：
- 编辑菜单——需要一项通常归管理员所有、但可以有针对性地授予的权限
- 使用页面构建器——许多页面构建器自带可单独分配的权限
- 管理表单或商店——相应的插件同样为此定义了各自的权限
办法始终如一：补上缺少的那一项权限，而不是更换角色。权限矩阵正是为此而设的。
清理比锁定更重要
一个有十二个菜单项、其中十个被锁定的后台，并不安全，只是杂乱。客户四处寻找、点错地方，然后打电话求助。权限规定了一个人可以做什么；同样重要的是，他到底能看到什么。
- 把后台菜单精简到真正需要的项目
- 当多个客户使用同一个安装时，将媒体库限制为只显示各自的文件
- 隐藏与使用者无关的小工具和导航菜单
- 登录后直接跳转到开始工作的地方——而不是跳到挂着五个提示框的仪表盘
一分钟就能完成的测试
权限无法在设置它的那个界面上评判。为每个角色创建一个测试用户，并以该用户身份登录——在另一个浏览器中进行，这样你自己的账号仍保持登录。
对于受保护的内容，还有第二项测试：退出登录，用受保护文章中的一个词访问 /wp-json/wp/v2/posts?search=。如果响应中出现了该内容，说明你的规则只改变了视图——数据仍然是公开的。
这项测试适用于任何权限插件。“隐藏”和“锁定”是两回事，而只有其中一个靠得住。
多人维护时的两个陷阱
第一个：有权分配权限的人，可以给自己分配更多权限。WordPress 为此设有一个钩子——get_editable_roles()——而绕过它的插件，恰恰打开了它本应关闭的那条路。
第二个涉及多站点网络：在那里，角色有一部分是全网络共用的。从某个子站点覆盖它们的人，会改变所有站点上的角色——包括那些不归他管的站点。
告别时
- 停用账号，而不是立刻删除——否则文章会失去作者。
- 删除之前，把文章转移到另一个账号名下。
- 撤销该账号的应用程序密码；即使修改了密码，它们依然有效。
- 结束正在进行的会话。
- 在变更记录中写明时间和原因。
常见问题
没有管理员权限的客户能更新插件吗？
不能，而且这样很好。更新属于运维工作，而不是内容维护——更新是最常导致出问题的时刻。
如果客户坚持要当管理员呢？
那就为他另建一个账号，让日常使用的账号保持较小的角色。这和人们在自己电脑上做的分离是一回事。
这需要插件吗？
对于四个标准角色，不需要。一旦你想补充单项权限、精简菜单或真正保护内容，就需要。
自定义角色设多少个比较合理？
越少越好。三到四个就能覆盖几乎所有编辑团队；每多一个，就多一个没人能理清的角色。
限制在前台也会生效吗？
只有当插件在前台也强制执行时才会。用上面的 REST 测试检查一下——一分钟就能得出答案。