WordPress User Roles and Capabilities — Admin, Editor, Author, Contributor and Subscriber

In this tutorial, you'll learn every WordPress user role — Administrator, Editor, Author, Contributor, Subscriber — and how to assign roles securely.

What You'll Learn

• Why user roles matter for security, workflow, and delegation
• The six default roles: Super Admin, Administrator, Editor, Author, Contributor, Subscriber
• The capabilities table — exactly what each role can do
• How to add, remove, and modify roles and capabilities with PHP
• When and how to create custom roles
• Best practices: Least Privilege, no admin accounts for authors

Why It Matters

Every user you add to your WordPress site is a potential security risk. If an Author account gets hacked, the attacker can publish malicious content. If an Administrator account gets compromised, they can install backdoor plugins, steal the database, or delete the entire site. Understanding user roles lets you give each person exactly the access they need — nothing more. This is called the principle of least privilege, and it is the single most important security practice you can implement.

Real-World Use

A news website has 50 contributors who write articles, 10 editors who review and publish, 2 administrators who manage plugins and themes, and 1 super admin who oversees a multisite network. Without roles, every user would need full admin access — a disaster waiting to happen. With roles, contributors can only write, editors can only publish, and only the two admins can install plugins. If a contributor's account is compromised, the attacker can write a draft — nothing more.

Learning Path

flowchart LR
    A[Backup & Migration] --> B[User Roles and Capabilities]
    B --> C[Managing Users]
    C --> D[Multisite Network]
    D --> E[Site Health & Debugging]
    B --> F[Custom Post Types]

    style B fill:#38bdf8,color:#0f172a,stroke-width:2px

What Are User Roles?

A user role is a collection of capabilities assigned to a user. A capability is a specific action a user can perform — like edit_posts, publish_posts, moderate_comments, or activate_plugins.

Think of a role like a keycard in an office building. A Subscriber's keycard opens only the front door. An Administrator's keycard opens every door, including the server room. You would not give a mailroom employee a keycard that opens the CEO's office. The same principle applies to WordPress — you assign each user the role that matches their job.

Capabilities vs Roles

A role is a named group of capabilities. WordPress checks capabilities, not roles, when deciding if a user can perform an action. For example, when a user tries to publish a post, WordPress checks if they have the publish_posts capability. If their role includes it, the action is allowed.

The Six Default Roles

Subscriber

A Subscriber can only manage their own profile — change their name, email, password, and how their display name appears on the site. They cannot write posts, upload files, or see anything in the admin area beyond their profile screen.

Typical use: A membership site where registered users access exclusive content but do not contribute content themselves.

Contributor

A Contributor can write and edit their own posts but cannot publish them. They also cannot upload files (images, documents) — they can only add text. A Contributor's post must be reviewed and published by an Editor or Administrator.

Typical use: Guest writers or junior staff who submit draft articles for review.

Author

An Author can publish and edit their own posts, upload media files, and manage their own profile. They cannot edit posts by other users, cannot manage categories (they can only use existing ones), and cannot change site settings.

Typical use: Regular blog writers who you trust to publish their own work.

Editor

An Editor can manage all posts and pages — including those written by other users. They can publish, edit, delete, and moderate comments, manage categories and tags, and create new links. They cannot change site settings, install themes or plugins, or manage users.

Typical use: A senior editor who manages a team of writers and oversees all content on the site.

Administrator

An Administrator has access to every feature on a single-site WordPress installation. They can install and delete themes and plugins, manage all users, change settings, edit any content, and do absolutely everything.

Typical use: The site owner or lead developer responsible for the technical operation of the site.

Super Admin

The Super Admin role exists only on multisite networks. A Super Admin can manage the entire network — add and delete sites, install themes and plugins network-wide, manage users across all sites, and control network settings. Super Admins are the highest level of access in WordPress.

Typical use: The person managing a multisite network with dozens or hundreds of sites.

Capabilities Table

Here is what each role can do. A checkmark means the capability is included in the role by default.

Important: The Super Admin column applies only to multisite networks. On a single-site installation, Super Admin and Administrator are essentially the same, though technically the Administrator is the highest role.

How WordPress Checks Capabilities

When you write code that performs an action, you check the user's capability first:

// Check if the current user can publish posts
if (current_user_can('publish_posts')) {
    // Let them publish
    wp_publish_post($post_id);
} else {
    // Redirect with error message
    wp_die('You do not have permission to publish posts.');
}

The function current_user_can() checks the current logged-in user's role and returns true if they have the specified capability. Always check capabilities before performing sensitive actions — never assume a user is authorized just because they reached a page.

You can also check a specific user by ID:

// Check a specific user by ID
$user_id = 42;
if (user_can($user_id, 'edit_others_posts')) {
    echo 'This user can edit other people\'s posts.';
}

Adding and Removing Capabilities with PHP

WordPress provides several functions to manage roles programmatically. These are typically added to your theme's functions.php file or a custom plugin.

Adding a New Role

// Add a custom role called "Moderator"
add_role(
    'moderator',             // Role slug
    'Moderator',             // Display name
    array(                   // Capabilities
        'read'              => true,
        'moderate_comments' => true,
        'edit_posts'        => true,
        'edit_others_posts' => false,
        'publish_posts'     => false,
    )
);

The first parameter is the internal slug, the second is the human-readable name, and the third is an associative array of capabilities. Any capability you do not specify defaults to false.

Adding a Capability to an Existing Role

// Grant the Editor role the ability to manage plugins
$role = get_role('editor');
$role->add_cap('activate_plugins');

// Now editors can activate plugins — be careful with this

