A WordPress role is just a named bundle of capabilities, and capabilities are the thing WordPress actually checks. edit_posts, publish_posts, moderate_comments, edit_users — every permission decision in the codebase tests one of these, not a role name. Once that clicks, customising permissions stops being a plugin question.
The default roles cover most sites, and most sites do not use them properly. The common failure is straightforward: everyone gets Administrator because it is easier than working out which role they need, and now six people can install plugins, edit other people’s posts, and change the site URL. Every one of those accounts is also a full compromise if its password leaks.
Table of contents
- The five default roles
- Capabilities are what actually gets checked
- Changing what a role can do
- Deciding who gets what
- Multisite is a different model
- Roles are not a security boundary for data
- How this fits the rest of the stack
- FAQ
The five default roles
- Administrator — everything on a single site. Install and delete plugins and themes, edit files, manage users, change any setting. On multisite this is narrower, with a Super Admin above it holding network-wide powers.
- Editor — full control over all content. Publish, edit, and delete anyone’s posts and pages, manage categories and tags, moderate comments. Cannot touch plugins, themes, users, or settings.
- Author — publish, edit, and delete their own posts, and upload files. Cannot touch anyone else’s content.
- Contributor — write and edit their own drafts, but cannot publish and cannot upload media. Their work needs an Editor or Administrator to go live.
- Subscriber — read, and manage their own profile. The default for new registrations.
The default role for new users is set in Settings, then General. It ships as Subscriber and should stay there on any site with open registration — a misconfiguration setting it to Author or worse is a well-known way to end up with a site full of spam posts.
The gap that catches people most often is Contributor’s inability to upload media. It reads as a bug to a new writer, who cannot add an image to their own draft. It is deliberate, and the answer is usually Author rather than a workaround.
Capabilities are what actually gets checked
Roles are convenience. The code checks capabilities, using current_user_can():
if ( current_user_can( 'edit_posts' ) ) {
// show the editor
}
if ( current_user_can( 'edit_post', $post_id ) ) {
// meta capability -- resolves per-post ownership
}There is an important distinction hidden there. edit_posts is a primitive capability: can this user edit posts in general. edit_post with a specific ID is a meta capability, which WordPress maps at runtime to the primitives needed for that particular post — checking ownership, published state, and whether it is locked. Always check the meta capability with an object ID when the decision is about one specific item.
The capabilities worth knowing by name because they separate the roles:
edit_posts— has the editor at all. Contributor and up.publish_posts— can push their own work live. Author and up.edit_others_posts— can edit anyone’s content. Editor and up.upload_files— media library. Author and up.manage_options— site settings. Administrator only, and the usual gate for plugin settings pages.edit_users— user management. Administrator only.install_plugins/edit_themes— code execution, effectively. Administrator only.
Changing what a role can do
You can add or remove individual capabilities from an existing role, or create an entirely new role, with four core functions: add_cap(), remove_cap(), add_role(), remove_role().
// let Editors manage the site's menus
function site_adjust_editor_caps() {
$editor = get_role( 'editor' );
if ( $editor ) {
$editor->add_cap( 'edit_theme_options' );
}
}
add_action( 'init', 'site_adjust_editor_caps' );There is a trap in that snippet that catches nearly everyone the first time. These functions write to the database — they are not runtime filters. Running add_cap() on every page load rewrites the same row on every request, which is pointless work. Worse, removing the code later does not remove the capability, because it was persisted.
The correct pattern is to run it once, on plugin or theme activation, and to run the corresponding removal on deactivation:
register_activation_hook( __FILE__, function () {
$role = add_role( 'shop_manager_lite', 'Shop Manager (Lite)', array(
'read' => true,
'edit_posts' => true,
'edit_published_posts'=> true,
'upload_files' => true,
) );
} );
register_deactivation_hook( __FILE__, function () {
remove_role( 'shop_manager_lite' );
} );If you prefer not to write code, several plugins provide a checkbox grid over the same functions. They are a fine choice for a site somebody else maintains — just be aware they are writing the same persisted database rows, so uninstalling the plugin does not necessarily restore the original permissions.
Deciding who gets what
The rule that prevents most trouble: give the least role that lets someone do their job, and treat Administrator as a small set of named people rather than a default.
- Writes and publishes their own articles — Author.
- Writes, but should be reviewed before publishing — Contributor.
- Manages the whole content operation — Editor. This covers far more people than teams assume, and it removes the ability to break the site.
- Installs plugins, changes settings, manages users — Administrator. Should be one or two people.
- A developer or agency working temporarily — Administrator, with the account removed when the engagement ends. Not left in place for two years.
Editor is the underused role. Most people who are given Administrator actually need Editor plus perhaps one extra capability, and granting that one capability is a four-line snippet. The difference in blast radius when an account is compromised is enormous.
Audit periodically. wp user list --role=administrator takes a second, and an admin account belonging to a contractor who left in 2024 is not an unusual finding.
Multisite is a different model
On a network, the roles above apply per site, and a new tier sits above them.
- Super Admin — manages the entire network: creating and deleting sites, network-wide plugins and themes, all users. Not visible as a role on single-site installs.
- A site Administrator on a multisite network cannot install plugins or themes by default; that is a network-level power.
- Users exist once across the network but hold different roles on different sites.
If you are adding a capability on multisite, be explicit about whether it should apply on one site or all of them. add_cap() on a role affects that site’s role definition, which on a network means you may need to iterate the sites — a detail that produces genuinely confusing bugs when missed.
Roles are not a security boundary for data
Worth stating plainly. Roles control what the WordPress admin interface allows. They are not encryption and they are not a database-level permission system.
Anyone with database access sees everything regardless of role. Anyone with file access can add a snippet granting themselves any capability. A plugin with a vulnerability can escalate privileges regardless of how carefully you configured roles — privilege escalation bugs in popular plugins are a recurring category, and they bypass the role system entirely rather than working within it.
So roles are one layer. The others are keeping plugins updated and minimal, strong authentication with two-factor on admin accounts, correct file permissions, and a disabled dashboard file editor. Configuring roles carefully on a site running six abandoned plugins is tidying a room with an open window.
How this fits the rest of the stack
Roles decide what people can do inside WordPress; the platform decides what happens when someone does something wrong. Managed WordPress on RunxBuild puts a file manager and a database browser in the dashboard, so checking which accounts hold which capability, or fixing a permissions change that went badly, does not require an SFTP client and a separate database GUI. Plans start at $3 a month, with the file manager and database browser included rather than behind a support ticket. WordPress database on RunxBuild covers browsing tables and running SQL, and the RunxBuild hosting calculator shows the site, storage, and bandwidth as separate figures when you are working out what a multi-author site costs.
Useful related references:
- Squarespace vs WordPress: The Question Behind the Question
- WordPress Maintenance Services: What You Are Actually Paying For
- WP-CLI: The Commands That Make WordPress Administration Bearable
- Services on RunxBuild
FAQ
What are the default WordPress user roles?
Administrator (full control of one site), Editor (all content, no settings or plugins), Author (own posts plus media uploads), Contributor (own drafts, cannot publish or upload), and Subscriber (read and manage own profile). Multisite adds Super Admin above all of them.
What is the difference between a role and a capability?
A capability is a single permission like edit_posts or manage_options, and it is what WordPress code actually checks. A role is a named bundle of capabilities. Customising permissions means adding or removing capabilities, which you can do without creating a new role.
How do I change what an Editor can do?
Use add_cap() or remove_cap() on the role object. Critically, run it once on plugin or theme activation rather than on every page load — these functions write to the database rather than filtering at runtime, so removing the code later does not remove the capability.
Why can a Contributor not upload images?
Contributors deliberately lack the upload_files capability, so they can draft posts but not add media. It is by design rather than a bug. If a writer needs to add their own images, Author is usually the right role rather than granting the capability separately.
Are WordPress roles a security boundary?
Only within the admin interface. Anyone with database or file access bypasses roles entirely, and privilege escalation vulnerabilities in plugins circumvent them rather than working within them. Roles are one layer alongside updates, strong authentication, file permissions, and a disabled dashboard file editor.