How to Modify Roles and Permissions in WordPress (Roles, Capabilities & Custom Roles)
If you run a WordPress site with more than one person logging in, sooner or later you need to control who can do what. An author should not be able to install plugins. A freelance editor should not be able to delete other people’s posts. A shop manager needs to manage orders but not touch your theme files. WordPress handles all of this through roles and capabilities, and learning how to modify them is one of the most practical skills for keeping a site organized and secure.
This guide explains the default WordPress roles, the difference between roles and capabilities, and exactly how to modify or adjust them — both with a role-editor plugin and directly in code.
Key Takeaways
• A role is a named bundle of capabilities (individual permissions like `edit_posts` or `manage_options`).
• WordPress ships with five default roles: Administrator, Editor, Author, Contributor, and Subscriber.
• You can modify roles the easy way with a role-editor plugin, or precisely in code using `add_role()`, `add_cap()`, `remove_cap()`, and `get_role()`.
• Always follow the principle of least privilege: give each user only the capabilities they actually need.
• Code that creates roles writes to the database — run it once on activation, not on every page load.
What are the default WordPress roles and what can each one do?
Out of the box, WordPress defines five roles arranged in a rough hierarchy. Each higher role generally includes the capabilities of the one below it, plus more.
| Role | What it can do | Key capabilities |
|---|---|---|
| Administrator | Full control of the site, including users, plugins, themes, and settings | `manage_options`, `install_plugins`, `edit_users`, `switch_themes` |
| Editor | Manage and publish all posts and pages, including those by other users | `edit_others_posts`, `publish_pages`, `delete_others_posts`, `manage_categories` |
| Author | Write, publish, and manage their own posts only | `publish_posts`, `edit_published_posts`, `upload_files` |
| Contributor | Write and edit their own posts but cannot publish them | `edit_posts`, `delete_posts` (no `publish_posts`) |
| Subscriber | Manage only their own profile; mainly used for membership or comments | `read` |
On a single-site install, the Administrator is the top role. On a WordPress Multisite network, there is an additional Super Admin role that controls the entire network of sites.
The practical takeaway: most permission problems are solved by either assigning a user the right existing role, or by adjusting the capabilities of a role to fit your workflow.
What is the difference between a role and a capability?
This distinction is the heart of managing permissions, so it is worth slowing down.
- A capability is a single, granular permission. Examples: `edit_posts`, `publish_posts`, `delete_others_posts`, `manage_options`, `upload_files`. WordPress checks capabilities — not roles — when deciding whether a user can perform an action.
- A role is simply a named bundle of capabilities. The “Editor” role, for instance, is just a label attached to a specific set of capabilities.
Internally, WordPress checks permissions with `current_user_can()`, and that function tests for a capability, not a role:
“`php if ( current_user_can( ‘edit_others_posts’ ) ) { // Show the “Edit” link for this post. } “`
Because of this, you have two ways to adjust what someone can do: change which role a user has, or change which capabilities a role contains. Understanding that roles are containers and capabilities are the contents makes everything that follows straightforward.
How do you modify roles and permissions with a plugin?
For everyday changes, a dedicated role-editor plugin is the easiest and safest approach — no code, and you get a visual interface to see every capability.
Popular tools include User Role Editor and Members. Both let you:
- Add or remove capabilities from an existing role. For example, grant Authors the `manage_categories` capability so they can create their own categories.
- Create a custom role from scratch or by cloning an existing one (for instance, clone “Editor” and remove the ability to delete posts).
- Assign multiple roles to a single user, or bulk-change roles across users.
The typical workflow:
- Install and activate the role-editor plugin.
- Open its settings screen (usually under Users or a dedicated menu).
- Select the role you want to change.
- Tick or untick capabilities, then save.
Because the changes are visual and reversible, plugins are ideal when you are experimenting or when non-developers manage the site. The trade-off is that you are trusting a third-party tool with sensitive permission data, so use a well-maintained plugin and keep it updated.
How do you modify roles and permissions in code?
When you want version-controlled, repeatable permission logic — or you are building a plugin or theme — you modify roles directly in code using WordPress’s Roles API. The core functions are:
- `add_role()` — create a brand-new role.
- `get_role()` — retrieve an existing role object so you can change it.
- `add_cap()` — add a capability to a role.
- `remove_cap()` — remove a capability from a role.
- `remove_role()` — delete a role entirely.
Creating a custom role with specific capabilities
Suppose you want a custom “SEO Manager” role: someone who can edit all posts and pages and manage categories, but cannot install plugins, change settings, or manage users. Here is how you would define it:
“`php function darazhost_register_seo_manager_role() { add_role( ‘seo_manager’, // Unique role slug. ‘SEO Manager’, // Display name. array( ‘read’ => true, // Access wp-admin. ‘edit_posts’ => true, ‘edit_others_posts’ => true, ‘edit_published_posts’ => true, ‘edit_pages’ => true, ‘edit_others_pages’ => true, ‘manage_categories’ => true, ‘upload_files’ => true, // Note: no manage_options, install_plugins, or edit_users. ) ); } “`
To adjust an existing role instead of creating a new one, fetch it with `get_role()` and modify its capabilities:
“`php function darazhost_adjust_author_caps() { $author = get_role( ‘author’ );
if ( $author ) { $author->add_cap( ‘manage_categories’ ); // Let Authors create categories. $author->remove_cap( ‘delete_published_posts’ ); // Stop Authors deleting live posts. } } “`
The detail almost every tutorial skips: `add_role()`, `add_cap()`, and `remove_cap()` do not just change permissions in memory for the current request — they write to your database, specifically to the `wp_user_roles` value stored in the `wp_options` table. If you hook these functions to something like `init` or `after_setup_theme`, they run on every single page load, repeatedly rewriting the same data. That is wasted queries on every request, and over time it can bloat the options table and make role changes hard to reverse.
The correct pattern is to call these functions once, on activation, not on every load:
“`php // For a plugin: register_activation_hook( __FILE__, ‘darazhost_register_seo_manager_role’ );
// For a theme, run once on switch: add_action( ‘after_switch_theme’, ‘darazhost_register_seo_manager_role’ ); “`
And clean up on the way out, so you do not leave orphaned roles behind:
“`php register_deactivation_hook( __FILE__, function () { remove_role( ‘seo_manager’ ); } ); “`
Think of it this way: defining a role is a setup action, not a runtime action. Run it once, store it, and let WordPress read it from the database on every request after that.
How do you change a single user’s role?
Modifying a role changes permissions for *everyone* assigned to it. To change just one person, change *which role they hold*:
- In the dashboard: go to Users → All Users, hover over the user, click Edit, choose a new value in the Role dropdown, and update. You can also use the bulk “Change role to…” action on the Users list.
- In code:
“`php $user = new WP_User( $user_id ); $user->set_role( ‘seo_manager’ ); // Replaces all existing roles. // Or add a role without removing existing ones: $user->add_role( ‘editor’ ); “`
Use `set_role()` to replace, or `add_role()` on the user object to layer an additional role on top.
What is the principle of least privilege, and why does it matter?
The principle of least privilege means giving every user (and every account) only the capabilities required to do their job — nothing more. It is the single most important idea in role management, and it is fundamentally a security practice.
Why it matters:
- Smaller attack surface. If a Contributor’s account is compromised, the attacker inherits only Contributor-level capabilities — they cannot install a malicious plugin or edit theme files.
- Fewer accidents. Users cannot break things they were never allowed to touch. An Author cannot accidentally delete a colleague’s published article if they lack `delete_others_posts`.
- Clear accountability. When roles map tightly to real responsibilities, it is easier to audit who could have done what.
A few common, least-privilege-friendly tasks:
- Let Editors manage menus or widgets without making them Administrators — add `edit_theme_options` to the Editor role.
- Restrict Authors from deleting published posts — remove `delete_published_posts` from the Author role.
- Give a client a “view reports” role that can read the dashboard and analytics but change nothing else.
- Create a “Shop Manager” role for an online store that handles orders and products but has no access to site settings or user management.
The guiding question for every capability is simple: *Does this person actually need to do this?* If the answer is no, do not grant it.
Secure hosting that complements smart role management
Tight roles and capabilities are one layer of defense — but they protect the application level only. A genuinely secure WordPress site also needs protection at the server level, and that is where your hosting matters.
DarazHost provides secure, reliable WordPress hosting designed to work hand-in-hand with good permission hygiene:
- Server-level security and a managed firewall to block threats before they reach WordPress.
- Free SSL to encrypt every login and admin session — so the credentials behind your carefully-scoped roles stay protected in transit.
- Reliable, performance-tuned infrastructure so your dashboard and role changes stay fast.
- 24/7 expert support to help you harden your site and troubleshoot issues quickly.
Least-privilege users plus a hardened host is defense in depth: even if one layer is tested, the others hold.
Frequently asked questions
1. Will modifying a role affect users who are already assigned to it? Yes. Roles are shared definitions, so any capability you add or remove applies immediately to every user holding that role. If you want to change permissions for just one person, change their role assignment instead — or create a custom role for them.
2. If I remove a role-editor plugin, will my custom roles disappear? Not automatically. Because role changes are written to the database, custom roles and modified capabilities often persist even after a plugin is deactivated. Good plugins offer a “reset to default” option — use it before uninstalling if you want a clean slate.
3. What is the difference between a role and a capability again? A capability is a single permission (like `publish_posts`). A role is a named bundle of capabilities (like “Editor”). WordPress checks capabilities to decide what a user can do, and roles are just a convenient way to group them.
4. How many custom roles can I create? There is no hard limit in WordPress. That said, fewer, well-defined roles are easier to maintain than dozens of overlapping ones. Create a custom role only when an existing role plus minor capability tweaks will not do the job.
5. Is it safer to edit roles with a plugin or with code? Both are safe when done carefully. Plugins are better for non-developers and quick, visual changes. Code is better for version control, repeatability, and shipping permission logic inside a plugin or theme — just remember to run role-creation functions on activation, not on every page load.