WordPress Development
WordPress User Roles and Capabilities: Custom Roles, Permissions, and Access Control
WordPress ships with five roles but most sites need more granular access control. Here is how the capability system works and how to configure exactly what each user can do.
WordPress ships with five user roles, each with different capabilities. Most WordPress sites use only one or two of these. Understanding the full capability system — and knowing how to create custom roles and capabilities — allows you to build precise access control for any multi-user WordPress workflow.
The five default WordPress roles
| Role | Key capabilities | Best for |
|---|---|---|
| Administrator | All capabilities — full site control | Site owners, developers |
| Editor | Create, edit, publish, delete any content; manage categories | Content managers, senior team members |
| Author | Create, edit, publish, delete own posts only | Regular content contributors |
| Contributor | Create and edit own posts; cannot publish; cannot upload files | Guest contributors, junior team members |
| Subscriber | Read content only; manage own profile | Membership sites, comment contributors |
Shop Manager is a custom role added by WooCommerce. It has most admin capabilities scoped to WooCommerce management (orders, products, reports, coupons) without full WordPress administrator access. Assign this role to store staff who need WooCommerce access but should not modify theme or plugin settings.
How WordPress capabilities work
Every action in WordPress is gated by a capability check using current_user_can('capability_name'). Capabilities are named strings: ‘edit_posts’, ‘publish_posts’, ‘manage_options’, ‘activate_plugins’. Roles are collections of capabilities. The distinction matters when you want to modify what specific users can do without creating entirely new roles.
Creating custom roles
Custom roles are useful when default roles do not match your team structure. Common custom role use cases:
- SEO Manager: can manage Rank Math settings and edit any post, but cannot activate plugins or modify theme
- Product Manager: can manage WooCommerce products but not orders or WooCommerce settings
- Client: can view specific private pages or custom post types relevant to their account
- Agency Sub-admin: has admin capabilities except cannot delete the site or modify critical settings
Register custom roles using add_role() in your plugin or child theme. Include the role slug, display name, and an array of capabilities. Remove roles using remove_role().
Modifying existing roles
Modify existing roles using get_role() followed by add_cap() or remove_cap(). Hook this to init and use a version flag or option to ensure it only runs once (add_cap and remove_cap modify the database on every call if not guarded).
Custom capabilities for plugins
Plugins can register and check for entirely custom capabilities. This is the correct pattern for plugin-specific access control:
Use descriptive, namespaced capability names: ‘my_plugin_manage_settings’, ‘my_plugin_view_reports’. Namespacing prevents conflicts with other plugins.
On plugin activation, add your custom capabilities to the roles that should have them using get_role()->add_cap().
Gate all plugin functionality behind current_user_can('my_plugin_manage_settings') checks. Never trust role names directly — always check capabilities.
Remove your custom capabilities from all roles in your plugin deactivation hook to clean up after your plugin.
The Members plugin for role management
The Members plugin by MemberPress provides a visual interface for managing WordPress roles and capabilities without code:
- Create, edit, and delete roles from the WordPress admin
- Toggle individual capabilities on and off per role via a visual checkbox interface
- Clone existing roles as a starting point for custom roles
- Restrict individual posts and pages to specific roles (content restriction without a full membership plugin)
- Import and export role configurations between WordPress installations
Restricting admin menu items by role
Use the Adminimize plugin or custom code to hide specific admin menu items per role. This prevents role confusion by showing staff only the menu items relevant to their responsibilities:
- Editor role: hide Appearance, Plugins, Settings, Tools
- Author role: hide Comments, Appearance, Plugins, Settings, Tools
- Shop Manager role: hide Appearance, Plugins, Settings, Tools, Posts
- SEO Manager role: hide Appearance, Plugins, Media, Comments (if not needed)
Need custom WordPress roles and access control configured?
Simple Automation Solutions configures custom user roles, capabilities, and admin interfaces for WordPress sites and multisite networks worldwide.
Frequently asked questions
Can I limit what pages an Editor can edit in WordPress?+
By default, Editors can edit any post or page on the site. To restrict Editors to specific content: (1) use the Members plugin’s Content Permissions feature to restrict individual posts/pages to specific roles; (2) use a capability plugin to create a custom Editor role that only has ‘edit_posts’ (own posts) rather than ‘edit_others_posts’; (3) for complex requirements, use the PublishPress Capabilities plugin which provides per-post-type capability control without custom code.
What is the difference between a role and a capability in WordPress?+
A capability is a single permission — a named string like ‘edit_posts’ or ‘manage_options’ that represents the ability to do a specific thing. A role is a named group of capabilities — ‘Editor’, ‘Author’, ‘Administrator’. WordPress checks capabilities, not roles: current_user_can('edit_posts') checks whether the current user has that capability, regardless of which role grants it. This distinction matters when you want to give a specific user a capability outside their role, or create custom roles with a precise set of capabilities.
How do I give a specific user administrator capabilities without making them an administrator?+
Use $user->add_cap('manage_options'); to grant a specific capability to a specific user object, independent of their role. Capabilities granted directly to users override role-based capabilities. This allows surgical access: give a trusted Editor the ability to manage plugin settings without full Administrator access. Manage user-specific capabilities via the Members plugin interface or programmatically via the Users API.
