I am working on a new site but I am using the users from an old site.

I created all my user roles, which match the user roles on the other site. I deleted the user and usermeta table from the new site and imported these tables from the old site.

I can now see all the users and I can login with the users. The issue I have is that the users, other than the primary admin, have no roles assigned.

When I check the database, I do see the proper role assigned to them.

'2039843', '308', 'wp_capabilities', 'a:1:{s:10:"subscriber";b:1;}'

When I am in the Users section of WordPress, I can see all the users but they have no roles "assigned" to them (even though it clearly is defined in the dataabase).

I am importing over 40,000 users so the database option seems the most fitting for my needs. Is there a snippet of code I can do to update this total perhaps? Where are these totals stored? I can tell, it's not scanning the usermeta table for these values so it has to be in the options table.

I already added the option for wp_user_roles and assigned it the same value as the old site, still no luck. No roles have totals and no users are assigned to the roles.

What is the best method to update the user role totals so WordPress will recognize the users are assigned properly to the roles?

2 Answers 2


You'll also need to export the old site's options table which is usually called wp_options and import it to new one. Cause in the options table aka wp_options table there is a row field called wp_user_roles and it holds the role values of the site.

  • I have added that too and still no totals or roles are assigned to the users. Also, when looking at the value of the option, I didn't see any totals.
    – Jeremy
    Oct 20, 2016 at 17:44

Ok, this is something I didn't know...

The usermeta meta_key wp_capabilities is unique to your database prefix. Since I used a different prefix than wp_ this key is also prefixed with the same prefix.

Since I imported the data from a table that used the default prefix: wp_ The data I imported used the prefix from the other database. So all I had to do to fix this was to do an update to replace wp_capabilities with the PREFIX_capabilities and now it works as expected.

This was interesting to identify as I wouldn't think that an option key would be prefixed with the database prefix. This is a little bit of a concern because now I am not sure what uses the prefix vs what doesn't... Bad design IMHO

  • The last part (UPDATE) is wrong, there are 5 standard meta keys that use prefix: wp_capabilities, wp_dashboard_quick_press_last_post_id, wp_user_level, wp_user-settings and wp_user-settings-time (and there is wp_user_roles in wp_options table)
    – dev_masta
    Jan 23, 2018 at 1:01
  • You are correct. Not sure why I didn't find those when I posted this but it is pretty easy to find everything. I removed the Updated section as it is incorrect.
    – Jeremy
    Jan 23, 2018 at 22:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.