Security updates can expose assumptions in membership, editorial, LMS, ecommerce, and role-editor plugins. A custom role may look correct in wp-admin while a REST route, AJAX action, bulk edit, or multisite screen grants too much or blocks legitimate work.
Use this for sites with custom roles, membership tiers, store managers, editors, support agents, instructors, vendors, or multisite administrators.
Quick answer
Create disposable users for each business role, define the allowed and denied actions before testing, then run the same matrix through wp-admin, REST, AJAX, and the public workflow. Verify the capability check at the action boundary, not only menu visibility.
What to check first
- Export roles and capabilities before the update and compare them after activation hooks run.
- Create one test user for every high-risk business role and one no-role control.
- Test create, edit, publish, delete, export, user management, settings, and plugin-specific actions.
- Repeat sensitive actions through REST or AJAX when the plugin exposes those routes.
- Capture actor ID, route, requested object, capability decision, and resulting state.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Restore the minimum capability set from an approved role baseline. | Export roles and capabilities before the update and compare them after activation hooks run. | Every allowed fixture succeeds through the intended interface. |
| Patch plugin callbacks to check the specific capability and object ownership. | Create one test user for every high-risk business role and one no-role control. | Every denied fixture returns no sensitive data and creates no state change. |
| Protect REST and AJAX handlers with authentication, authorization, and request validation. | Test create, edit, publish, delete, export, user management, settings, and plugin-specific actions. | REST, AJAX, and wp-admin agree on the authorization boundary. |
| Remove orphaned capabilities only after confirming no active workflow depends on them. | Repeat sensitive actions through REST or AJAX when the plugin exposes those routes. | Role and capability exports match the approved post-fix baseline. |
Why this usually happens
- Plugins sometimes check a broad role name instead of the capability needed for the exact action.
- Menu hiding can make wp-admin look restricted while the underlying endpoint remains callable.
- Activation, migration, and role-editor plugins may add capabilities that persist after deactivation.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp role list --fields=role,name --format=table
wp cap list editor --format=table
wp user create audit_editor audit-editor@example.com --role=editor
# Run approved and denied fixtures, then remove the user.
wp user delete audit_editor --yes
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Editor content action | Editor edits assigned post | Allowed without settings or user-management access |
| Store manager order action | Manager updates test order | Allowed only for intended order operations |
| Subscriber privileged action | Subscriber calls protected REST route | 403 or equivalent denial with no state change |
| No-role control | Authenticated user without business role | No inherited plugin privilege |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Restore the minimum capability set from an approved role baseline.
- Patch plugin callbacks to check the specific capability and object ownership.
- Protect REST and AJAX handlers with authentication, authorization, and request validation.
- Remove orphaned capabilities only after confirming no active workflow depends on them.
- Rerun the matrix and record both allowed and denied controls.
Decision rule
If an unauthorized role changes state, stop rollout and treat it as an access-control defect. If only menu visibility is wrong but endpoints enforce the correct capability, classify it as an interface regression and fix without weakening authorization.
Production verification checklist
- Every allowed fixture succeeds through the intended interface.
- Every denied fixture returns no sensitive data and creates no state change.
- REST, AJAX, and wp-admin agree on the authorization boundary.
- Role and capability exports match the approved post-fix baseline.
Field notes
- Test object ownership because edit_others_posts and edit_posts are different boundaries.
- Use disposable content and users so denied actions can be attempted safely.
- Snapshot the roles option before changing it, because role edits affect every account using that role.
Questions teams ask during testing
Should plugins check roles or capabilities?
Capabilities are the intended WordPress authorization primitive because roles can be customized and shared across different businesses.
Why test REST separately?
A plugin can secure wp-admin correctly while exposing a different permission callback on its REST route.
What is the best control?
A no-role or subscriber test user attempting the same sensitive action provides a clear denied control.
Mistakes to avoid
- Do not infer access from whether a menu item is visible.
- Do not test destructive actions against real users or orders.
- Do not grant administrator to solve one missing plugin capability.
- Do not remove unfamiliar capabilities until their owning plugin is identified.
What to tell the client or owner
Share a table of role, action, expected result, actual result, endpoint, and resulting object state. Avoid screenshots alone because they do not prove the server decision.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test a WordPress role regression.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references