Key takeaways
- A single WordPress site has five default roles: Administrator, Editor, Author, Contributor and Subscriber. Super Admin exists only on Multisite.
- WordPress checks capabilities such as publish_posts, upload_files and manage_options. It does not check the role name, so plugins that add or demand capabilities change what a role can do.
- WooCommerce adds Customer and Shop Manager. Shop Manager can handle products, orders, coupons, reports and customer details, so it is not a read-only staff role.
- wp role reset –all and User Role Editor’s Reset both wipe capabilities that plugins and site owners added. Back up first and reset one role at a time.
- Hosting-portal access, page privacy and firewall 403 errors sit outside WordPress roles. Changing a role will not fix them.
A writer can’t upload her own hero image. A store assistant can issue refunds nobody meant him to touch. A contractor still has Administrator two years after the project ended. Each of these is a role decision, and most were made in a hurry from the dropdown on the Add New User screen.
Roles look like job titles. They are permission bundles, and the bundle on your site may not match the one in the documentation. This article covers what each default role can do, why plugins change the answer, and how to give people the narrowest access that still lets them work. On a Multisite network the same rules apply to each site separately, which is why our article on what a multisite manager manages treats users and roles as two separate things.
What a WordPress user role actually is
A role is a named set of capabilities. A capability is one permission: publish_posts, upload_files, manage_options (site settings), edit_theme_options (the Site Editor, menus and widgets), install_plugins, promote_users (changing other people’s roles). When someone clicks a button, WordPress checks the capability, not the role’s name.
That difference matters. WordPress.org’s Roles and Capabilities documentation says plugins and themes can add roles and capabilities, so two sites can both have an “Editor” that behaves differently. The role’s name tells you the starting point. The capability list tells you what the person can actually do.
What each default role can do
On a single self-hosted site there are five default roles. A sixth, Super Admin, appears only on Multisite.
| Role | Can do by default | Cannot do by default | Usual fit |
|---|---|---|---|
| Super Admin (Multisite only) | Everything, across the whole network | Nothing withheld | The network owner |
| Administrator | Settings, plugins, themes, users, all content | On Multisite, some capabilities are reserved for the Super Admin | Whoever maintains the site |
| Editor | Publish and manage all posts and pages, including other people’s; moderate comments | Plugins, themes, users, site settings | Content lead |
| Author | Publish and manage their own posts; upload media | Pages; other people’s posts | Writer who publishes their own work |
| Contributor | Write and edit their own posts | Publish; upload media | Writer whose work gets reviewed |
| Subscriber | Read; manage their own profile | Anything else in the dashboard | Members, commenters |
Online guides disagree on whether WordPress has five or six roles because some describe WordPress.com, the hosted service. Its support documentation lists an extra Viewer role that self-hosted WordPress doesn’t have. When a guide’s advice doesn’t match your dashboard, check which platform it was written for.
Most role decisions happen between Editor, Author and Contributor
Contributor and Author differ in two capabilities: publishing and uploading. A Contributor’s draft arrives without its images because the role has no upload_files. If your writers supply their own photos, Author is usually the right role. Moving files back and forth by email for every post is the wrong fix.
Author and Editor differ in scope. An Editor can change or delete anyone’s posts and every page on the site. People often hand Editor to every writer because one of them needs to update the About page. Authors can’t edit pages by default, so that one task pulls the whole team up a level. Give Editor to the person who owns the content, and keep the rest of the team on Author or Contributor.
Why a role’s name doesn’t tell you what someone can do
Plugins add their own capabilities, and the default roles don’t have them. In a WP Job Manager support thread, users with a custom Consultant role got “Sorry, you are not allowed to access this page” when they opened job listings. The missing capability was edit_job_listings. Granting the general edit_posts capability made the error go away, but it also gave those users access to posts they were never meant to edit.
Some plugins lock features behind a broad capability. In another support thread about a slider plugin, an Editor couldn’t even see the slider menu because the plugin required manage_options. Giving Editors that capability would let them use the sliders. It would also open every site setting to them. When a plugin forces that choice, the better answer is to ask its author for a feature-specific capability.
WooCommerce is the biggest example. Its Roles and Capabilities documentation says it adds a Customer role and a Shop Manager role, and gives Administrators store capabilities. Shop Managers can manage products, orders, coupons, reports and customer details. That makes it a powerful role, not a safe default for someone who only needs to pack orders.
WooCommerce also shows that one account can hold more than one role. Its guide to Shop Manager editable roles says Shop Managers can edit Customer-only accounts by default. To edit any other account, every role on that account has to be on an allowlist. The woocommerce_shop_manager_editable_roles filter changes that allowlist. It does not give Shop Managers any WordPress user-management capabilities.
How to choose the right role for each person
Start from the tasks, not the job title. “Marketing assistant” can mean writing blog posts at one company and running the store at another.
- List what the person does in a normal week. For example: publish posts, swap a banner image, edit product descriptions, reply to comments.
- Pick the lowest default role that covers the whole list. If two roles both work, take the lower one.
- If one task is missing, grant that one capability. Add it to a custom role. Don’t move the person up a whole role, and don’t hand out
manage_optionsor Administrator to cover one task. - Test it as that user. Create a test account with the role and log in from a private browser window. If you test from your Administrator account, you won’t see the gaps a real user hits.
- Write down why each role above Author was granted. A note such as “Editor for launch week” makes it easier to remember to take temporary access back.
Check one more setting. Under Settings → General, New User Default Role decides which role every new registration gets. If “Anyone can register” is turned on, that role goes to strangers, so keep it at Subscriber, or Customer on a store. Changing it only affects future signups. You change existing accounts under Users → All Users.
How to change a role and see what it really grants
In the dashboard, go to Users → All Users. Tick one or more users, choose a role from the “Change role to…” dropdown, and click Change. To change one user, you can also open their profile and use the Role field. You need the promote_users capability to do either, and by default only Administrators have it.
The dashboard won’t show you the full capability list for a role. With SSH access and WP-CLI you can see it directly:
wp role list
wp cap list editor
wp user list --role=administrator --fields=ID,user_login,user_email
wp user set-role 42 author
The third command is the useful one for an audit. It lists every Administrator, and on older sites that list is usually longer than anyone expects.
When a custom role is the right answer, and what breaks it
Create a custom role when no default role fits without giving too much away. Examples include a copy editor who fixes other people’s posts but can’t publish new ones, or store staff who need orders but not settings. The common tools are role-editor plugins. User Role Editor lists 700,000+ active installations in the WordPress.org directory, and Members lists 300,000+. Most people clone an existing role and remove capabilities from the copy.
In code, register the role once, when the plugin is activated. The Plugin Handbook warns that removing and re-adding roles on every load when nothing has changed can “degrade performance considerably.”
register_activation_hook( __FILE__, function () {
add_role( 'copy_editor', 'Copy Editor', array(
'read' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'edit_published_posts' => true,
) );
} );
register_deactivation_hook( __FILE__, function () {
remove_role( 'copy_editor' );
} );
Custom roles break in three common ways:
- Resets. Hostinger’s WP-CLI guide warns that
wp role reset --allresets every role, including roles created by plugins, and removes custom capabilities. User Role Editor’s own documentation says its Reset returns roles to a fresh-install state and loses changes made by you or by plugins. Take a backup, then reset only the role that is broken:wp role reset editor. - Another plugin overwrites your changes. If a role change looks saved and then disappears, another plugin may be re-registering that role. In a Members support thread about this, the advice was to disable plugins one at a time until the change stays.
- Hiding a menu is not restricting access. Admin menu editors hide items in the dashboard. A user who knows the URL can still reach the screen if their role has the capability. Use menu hiding for a tidier dashboard and capabilities for security.
What WordPress roles don’t control
Several problems look like role problems but aren’t.
Hosting accounts. Hosts run their own user systems. Kinsta’s guide to client access management treats MyKinsta access and WordPress roles as two separate things to assign. WP Engine has its own User Portal users and roles. Removing someone’s WordPress account doesn’t remove their hosting, SFTP or database access. When someone leaves, check both.
Who can see a published page. Roles control what logged-in users can do in the dashboard. They don’t decide who can view a public URL or whether search engines index it. For private content, use a login or a password. Our guide on password protecting a WordPress page explains which one fits which situation.
Some “not allowed” errors. A 403 can have causes other than a missing capability. In a Ditty support thread, the reply explained that the editor saves through the REST API. A 403 there could be rest_forbidden, which means a capability really is missing. It could be rest_cookie_invalid_nonce, which means the session has expired and logging out and back in fixes it. Or it could be a firewall’s block page. Check the response in your browser’s network tab before you change anyone’s role.
Who should hold Administrator on a client site
This is where roles become a business question. Agencies worry that a client with Administrator rights will install a plugin and break the site, leaving them with repair work they can’t bill for. Owners worry about being locked out of a site they paid for. Both concerns are reasonable, and neither is solved by sharing one Administrator login.
The setup that holds up: the client owns the domain and hosting and has an Administrator account of their own, even if they rarely use it. Their day-to-day staff get Editor or a narrower role. The agency’s developers get named accounts, not a shared one. Plugin changes are agreed before they happen and made after a backup. Every account is removed when the engagement ends. The weak spot that our article on common WordPress security issues keeps coming back to is the old contractor whose admin login still works.
Clients often push for Administrator because every small change otherwise waits in the agency’s queue. Handling those routine client requests is the work SiteSelf’s page for agencies describes.
Frequently asked questions
Can a WordPress user have more than one role?
Yes, at the data level. The standard dashboard shows one role per user, but plugins can assign several, and WooCommerce’s documentation describes accounts with more than one role. The user gets the combined capabilities of all their roles.
What role should a freelance writer get?
Contributor if someone reviews their drafts before publishing, Author if they publish their own posts. Contributor can’t upload images, so pick Author if they supply their own photos. Editor is too much for a writer who only handles their own work.
Does a developer need Administrator?
For plugin, theme or settings work, usually yes, because those tasks need Administrator-level capabilities. Give them a named account of their own, agree on the scope of work, take a backup first, and remove or downgrade the account when the work is done. Code and file work may also need hosting access, which is a separate account.
Can I give WooCommerce staff a “view orders only” role?
Not with the built-in roles. WooCommerce adds only Customer and Shop Manager, and Shop Manager covers far more than orders. Clone Shop Manager with a role editor, remove what the job doesn’t need, and test the result with a staff account before you hand it over.
Does WordPress record who changed a user’s role?
Core WordPress doesn’t keep an activity log of role changes. If you need that record, install an activity log plugin. Check the Administrator list regularly with wp user list --role=administrator, because a new Administrator you didn’t create is also a sign of a hacked site.
Why do my role changes not stick?
Another plugin is probably re-registering the role when it loads. Disable plugins one at a time until the change stays, then make the change through that plugin’s own settings or hooks. Don’t use a full reset to fix it, because a reset wipes every other custom capability too.
Leave a Reply