WordPress User Roles and Permissions, Properly Set Up

• Subscriber: reads, and manages their own profile. Nothing else.
• Contributor: writes and edits their own posts but cannot publish them, and cannot upload files.
• Author: writes, publishes and deletes their own posts, and uploads files.
• Editor: full control over all content — anyone's posts and pages, categories, comments. No access to plugins, themes, users or settings.
• Administrator: everything, including installing plugins and themes, editing code through the dashboard, changing settings and managing users.
• On multisite there's also Super Admin, which spans the whole network, and site Administrators lose some of their single-site powers.

The gap between Editor and Administrator is much wider than it looks. Editor is content permissions. Administrator is the ability to execute arbitrary code on your server.

An administrator can install a plugin, and a plugin is PHP. They can also edit theme and plugin files directly through the dashboard editor, if it hasn't been disabled. So a compromised administrator account is not 'someone can change our content' — it's 'someone can run whatever they like on our server, read the database, and install a backdoor'.

That's why the recurring advice is 2FA on administrators specifically, and why the number of administrator accounts is a meaningful security metric on its own.

A role is nothing more than a named bundle of capabilities. Editor is a set that includes edit_others_posts and publish_pages but not install_plugins. Capabilities are the real permission system; roles are a convenience on top.

This has a practical consequence for anyone writing code: always check capabilities, never role names. current_user_can('edit_posts') is correct. Checking whether a user's role is 'editor' breaks on any site with custom roles, and breaks again when a plugin grants a capability to a role you didn't anticipate.

For code acting on a specific object, check against that object: whether a user can edit this particular post, not whether they can edit posts generally. On a multi-author site those are very different questions.

The built-in roles rarely fit exactly. A common need is someone who manages products but shouldn't touch settings, or who moderates comments and nothing else, or who can edit pages but not create them.

Create a custom role with exactly the capabilities that job needs. Start from the nearest built-in role, then add and remove individual capabilities rather than starting from scratch — it's easier to reason about and less likely to miss something.

Define roles in code, in a site-specific plugin, rather than through a UI plugin that stores them in the database. Roles are stored in wp_options, so a UI-created role exists on production and not on staging unless someone remembers to recreate it. In code, they deploy with everything else.

Remember that adding a role doesn't remove capabilities from existing ones. Moving someone from Administrator to a custom role means changing their assignment, not just creating the role.

• Give the lowest role that lets someone do their job, and increase it when they hit a wall rather than pre-emptively.
• Most people who have Administrator only need Editor. Ask what specifically they can't do with Editor.
• Developers and agencies need Administrator while working. Remove it when the engagement ends.
• One account per person, always. Shared logins make it impossible to attribute an action or revoke one person's access.
• Service accounts for integrations, with their own minimal role, never an administrator account shared with a script.
• Contributors for external writers, so nothing publishes without review.

User lists accumulate. People leave, agencies finish, a plugin creates an account, a temporary access grant becomes permanent because nobody revoked it.

• List every user with their role, and confirm you recognise each one.
• Check for administrator accounts you didn't expect. This is the single highest-signal check on the list — an unexplained administrator is a strong indicator of compromise.
• Remove accounts for anyone no longer involved, reassigning their content rather than deleting it.
• Check whether anyone's role has drifted upward without a reason.
• Confirm 2FA is enabled on every remaining administrator.
• Look at when each account last logged in. Dormant privileged accounts are pure risk.

When you delete a WordPress user, it asks whether to delete their content or reassign it. Reassign it, to a house account or an active editor. Deleting content along with the user is irreversible and catches people out regularly.

For someone who may return, consider changing their role to Subscriber and disabling the account rather than deleting it. That removes the access while keeping the attribution intact.

• Set DISALLOW_FILE_EDIT in wp-config.php. This removes the theme and plugin editors from the dashboard, so a compromised administrator session can't immediately write PHP.
• Consider DISALLOW_FILE_MODS on sites where plugins should only be deployed through version control — it blocks installation and updates from the dashboard entirely.
• Restrict the REST API's users endpoint, which otherwise publishes account slugs as a ready-made username list.
• Enforce 2FA on administrators and editors.
• Keep an audit log of administrative actions, so a problem can be reconstructed rather than guessed at.

Plugins add roles. WooCommerce adds Customer and Shop Manager; membership and LMS plugins add their own. Shop Manager in particular is worth understanding, because it can manage products, orders and customers — including customer addresses and order histories.

Review what each added role can actually do rather than assuming the name describes it. And remember that these roles persist in the database if the plugin is removed, which is another reason the quarterly audit is worth doing.