Removing a Capability from a Role

// Remove the ability for Authors to upload files
$role = get_role('author');
$role->remove_cap('upload_files');

// Authors can still write posts but cannot upload images

Removing a Role Entirely

// Remove the Contributor role from your site
remove_role('contributor');

// This deletes the role and reassigns users with that role
// to the default role (usually Subscriber)

Resetting Default Roles

If you make a mistake, you can reset all roles to their defaults using a plugin or by installing a fresh copy of WordPress and exporting the roles table. There is no built-in "reset roles" function.

Custom Roles — When and How

The six default roles cover most scenarios, but sometimes you need something specific. For example, you might want a role that can only upload images but not write posts (a "media manager"), or a role that can manage WooCommerce orders but not products.

When to Create a Custom Role

• You need a fine-grained permission that no default role provides
• You want to limit a role further than the most restrictive matching default
• You are building a plugin that adds its own capabilities

When NOT to Create a Custom Role

• You can achieve the same result with a default role
• You only need one or two additional capabilities — consider adding them to an existing role instead

Using Plugins

The easiest way to manage custom roles is with plugins like Members or User Role Editor. These provide a UI for creating, editing, and assigning roles without writing code.

// After activating the Members plugin, you can create roles via:
// Users > Roles > Add New

The memberpress plugin approach is fine for most users. However, if you are building a client site, consider defining roles in code so they are reproducible when you migrate the site.

// Define roles in a custom plugin so they travel with the codebase
function mytheme_add_custom_roles() {
    add_role(
        'media_manager',
        'Media Manager',
        array(
            'read'         => true,
            'upload_files' => true,
            'edit_posts'   => false,
        )
    );
}
add_action('init', 'mytheme_add_custom_roles');

Best Practices

Principle of Least Privilege

Assign the minimum role necessary for the user to do their job. If someone only needs to write drafts, make them a Contributor, not an Author. If they only need to manage their profile, make them a Subscriber.

No Administrator Accounts for Content Authors

A common mistake is making every content contributor an Administrator because "it is easier." This is extremely dangerous. If any of those accounts is compromised, the attacker has full control of your site. Keep Administrator accounts to an absolute minimum — ideally one or two people.

Regular Audits

Review your user list every few months. Remove accounts for people who no longer work on the site. Demote users who have changed roles. An old employee's admin account is a ticking time bomb.

Capability Checking in Custom Code

Whenever you build a custom feature, use current_user_can() to gate access. Never rely on role names directly — a future update might change role names, but capability names stay stable.

// Good: check capability
if (current_user_can('edit_others_posts')) { ... }

// Bad: check role name
$user = wp_get_current_user();
if (in_array('administrator', $user->roles)) { ... }

Role names can change. Capability names are part of the WordPress core API and are much more stable.

Common Mistakes

1. Making all users Administrators because it is convenient. Every Administrator account is a single compromised password away from total site takeover. Use the minimum role needed. If a user only writes posts, give them the Author role — not Administrator.

2. Not understanding the Contributor role limitation. Contributors cannot upload files. When you assign a contributor and they ask why they cannot add images, this is why. If they need to upload images, upgrade them to Author.

3. Using remove_role() without a backup plan. Removing a role deletes it permanently. If you remove the Contributor role and later want it back, you must re-create it manually. Make a database backup before modifying roles.

4. Granting activate_plugins to Editor roles. Some site owners give editors plugin activation access so they can install SEO tools. This is dangerous — a plugin can contain arbitrary code. Keep plugin management in Administrator hands only.

5. Forgetting about Super Admin on multisite. On a multisite network, an Administrator on one site cannot manage other sites and cannot install network-wide plugins. Use Super Admin sparingly — only for the person managing the entire network.

Practice Questions

1. An Editor on your site complains they cannot install a new SEO plugin. Why can't they, and what should you do? Answer: Editors do not have the install_plugins capability. Only Administrators and Super Admins can install plugins. You should install the plugin yourself as the Administrator.

2. A Contributor writes a post and presses "Publish" but the button does nothing. Why? Answer: Contributors have edit_posts but not publish_posts. They can only submit drafts. An Editor or Administrator must review and publish the post.

3. You want to allow Authors to moderate comments on their own posts but nothing else. Can you do this with default roles? Answer: No. Authors do not have moderate_comments by default. You would need to add this capability to the Author role using get_role('author')->add_cap('moderate_comments') or create a custom role.

Challenge: Design a user role system for a school website with these users: principal (full control), teachers (can write and publish their own posts about their classes), office staff (can manage pages like About and Contact but cannot install plugins), and parents (can read content and comment). Map each user to a role and explain any customizations needed.

FAQ

Mini Project

Build a role system for a multi-author blog:

1. Create a custom role called "Reviewer" with capabilities: read, edit_posts, edit_others_posts, but NOT publish_posts or delete_posts.
2. Add the upload_files capability to the Contributor role.
3. Remove the delete_others_posts capability from the Editor role.
4. Create three test users: one Manager (Administrator), two Reviewers, and verify that:
   • Reviewers can edit any post but cannot publish or delete
   • Contributors can now upload images
   • Editors cannot delete posts by other users
5. Write a short PHP script that lists all users and their roles on a custom admin page.

This exercise gives you hands-on experience with role management that you will use on every client site.

What's Next

Now that you understand user roles, move on to Managing Users to learn how to add users, edit profiles, and manage your user base. Then explore Multisite Network to see how roles work across multiple sites.

For more depth, see Security Hardening (audit user accounts regularly) and Custom Post Types (capabilities are critical for CPT permissions).