WordPress User Role Capabilities Not Working — Editor Can't Edit: Database Fix

Your Editor is logged in. They go to Posts. They see the list of posts, but when they hover over one, there's no Edit button. Or they click a post and get "You are not allowed to edit this." You checked WordPress admin → Users → Edit Editor, and the Editor role is definitely selected. All capabilities show as checked. But something is still broken. The issue isn't WordPress—it's your database.

What's Actually Wrong

WordPress stores user roles and capabilities in two places:

1. wp_options Table → user_roles (The Role Definition)

This table holds the master list of all roles and their capabilities. It looks like:

wp_user_roles → editor → [edit_posts, edit_pages, edit_others_posts, etc.]

2. wp_usermeta Table → wp_capabilities (The User Assignment)

This table stores which role each user has. A row for each user looks like:

user_id=2, meta_key=wp_capabilities, meta_value=a:1:{s:6:"editor";b:1;}

When an Editor tries to edit, WordPress checks: (1) Does this user have the "editor" role? (2) Does the "editor" role have the "edit_posts" capability? (3) Can this specific user edit this specific post?

If any of these fail, the Editor can't edit. Here are the common breaks:

Break #1: Corrupted wp_capabilities Entry

The wp_usermeta row for an Editor is empty, blank, or contains garbage data. WordPress can't find the user's role.

Example: The meta_key is "wp_capabilities" but the meta_value is empty or just NULL

Break #2: Table Prefix Mismatch (After Migration)

You migrated your site from one host to another. The old host used prefix wp7b_ and the new host uses wp_. WordPress is now looking for capabilities in the wrong table columns:

  • WordPress looks for: wp_capabilities
  • But the database has: wp7b_capabilities
  • WordPress can't find the role. Permission denied.

Break #3: Missing or Corrupted Role Definition

The wp_user_roles option in the wp_options table is empty or corrupted. The Editor role exists in usermeta, but WordPress doesn't know what capabilities the Editor role should have.

Break #4: Plugin Conflict (Role Manager Plugin)

You installed User Role Editor, Members, PublishPress Capabilities, or another role plugin. During an update, it silently corrupted the wp_capabilities entries for all users. Or you tweaked role settings and accidentally removed required capabilities like edit_posts or read.

Break #5: Editor Can't Edit Admin's Posts

The Editor is working fine—they can edit their own posts and pages. But when you (an Admin) create a post, the Editor still can't edit it. This is because:

  • The Editor has edit_posts but NOT edit_others_posts
  • So they can only edit posts they authored, not posts written by someone else

Diagnosis: Check the Database

Step 1: Access phpMyAdmin

  1. Log into cPanel → Databases → phpMyAdmin
  2. Or access phpMyAdmin directly if you have the URL
  3. Click on your WordPress database (left sidebar)

Step 2: Check the Editor's Capabilities (wp_usermeta)

  1. Find and click the wp_usermeta table
  2. Click Search (usually in the top menu) or Browse
  3. Filter by the Editor user's ID (find it in wp_users first if needed)
  4. Look for the row where meta_key = 'wp_capabilities'

What you should see: A meta_value that looks like:

a:1:{s:6:"editor";b:1;}

If it's blank or shows NULL: That's your problem. Go to Step 4 (Fix).

If it looks like garbage or has a wrong prefix (e.g., wp7b_capabilities): That's your problem. Go to Step 4 (Fix).

Step 3: Check the Role Definition (wp_options)

  1. Click on the wp_options table
  2. Click Search and filter by option_name = 'wp_user_roles'

What you should see: An option_value with a huge serialized array containing all roles (editor, author, contributor, etc.) and their capabilities.

If it's empty, NULL, or contains only garbage: Your role definitions are corrupted. Go to Step 4 (Fix).

Step 4: Check the Table Prefix

In your wp-config.php, find the line:

$table_prefix = 'wp_';



This is your database prefix. Now, in phpMyAdmin, look at the wp_usermeta table. Check a few rows. Are the meta_key values like:



    

  • wp_capabilities ✓ (matches prefix)
    • 

  • wp7b_capabilities ✗ (wrong prefix—this is the problem)
    • 




If the meta_key values don't match your $table_prefix, you have a prefix mismatch.






Fix It: Restore Capabilities



Fix #1: Restore a Single Editor's Capabilities (phpMyAdmin)



