How to Manage User Roles and Permissions in WordPress?

Every WordPress user account has a role, and every role is really just a named bundle of capabilities — individual permissions like edit_posts, publish_posts, or manage_options that WordPress checks before letting an action happen. Understanding how these two things (roles and capabilities) relate is the difference between clicking around dashboard menus hoping you set permissions correctly, and knowing exactly what a given user can and can't do.

This guide covers WordPress's default role system, how to change a user's role through the dashboard and programmatically, and how to fine-tune permissions at the capability level when the built-in roles don't quite fit.

WordPress's Default Roles, Explained

A fresh WordPress install ships with five roles, each a progressively smaller set of capabilities:

• Administrator — full access to everything: installing plugins and themes, managing users, editing settings, and every content capability. Reserve this for people who need to manage the site itself, not just its content.
• Editor — can publish, edit, and delete any post or page (including other users' content), manage categories and tags, and moderate comments. No access to plugins, themes, or site settings.
• Author — can write, edit, publish, and delete their own posts, and upload media. Cannot touch anyone else's content.
• Contributor — can write and edit their own posts, but cannot publish them; a Contributor's post moves to "Pending Review" until an Editor or Administrator publishes it.
• Subscriber — can log in and manage their own profile, nothing else. The default role for anyone who just needs an account (commenting, a membership area, a course).

If you're running WooCommerce, LearnDash, or a similar plugin, you'll also see roles like Shop Manager or LMS Instructor added on top of these five — plugins register their own roles the same way core does.

How Capabilities Actually Work

Under the hood, a role is stored as an array of capability names mapped to true. When WordPress needs to decide whether the current user is allowed to do something, it calls current_user_can() with a capability name:

if ( current_user_can( 'publish_posts' ) ) {
    // This user's role includes the publish_posts capability.
}

current_user_can() also accepts a specific object, which matters for capabilities that depend on ownership — for example, checking whether the current user can edit one particular post rather than posts in general:

if ( current_user_can( 'edit_post', $post_id ) ) {
    // True for the post's author (if they have edit_posts),
    // or for anyone with edit_others_posts (Editors, Admins).
}

That second example runs through WordPress's map_meta_cap filter, which translates a "meta capability" like edit_post into the actual primitive capabilities (edit_posts, edit_others_posts, edit_published_posts) a role needs, based on who owns the post and its status. You'll reach for this same filter if you ever build a custom user role with ownership-aware permissions of your own.

Changing a User's Role from the Dashboard

For one-off changes, the dashboard is the fastest path:

1. Go to Users > All Users.
2. Find the user and click Edit (or check their box and use Bulk Actions > Change role to for multiple users at once).
3. Under Role, select the new role from the dropdown.
4. Click Update User (or Change for bulk edits).

This replaces the user's existing role entirely — WordPress's default UI doesn't support giving one user two roles at once, though that's possible programmatically.

Changing Roles Programmatically

For anything you need to run automatically — say, promoting a user to Editor after they've published five posts, or syncing roles from an external system — WP_User gives you three methods:

$user = get_user_by( 'id', 42 );

// Replaces all of the user's existing roles with just this one.
$user->set_role( 'editor' );

// Adds a role without removing whatever roles they already have.
$user->add_role( 'shop_manager' );

// Removes one specific role, leaving any others intact.
$user->remove_role( 'subscriber' );

set_role() is what you want almost all the time — it's a clean swap. add_role() and remove_role() exist for the less common case of a user legitimately needing multiple simultaneous roles (a site where someone is both a Shop Manager and an Author, for instance).

Adding or Removing Capabilities from a Role

Sometimes the built-in roles are 90% right but missing one capability you need. Rather than building a whole custom role, you can adjust an existing one directly:

function tw_grant_editors_theme_access() {
    $editor = get_role( 'editor' );

    if ( $editor && ! $editor->has_cap( 'edit_theme_options' ) ) {
        $editor->add_cap( 'edit_theme_options' );
    }
}
add_action( 'init', 'tw_grant_editors_theme_access' );

get_role() returns a WP_Role object, and add_cap() / remove_cap() modify it directly in the database — this isn't a filter that runs on every request, it's a one-time write, similar to what happens when a plugin activates. That means you should run it once (on plugin activation, or gated behind a check like the has_cap() test above) rather than on every single init, or you'll be writing to the wp_options table on every page load for no reason.

The reverse works the same way:

$editor = get_role( 'editor' );
$editor->remove_cap( 'edit_theme_options' );

Restricting Dashboard Menus and Admin Pages by Capability

Beyond content actions, capabilities gate dashboard visibility too. If you've added a custom admin page, tie it to a specific capability rather than leaving it open to anyone who can log in:

add_action( 'admin_menu', function () {
    add_menu_page(
        'Site Reports',
        'Reports',
        'manage_options', // capability required to see this menu item
        'tw-reports',
        'tw_render_reports_page'
    );
} );

Only users whose role includes manage_options (Administrators, by default) will even see the "Reports" item in their dashboard sidebar — WordPress hides menu items automatically based on the capability passed to add_menu_page(), rather than requiring you to check permissions again inside the page callback (though it's still good practice to check again inside tw_render_reports_page() in case something calls it directly).

Best Practices for Managing Roles and Permissions

• Follow least privilege. Give each person the smallest role that lets them do their job. A content writer who never touches settings doesn't need Administrator access, even if it's more convenient in the moment.
• Audit roles periodically. It's common for a site to accumulate Administrator accounts over time — a former contractor, a plugin support request that was never downgraded back. Review Users > All Users every few months.
• Never share the Administrator account. Every person with dashboard access should have their own login; shared credentials make it impossible to know who did what, and complicate changing a password when someone leaves the team.
• Use capability checks, not role checks, in your own code. Write current_user_can( 'publish_posts' ) rather than current_user_can( 'editor' ) wherever possible. Checking a capability keeps your code working correctly even if a site later customizes which roles have which permissions.

Frequently Asked Questions (FAQ) About WordPress User Roles and Permissions

Conclusion

WordPress's five default roles cover most sites out of the box, but the real flexibility lives one level down, in the individual capabilities that make up each role. Once you're comfortable with current_user_can(), get_role(), and the three WP_User methods for changing roles, you can adjust permissions precisely instead of over-granting Administrator access out of convenience.

When the built-in roles genuinely don't fit — a role that should publish content but never touch plugin settings, for instance — the next step is building one from scratch, which is exactly what creating a custom user role covers.