User Role Editor Alternative: Five Questions Before You Switch

If you're looking for an alternative to a permissions plugin, you usually haven't run into a bug but noticed a gap: a client sees menu items that are none of their business. A protected post shows up somewhere after all. Or nobody can say anymore who got which capability and when. Five questions sort this out.

Question 1: Does the rule hold without the backend?

This is the most important one, and you can answer it yourself in a minute. Protect a post so that only a specific role is supposed to see it. Log out. Open /wp-json/wp/v2/posts?search= with a word from that post.

If the content shows up in the response, your rule only changes the view. The WordPress REST API is reachable out of the box, and it queries different parts of the code than a post list in the backend does. Kakapo Roles explicitly enforces the visibility rule there as well — which is exactly why this test is the fastest way to evaluate a permissions plugin.

Run this test with the plugin you're currently using, too, before you switch. Sometimes the gap is somewhere else — in a page builder, for example, that delivers content via its own endpoint.

Question 2: Can someone give themselves more capabilities?

A permissions plugin that lets anyone with access to its interface upgrade their own role defeats its purpose. WordPress has a safeguard for this — get_editable_roles() — which determines which roles someone is allowed to edit at all. The question for the alternative: Is it respected everywhere?

In network mode, there's a second boundary: there, some roles are network-wide. Anyone who overwrites them from a subsite changes them for all sites in the network — including the ones that don't belong to them.

Question 3: Can the backend be cleaned up?

Capabilities define what someone MAY do. For a client, what they SEE is just as important. An editor facing twelve menu items, ten of which are locked, doesn't have a secure backend — just a confusing one.

So check whether the alternative goes beyond roles and capabilities: admin menu per role, limiting the Media Library to own files, widgets and navigation menus, allowed shortcodes, redirect after login. Kakapo Roles has all of this built in — with many plugins of this kind, it takes separate add-ons or code snippets.

Question 4: Can you look up what was changed?

Capabilities are changed rarely and usually under time pressure. Six months later, the question comes up of why a role is allowed to do something. Without a log, the answer is a guess.

The question for the alternative: is there a change log, and does it record WHO gained or lost WHICH capability WHEN? Kakapo Roles keeps one and also records the changes made through assignment and migration.

Question 5: Do I have to rebuild this on every site?

If you look after several installations, you build the same capability structure multiple times — and deviate from it a little each time. After a year, five sites are five special cases. So check whether the structure can be exported and imported, and what happens to existing roles on import: merge or replace?

Kakapo Roles can do both and tells you before importing which of the two options is selected. “Replace” is the more dangerous one — which is why it has to be explicitly confirmed.

The checklist in brief

What you should do before switching

1. Record the current state — which custom roles exist and which capabilities are attached to them.
2. Create a backup. Capabilities live in the database; one slip affects all users at once.
3. Recreate the structure in the new plugin and compare it line by line.
4. Log in with a test user for each role and check what they really see.
5. Run the REST test from question 1.
6. Deactivate the old plugin instead of deleting it — for two weeks.

Two permissions plugins running at the same time write to the same roles, and whoever saves last wins. During the transition period, only make changes in one of the two.

Frequently asked questions