Last updated September 8th, 2023 at 12:07 pm
Overview
Out of the box, WordPress offers a gatekeeping system — controlling which users can perform which actions — based on a default set of user roles and capabilities. In this article, I’ll explain the limitations of those default roles and capabilities and how you can modify them to better meet your specific needs.
Default WordPress Roles & Capabilities
The default WordPress roles — and the capabilities assigned to those roles by default — are inadequate in some situations and potentially dangerous in others. It’s not uncommon for a WordPress admin to promote a user to a role that confers more power than that user should have, just so that he or she can perform a limited set of functions not available to a lower-level role.
For example, you might want to permit a user to edit only blog posts — not pages or any other custom post types. Unfortunately, the “Editor” role, by default, permits editing both blog posts and pages — as well as some other custom post types.
Probably the most common case of giving users more power than they should have is the practice of conferring the role of “Administrator” to users who don’t need and shouldn’t have all the capabilities associated with that role.
The problem with overloading users with more power than they need isn’t so much that they’ll deliberately abuse their power and nefariously damage things, as this is a rare occurrence. Rather, the problem is that users who don’t need to be Administrators might create problems inadvertently (at worst) or be confused by the dashboard interface (at best).
Fortunately, the extensibility of WordPress allows us to customize dashboard access in such a way to give users access only to the functionality they need.
The Scenario
I’ll illustrate how to customize your WordPress website’s gatekeeping system using the example of a WordPress/MemberPress membership site I recently launched for the SouthEastern Bluegrass Association (“SEBA”).
SEBA is an all-volunteer organization dedicated to the support and promotion of bluegrass music in the southeastern United States. The organization has several geographically-based chapters, each of which holds a monthly meeting and bluegrass jam that is organized by that chapter’s volunteer leader, who is a website user with an active SEBA membership. (These chapter leaders are sometimes referred to as “Chapter VPs”, even though they’re not actual officers of the organization.)
Each chapter (which is a WordPress custom post type called “chapter” — more posts about custom post types here) has its own page on the SEBA website, and the requirement was that a chapter’s page content could be created and edited only by that chapter’s “VP”. (Of course, site Administrators would also have that capability.)
The Problem
Without modifying the WordPress default role-capability gatekeeping system, there was no way to limit chapter editing powers as needed. In the default system, an editor is an editor — without regard to the type of post. If we made a chapter leader a WordPress “Editor”, he or she could edit not only any chapter’s content but almost any content for any post type. We definitely did not want that.
The Solution
The solution consisted of 3 parts:
- A new role, which we called “Chapter VP”
- A new capability type, called “chapter”
- Granting specific capabilities to the “Chapter VP” role
Step 1: Create New Role
Using the Members plugin, originally developed by Justin Tadlock and currently maintained by the folks at MemberPress, I created the new role, “Chapter VP”. Doing so was as simple as selecting “Members ? Roles ? Add New Role” in the WordPress dashboard.
Step 2: Create New Capability Type
To create the new capability type, I edited the php code that registers the “chapter” custom post type.
When registering a custom post type, there is an optional parameter for ‘capability type’ whose default value is ‘post’ (details on the ‘capability_type’ parameter here. Setting the capability type for a custom post type to ‘post’ means that the capabilities for reading, editing, and deleting posts of that type will be the same as the capabilities for standard (blog) posts.
To create this new capability type, I simply replaced this line…
'capability_type' => 'post',
with this line…
'capability_type' => 'chapter',
The result of this modification is that WordPress will generate new capabilities that can be granted or denied to specific roles. Note capabilities in this screen shot.
Step 3: Grant Capabilities
Finally, I used the Members plugin to grant capabilities to the new Chapter VP role.
Here’s the screen shot again, with callouts. Note that while capability #1 (edit_chapters) is granted to the Chapter VP role, capability #2 (edit_others_chapters) is not. This is how we allow a Chapter VP to edit his/her chapter content but not chapter content of any other Chapter VPs.
In Closing
Creating new WordPress roles and capabilities and assigning capabilities to roles can be performed with code as well as with other role management plugins. In this case, I chose to use the (free) Members plugin for our solution for these reasons:
- I chose to use a plugin rather than code so as to make the process more accessible to WordPress admins who are not developers.
- I’ve been using the Members plugin for years, and it integrates seamlessly with MemberPress.
I hope this article drives home how easy it is to customize WordPress user roles and capabilities — and how you can use these techniques to avoid the trap of making users who shouldn’t be administrators administrators. (And keep in mind that you can create new roles without creating new capabilities.)
If you have questions, comments, or examples of how you customized user roles and capabilities for one of your WordPress websites, please let me know in the comments below.
Leave a Reply