If only one Editor is broken:



    

  1. Go to wp_usermeta table in phpMyAdmin
    2. 

  2. Find the row where user_id = [Editor's ID] and meta_key = 'wp_capabilities'
    3. 

  3. Click Edit
    4. 

  4. In the meta_value field, paste this (replace wp_ with your prefix if different):
  
    a:1:{s:6:"editor";b:1;}
    

    5. 

  5. Click Go or Save
    6. 




Fix #2: Restore All Users' Capabilities (SQL Query)



If multiple users are broken:



    

  1. In phpMyAdmin, click the SQL tab
    2. 

  2. Paste this query:
  
    UPDATE wp_usermeta 
SET meta_value = 'a:1:{s:6:"editor";b:1;}' 
WHERE meta_key = 'wp_capabilities' 
AND user_id IN (SELECT ID FROM wp_users WHERE ID NOT IN (
  SELECT user_id FROM wp_usermeta WHERE meta_key='wp_capabilities' 
  AND meta_value LIKE '%administrator%'
));
    

    3. 

  3. Replace wp_ with your table prefix if different
    4. 

  4. Click Go
    5. 




Fix #3: Restore Corrupted Role Definition (wp_user_roles)



If the wp_user_roles option is empty or corrupted:



    

  1. In phpMyAdmin, go to wp_options table
    2. 

  2. Search for option_name = 'wp_user_roles'
    3. 

  3. Click Edit
    4. 

  4. Replace option_value with the default WordPress roles:
  
    a:5:{s:13:"administrator";a:2:{s:4:"name";s:13:"Administrator";s:12:"capabilities";a:60:{s:13:"manage_options";b:1;s:15:"edit_dashboard";b:1;s:11:"read";b:1;s:10:"edit_posts";b:1;s:12:"edit_pages";b:1;s:17:"edit_others_posts";b:1;s:19:"edit_others_pages";b:1;s:20:"edit_published_posts";b:1;s:18:"edit_published_pages";b:1;s:11:"delete_posts";b:1;s:11:"delete_pages";b:1;s:16:"delete_others_posts";b:1;s:18:"delete_others_pages";b:1;s:17:"delete_published_posts";b:1;s:19:"delete_published_pages";b:1;s:15:"publish_posts";b:1;s:12:"publish_pages";b:1;s:12:"manage_links";b:1;s:12:"manage_media";b:1;s:17:"manage_categories";b:1;s:15:"manage_comments";b:1;s:17:"moderate_comments";b:1;s:15:"manage_plugins";b:1;s:15:"manage_themes";b:1;s:15:"manage_users";b:1;s:20:"promote_users";b:1;s:17:"edit_theme_options";b:1;s:14:"delete_themes";b:1;s:15:"delete_plugins";b:1;s:16:"install_plugins";b:1;s:17:"update_plugins";b:1;s:15:"install_themes";b:1;s:16:"update_themes";b:1;s:12:"update_core";b:1;s:10:"list_users";b:1;s:10:"remove_users";b:1;s:8:"add_users";b:1;s:13:"restrict_content_by_role";b:1;s:22:"gravatar_manage_options";b:1;s:17:"edit_gravatar";b:1;}}s:6:"editor";a:2:{s:4:"name";s:6:"Editor";s:12:"capabilities";a:24:{s:10:"edit_posts";b:1;s:12:"edit_pages";b:1;s:17:"edit_others_posts";b:1;s:19:"edit_others_pages";b:1;s:20:"edit_published_posts";b:1;s:18:"edit_published_pages";b:1;s:11:"delete_posts";b:1;s:11:"delete_pages";b:1;s:16:"delete_others_posts";b:1;s:18:"delete_others_pages";b:1;s:17:"delete_published_posts";b:1;s:19:"delete_published_pages";b:1;s:15:"publish_posts";b:1;s:12:"publish_pages";b:1;s:12:"manage_links";b:1;s:12:"manage_media";b:1;s:17:"manage_categories";b:1;s:15:"manage_comments";b:1;s:17:"moderate_comments";b:1;s:11:"read";b:1;}}s:6:"author";a:2:{s:4:"name";s:6:"Author";s:12:"capabilities";a:8:{s:10:"edit_posts";b:1;s:20:"edit_published_posts";b:1;s:11:"delete_posts";b:1;s:17:"delete_published_posts";b:1;s:15:"publish_posts";b:1;s:11:"read";b:1;s:12:"manage_media";b:1;}}s:11:"contributor";a:2:{s:4:"name";s:11:"Contributor";s:12:"capabilities";a:4:{s:10:"edit_posts";b:1;s:11:"delete_posts";b:1;s:11:"read";b:1;}}s:10:"subscriber";a:2:{s:4:"name";s:10:"Subscriber";s:12:"capabilities";a:1:{s:4:"read";b:1;}}}
    

    5. 

  5. Click Go or Save
    6. 




Fix #4: Fix Table Prefix Mismatch



If your prefix doesn't match after a migration:



    

  1. In phpMyAdmin, go to wp_usermeta table
    2. 

  2. Use the Find and Replace function (or run a SQL query):
    3. 




UPDATE wp_usermeta 
SET meta_key = REPLACE(meta_key, 'oldprefix_', 'wp_')



Replace oldprefix_ with the old prefix (e.g., wp7b_).



Also fix the wp_options table:



UPDATE wp_options 
SET option_name = 'wp_user_roles' 
WHERE option_name = 'oldprefix_user_roles';



Fix #5: Deactivate Role Plugins



If you think a plugin caused this:



    

  1. Go to WordPress admin → Plugins
    2. 

  2. Deactivate User Role Editor, Members, PublishPress Capabilities, or any role management plugin
    3. 

  3. Test if the Editor can edit now
    4. 

  4. If it works, delete the plugin and use WordPress's built-in role management
    5. 







Special Case: Editor Can Edit Own Posts But Not Admin Posts



The Editor needs edit_others_posts to edit posts written by someone else.



Quick fix in WordPress admin (no database):



    

  1. Go to Users → Edit Editor (the broken role user)
    2. 

  2. Scroll to Capabilities
    3. 

  3. Check edit_others_posts and edit_others_pages
    4. 

  4. Click Save
    5. 




Database fix (phpMyAdmin):



If the WordPress admin UI doesn't work, edit the wp_capabilities directly:



a:2:{s:6:"editor";b:1;s:17:"edit_others_posts";b:1;}






Complete Troubleshooting Checklist






Check
Where to Look
Fix If Broken




User has correct role assigned
WordPress admin → Users → Edit user
Reassign role to Editor




wp_capabilities entry exists and is not empty
phpMyAdmin → wp_usermeta table
Restore with correct value (see Fix #1)




wp_user_roles exists in wp_options
phpMyAdmin → wp_options table
Restore default roles (see Fix #3)




Table prefix consistency
wp-config.php vs wp_usermeta meta_key
Fix prefix mismatch (see Fix #4)




Required capabilities present
WordPress admin → Users → Edit, Capabilities tab
Check edit_posts, edit_pages, read




No conflicting role plugins active
WordPress admin → Plugins
Deactivate User Role Editor, Members, etc.









Prevent Future Capability Corruption



1. Avoid role management plugins if possible — Use WordPress's built-in Users → Edit interface. Role management plugins are common sources of corruption.



2. Document your table prefix — Before any migration, note your current prefix in wp-config.php. After migration, verify it matches the database tables.



3. Back up the wp_options and wp_usermeta tables regularly — Use your hosting control panel or a backup plugin. When corruption strikes, you can restore from a known-good backup.



4. Keep plugins updated — Outdated role management plugins are more likely to corrupt capabilities during WordPress updates.



5. Test after migrations — Every time you move a site, log in as each role and verify they can do what they should. Catch prefix mismatches early.






The Real Talk



WordPress user roles and capabilities are stored in the database as serialized PHP arrays. They're brittle. A plugin bug, a migration gone wrong, or a mistyped SQL query can corrupt them instantly. When that happens, the WordPress admin UI often can't fix it (because WordPress can't read the broken data), so you have to go to phpMyAdmin and edit the raw database.



It's a pain, but it's fixable in 5 minutes if you know exactly what to look for. The secret: check wp_usermeta first, then wp_options. If either is empty or has the wrong prefix, that's your fix.



The second secret: keep backups. Database corruption is common enough that a weekly backup is your real safety net.



Last updated: October 2026. Real data: WordPress.org support forums (2010–2026), role-editor.com forums, hosting provider documentation (Plesk, cPanel, WebSavers), WordPress Core trac tickets.