How to manage user roles and permissions in WordPress
Manage users from Users > All Users, then assign the least powerful role that lets each person do their work. WordPress handles common roles without a plugin, but custom capabilities, WooCommerce permissions, and multisite controls usually need code or a role-management plugin.
- 01Match work to a role
- 02Assign a user role
- 03Use capabilities for exceptions
- 04Test the actual workflow
- 05Review risky permissions
- 06Take the fast route
What you need
- Administrator access to the WordPress site
- A list of what each user must be able to do
- A test account or staging site for permission checks
Match work to a role
Start with the smallest built-in role that fits the job. Subscribers can manage their profiles, Contributors can write posts but not publish them, Authors can publish their own posts, Editors can manage other users’ content, and Administrators manage nearly all settings on a single-site installation. Multisite adds the Super Admin role for network-level tasks.
Do not assign Administrator simply because someone needs to publish posts. Extra capabilities can expose plugins, themes, settings, users, and site data.
Assign a user role
Go to Users > All Users, select a user, choose the required role in the role selector, and save the change. For a new account, go to Users > Add New and choose the role before creating the user.
To control the role given to future accounts, go to Settings > General and change the default user role. This changes the default for new users, not existing accounts.
Use capabilities for exceptions
A role is a group of capabilities, while a capability is a specific permission such as edit_posts, publish_posts, upload_files, or edit_others_posts. If a user needs one exception, add or remove that capability rather than making them an Administrator.
For a custom role, WordPress provides add_role(). To change an existing role, retrieve it with get_role() and use the role’s add_cap() or remove_cap() method. Put role-creation code in a plugin activation hook or another controlled one-time condition; running it on every request is an easy way to create confusing maintenance problems.
Test the actual workflow
Create a test user with the same role and try the real job: create a post, edit someone else’s post, upload media, submit content for review, manage comments, or edit a page. Check both the dashboard and the front end.
A role can appear correct while a plugin or theme blocks a screen. Editors normally have capabilities for other users’ posts and pages, so if that stops working, investigate changed capabilities or a plugin conflict before granting broader access.
Review risky permissions
Pay particular attention to permissions that affect the whole site, including plugin and theme management, user management, unfiltered HTML, and Site Editor access. The edit_theme_options capability can provide Site Editor access but may also expose other theme-related administration, so grant it only when the job requires it.
Remove unused accounts, review administrator access regularly, and document any custom role. Keep a recovery administrator account available before changing permissions on a live site.
Take the fast route
For a few users and standard publishing tasks, the built-in role selector is the fastest route and is usually enough. If you need fine-grained controls for custom post types, WooCommerce, content restrictions, or multisite access, use a role-management plugin instead of maintaining custom code.
PublishPress Capabilities Pro is a suitable option when you need an interface for creating and modifying roles, controlling detailed capabilities, and managing permissions across more complex WordPress sites. Apply changes gradually, then retest each important workflow.
Let PublishPress Capabilities Pro do it
Fine-grained role and capability controls for content, custom post types, WooCommerce, and multisite access.
Sources
- wordpress.org /documentation/article/roles-and-capabilities/?utm_source=op…
- developer.wordpress.org /reference/functions/add_role/?utm_source=openai
- wordpress.org /support/topic/no-admin-access-for-authors-editors/?utm_sour…
Questions
- What is the difference between a WordPress role and a capability?
- A role is a collection of permissions assigned to a user, while a capability is one specific permission. For example, Author is a role and <code>publish_posts</code> is a capability. WordPress combines a user’s role capabilities to decide which dashboard screens, actions, and content they can access.
- Can I manage roles without a plugin?
- Yes, WordPress includes built-in roles and lets you assign them from the Users screens without a plugin. Creating or changing custom roles is also possible with code using functions such as <code>add_role()</code> and methods such as <code>add_cap()</code>. A plugin becomes useful when you need an interface or many detailed permission changes.
- Why can an Author not publish someone else’s post?
- Authors can publish and manage their own posts, but they do not normally have the capabilities for editing or publishing other users’ posts. Those permissions are associated with capabilities such as <code>edit_others_posts</code> and are normally available to Editors and Administrators. Grant only the additional capability the workflow requires.
- Why does a user still see a permission error after I change their role?
- A permission error can come from a missing capability, a plugin or theme conflict, or a custom restriction that hides dashboard access. Test the account against the required capabilities, then temporarily check for conflicts on a staging site. Do not solve an isolated error by making the user an Administrator until you know which permission is missing.
- How should I manage roles on WordPress multisite?
- Treat multisite permissions separately from single-site permissions. Super Administrators manage network-level features, while site-level roles control access within an individual site. A capability available to a single-site Administrator may be restricted to Super Administrators in multisite, so test access on the specific site and network areas involved.