When a user’s role and capabilities get out of sync — an editor who suddenly can’t edit, a shop manager missing order access, a custom role that never worked quite right — the cause is almost always a mismatch between what WordPress thinks that role can do and what a plugin or customization expects it to be able to do, not a WordPress bug.
Compare what the role should allow against what actually shows
In your dashboard, go to Users, open the affected account, and note its assigned role. Then check whether that role’s expected capabilities (visible in most role-management plugins, or by testing specific actions) actually match what the user can and can’t do. A mismatch there confirms this rather than a different account-specific problem.
User role & capability repair
A role that's stopped granting the capabilities it should, found and corrected.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| A user’s role doesn’t grant the capabilities it should | This fix covers it |
| You need an entirely new custom role created from scratch | Custom role creation from supplied spec |
| The issue is admin menu items showing that shouldn’t, not core capabilities | Admin menu & dashboard access cleanup |
| Two plugins seem to be fighting over what a role can do | Capability conflict between plugins, the more specific version of this |
What you are seeing
- A user unable to perform an action their role should normally allow
- Menu items or options missing that should be visible for their role
- The issue possibly affecting only one user, or every user with a specific role
- The problem possibly appearing suddenly, often after a plugin update
Common causes
- A plugin update resetting or altering capabilities tied to a role
- A custom role created without every capability it was actually meant to include
- Multiple plugins each modifying the same role’s capabilities in conflicting ways
- A caching issue serving a stale version of role permissions
- Direct database changes made previously that didn’t fully propagate as intended
What we do
- Confirm exactly which capabilities are missing or incorrect for the affected role
- Identify what’s actually setting those capabilities currently, including any conflicting sources
- Correct the role definition to include everything it should
- Test the specific actions the user needs to confirm they now work
- Check other users with the same role aren’t affected by the same gap
- Document the correction for future reference
What is included
- The specific role or capability mismatch identified and corrected
- Testing confirming the affected user can now perform expected actions
- A check for other users sharing the same affected role
- The pre-fix backup, kept for 30 days
Not included
- Creating an entirely new custom role, a separate, related fix
- Resolving a conflict between plugins in the general case, unless that’s confirmed as the cause
- Broader user audits beyond the specific reported issue
- Ongoing adjustment as you add new plugins that modify roles
Questions about this fix
Why would this happen suddenly with no changes I'm aware of?
A plugin update is one of the most common causes — plugins can quietly alter role capabilities as part of their own update process, without any deliberate change on your end.
Does this affect just one user or everyone with the same role?
Typically everyone sharing that role is affected the same way, since capabilities are tied to the role definition, not the individual account, unless something else is happening at the account level specifically.
Could a plugin I use intentionally be changing this role's capabilities?
Yes, some plugins deliberately modify default role capabilities as part of their function — we check for this specifically, since the fix differs from a simple accidental misconfiguration.
Will this happen again after future plugin updates?
It's a genuine risk if the same plugin is the recurring cause, which is worth knowing and watching for after future updates to that specific plugin.
Is this the same issue as a capability conflict between two plugins?
Related, but we treat conflict between two specific plugins as its own, more targeted fix, since the resolution approach differs from a straightforward single-cause capability gap.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.