Extending Role Capabilities in WordPress

WordPress comes equipped with a standard user role management system granting permissions and actions limited to each role. In this tutorial, I provide a summary of the default roles and their capabilties in WordPress and demonstrate how to add capabilities (similar to permissions in other platforms) to existing roles. Each approach has caveats, which I highlight in each example.

First, we’ll take a look at the default roles WordPress has to offer.

Note: If you’re looking for a quick solution involving no coding/development, please download the User Role Editor plugin.

Default WordPress Roles and Capabilities

By default, a typical WordPress installation has five default user roles:

1. Administrator
2. Editor
3. Author
4. Contributor
5. Subscriber

To understand each role, I’ve provided a summary of each.

Administrator

The Administrator role is the most powerful role in the WordPress ecosystem. Administrators have the ability to:

• Add, edit, and delete all content types and users
• Add, edit, and delete plugins and themes
• Update the WordPress Core
• Completely control the website

Smaller sites usually delegate this role to the owner of the website or to a dedicated developer/webmaster who deploys regular updates and manages technical operations for the website. Anyone who does not require this level of capabilities should be assigned a different role.

Editor

Editors control and manage the content aspects of a WordPress website. Editors have the ability to:

• Add, edit, puslish, and delete all content types
• Moderate, edit, and delete comments on posts
• Create categories
• Add categories
• Create and add tags

Editors do not have capabilities to change site settings or perform technical changes like updating plugins, updating themes, or adding/removing other users.

Author

Authors manage and produce their own content on a WordPress site. Authors have the ability to:

• Add, edit, publish, and delete their own posts
• Add categories
• Create and add tags

Unlike Editors, Authors can only view comments on their posts, but they cannot moderate, approve, or delete them.

Contributor

Contributors create their own content on a WordPress site. Contributors have the ability to:

• Add and edit their own posts
• Create and add tags

Like Authors, Contributors can only view comments on their posts, but they cannot moderate, approve, or delete them.

Subscriber

The Subscriber role is the most restricted role. The only capabilities this role has is the ability to update their own user profile information and to change their login password. This role is useful for websites that have a subscription model where users must login to read content or leave comments.

Extending Current Role Capabilities

Sometimes, the base roles and capabilities aren’t enough and an existing role needs to be extended. In a recent project, I needed to give the Subscriber role the ability to read private posts and pages on a site. Instead of adding a plugin to do this, I decided to extend the roles using the get_role() and add_cap() WordPress functions.

There’s a number of approaches to solving this problem, so I’ll provide two different examples with their pros and cons.

Extending Roles in functions.php

This is probably the quickest and simplest solution for extending capabilities on a role; a function is created that where the Subscriber role is retrieved via get_role() and stored in a variable. The role then gets the read_private_posts and read_private_pages capabilities added to it via add_cap(). Overall, this approach is pretty simple and straightforward. This approach is also the one I see floating around the internet as the defacto solution. Below is an example.

Caveats

• This method will write to the database even if the capability has been registered.
• This method will fire on every page load, compromising performance.

Extending Roles Using a Custom Plugin

A more robust and performance friendly approach to this problem requires a bit of extra work, but makes up for the performance caveats in the previous example. In this example, we’ll create a simple plugin that extends the capabilities of the Subscriber role.

When writing a plugin, the register_activation_hook() function is used to trigger the code when the plugin is activated, meaning it will only fire once. It must be taken into account, though, that the capabilities should be disabled/removed when the plugin is deactivated, so the register_deactivation_hook() needs to be used to remove the capabilities when the plugin is deactivated.

Caveats

• This solution depends on activation/deactivation of the plugin
• What happens if the plugin is live in production, but an update to the plugin is pushed?

Conclusion

While WordPress has multiple approaches to solving problems, the relationship between what needs to be achieved and the database always needs to be taken into consideration, especially when writing plugins and themes.

Along with writing clean and effective code, please document any changes and overrides so that other developers who may inherit your site in the future can understand the how and why your changes were made (or better yet, a reminder for yourself).

Did I miss something? Feel free to leave a comment below or contact me if you have any questions.