Members vs. Kakapo Roles: Managing Capabilities That Actually Hold

A permissions plugin is measured by a single question: does the capability still hold when nobody is clicking through the backend? Much of what's called “hiding” only changes the view — the data remains exposed, one REST API request away. This comparison sorts Members and Kakapo Roles by that.

The short answer

Members is an established, free permissions plugin: create and edit roles, assign capabilities, protect content per role. It's lean, widely used, and sufficient for most simple cases.

Kakapo Roles goes one level deeper. It manages not only roles and capabilities but also what a user sees in the backend in the first place — admin menu, Media Library, widgets, shortcodes — and it explicitly enforces the visibility rules in the REST API as well. On top of that come a change log, a trash for deleted roles, and import/export.

In short: if you want to create roles and protect content, Members will take you far and costs nothing. If you want to give a client a tidy backend, document capabilities traceably, or prevent a rule from only affecting the interface, Kakapo Roles is the better fit.

What both can do

• Create, rename, and delete custom roles
• Set capabilities per role, including those of custom post types
• Grant individual users additional capabilities or revoke them
• Restrict content to specific roles
• Several roles per user

Up to this point, the choice is a matter of taste. Beyond that, it gets interesting.

Where the two differ

The difference that matters: hiding isn't locking

If a post should be visible “only to specific roles,” there are two ways to implement that. One hides it in lists and on the front end. The other denies access — everywhere, including where nobody clicks.

The difference isn't a subtlety. The WordPress REST API is reachable out of the box; a request to /wp-json/wp/v2/posts returns posts as JSON, without logging in. A rule that only changes the view has no effect there — the content that was meant “for members only” appears in plain text in the response.

That's why Kakapo Roles also enforces the visibility rule in the REST API. That one line is the reason a permissions plugin can be tested at all: request your protected address once as JSON, while logged out. If the content is there, the rule protects nothing.

You can run this test with any plugin, including the one you're using right now: protect a post, log out, open /wp-json/wp/v2/posts?search=…. It takes one minute and tells you more than any feature list.

The second trap: who's allowed to grant capabilities?

A permissions plugin that lets anyone with access to its interface give themselves more capabilities defeats its own purpose. WordPress has a safeguard for this: get_editable_roles() determines which roles someone is allowed to edit at all. A plugin that bypasses it opens exactly the door it's supposed to close.

In network mode, a second question comes up: there, some roles are network-wide. Anyone who overwrites them from a subsite changes them for all sites. Kakapo Roles respects both — the safeguard and the boundary between site and network.

When Members is the better choice

• You need roles and capabilities, nothing else
• Your budget is zero
• You work with a single site and few users
• You want a plugin that does exactly one thing

When Kakapo Roles is the better choice

• You're handing a backend over to a client and want to tidy it up — menu, Media Library, widgets
• You want protected content to be protected via the REST API too
• You need to be able to prove who got which capability and when
• You want to build a capability structure once and transfer it to other sites
• You already use other Kakapo plugins and want one invoice instead of five

Switching: what to do

1. Write down which custom roles exist and which capabilities are attached to them — a screenshot of the matrix is enough.
2. Create a backup. Capabilities live in the database, and one slip affects all users at once.
3. Install Kakapo Roles and enter your license key.
4. Recreate the roles and compare the matrix line by line with your notes.
5. Log in with a test user for each role and check what they really see.
6. Run the REST test for a piece of protected content.
7. Only then switch off the old plugin — don't delete it, keep it for two weeks.

Running two permissions plugins at the same time is a bad state of affairs: both write to the same roles, and whoever saves last wins. Keep the transition period short, and during that time only make changes in one of the two.

Frequently asked questions