- Article
- 3 minutes read
- Reviewed August 3, 2026
Roles group permissions for WordPress users. Capabilities are the individual permissions checked when a user tries to perform an action.
Custom content can use the same capabilities as posts or define a dedicated set so teams can manage one content type without receiving unrelated access.
Roles and Capabilities
Administrator, Editor, Author, Contributor and Subscriber are default roles. Each role contains capabilities such as editing posts, publishing posts or managing categories.
Code should normally check a capability rather than a role name. Roles can be customized, while capabilities express the required action.
Post Type Capabilities
A post type registration can define a base capability type and explicit capabilities for singular and plural actions.
WordPress can map meta capabilities such as editing one specific record into primitive capabilities based on ownership and status.
Why Use Custom Capabilities?
Suppose event managers should publish events but should not edit blog posts. If Events reuse ordinary post capabilities, granting the needed access also grants access to posts.
A custom capability set allows roles such as Event Manager to receive only event-related permissions.
Common Capability Areas
- Edit own and others’ records.
- Publish records.
- Read private records.
- Delete own, others’ and published records.
- Create new records.
- Manage, edit, delete and assign taxonomy terms.
Ownership and Status
Permissions may differ for an author’s own draft, another user’s record, a published item or private content.
Test the complete matrix instead of confirming only that an administrator can access the screen.
Taxonomy Capabilities
Taxonomies have separate capabilities for managing, editing, deleting and assigning terms. This supports controlled vocabularies where most editors can assign terms but only information architects can create them.
Administration Menus Are Not Security
Hiding a menu item does not prevent direct requests to editing screens or REST endpoints. Every action must enforce capabilities on the server.
Nonces help protect intent and request origin but do not replace authorization.
REST API Permissions
Standard REST controllers apply content capabilities to create, update and delete requests. Custom endpoints need their own permission callbacks.
Never use a permission callback that simply returns true for protected operations.
Assigning and Removing Capabilities
Plugins may add capabilities on activation and remove them on uninstall, but removing capabilities during deactivation can disrupt sites that temporarily disable a plugin.
Document capability ownership and avoid overwriting an entire role definition when adding one permission.
Least Privilege
Give users the smallest set of capabilities required for their responsibilities. This limits mistakes and reduces the impact of compromised accounts.
Review access when roles change, contractors leave or a content type becomes more sensitive.
Testing Checklist
- Administrator and intended manager roles.
- Authors editing their own versus others’ records.
- Draft, published, private and trashed content.
- Creating, assigning and deleting taxonomy terms.
- Bulk actions and quick edit.
- Imports, REST requests and front-end forms.
- Direct URLs to hidden administration screens.
Frequently Asked Questions
Should code check a role name or capability?
Check capabilities. Roles are configurable containers and may differ between sites.
Can a custom post type have its own permissions?
Yes. Registration can define a custom capability type and capability mapping.
Does hiding a menu protect content?
No. Menu visibility is an interface choice; server-side capability checks provide authorization.