WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My network is showing roles in some sites and not in others.

For some reason that I can't explain, when I add a new user, I have no role to choose from on the drop down box of a sub-site in my network. Also my new user assigned to a site is not showing on my list of users for that site.

Is this something fixable?

Below an image of the current situation.


Roles not Showing

Below is the picture showing the main site with the roles properly there, but the sub-sites of the network don't.

Roles showing

share|improve this question
  1. Determine your Multisite Blog ID. I will use 99 as an example
  2. Go into database
  3. Go to this table: wp_##_options (wp_99_options) - You will have a table for each blog.
  4. Find the record where "option_name" = "wp_user_roles"
  5. Change the text "wp_user_roles" to "wp_##_user_roles" ("wp_99_user_roles")

** the table you are editing will have option_id, blog_id, option_name, option_value, autoload. HOWEVER, DO NOT CHANGE ANY RECORD except the record where "option_name" = "wp_user_roles". There will only be a single record in this table like this.

** "wp_user_roles" is used when there is no multisite install, and here, it appears as though it was just a bug when the table was created.

share|improve this answer
Thank you! Life-saving advice here. This is EXACTLY the right answer. – ZaMoose Sep 17 '11 at 16:48
I had NO "wp_user_roles" in my table, what I did was copying the content of wp_4_options>wp_user_roles (a large json object or a serialized array, I dunnow) to a new record called wp_5_options (this was the blog missing roles) and it fixed my problem. Voted +1 nonetheless because it put me on the right track – Xananax Dec 15 '11 at 15:09
I resolved also REMOVING the record "wp_##_user_roles" from the main wp_options table, because it seems to override the one from wp_##_options. – Paolo Feb 19 '13 at 9:36
Brilliant answer! – jnthnclrk Aug 26 '13 at 15:36
For people who have migrated your site and changed prefixes, the error could be a "wp_##_user_roles" instead of "{new_prefix}_##_user_roles" – Des Nov 17 '14 at 21:59

If this is the problem I know so well, you are running a memcache setup behind your MU install? I've found that there's apparently a cache issue (witnessed in 2.9) for the options object where something good (like the wp_user_roles key) gets stuck in the "notoptions" memcache array.

If you do run atop memcache, and this sounds like a possiblity, try telnetting into the machine via 11211. Type delete blogid:options:notoptions, where the blogid is the id of the blog on which you see the issue. Refresh the admin panel and see if there are roles in the dropdown. If so, you've found your problem.

UPDATE: OK, so you did not find your problem -- you weren't running memcache. I would still check out the roles object, looking for a corrupt or non-existant one. I believe it's your best lead. You can use this code to dump the options table:

global $wpdb;
$array = $wpdb->get_col("SELECT option_name FROM $wpdb->options");
foreach ($array as $key) {
    echo $key . ": <code>";
    var_dump(get_option($key), true));
            echo "</code><br/>";
share|improve this answer
Editor. I don't know how memcache got into my server. I am not using it at all. Maybe because I installed w3 cache. I tried the delete it gave me a message saying not_found. I went ahead and disabled the memcache, since I am not using it. I am still having the issue. – Geo Mar 11 '11 at 2:50
I'm sorry that wasn't a solution to your problem. I run into this one a lot so it was my best guess. I would keep looking into the roles object for that blog. Does it exist? Updated my answer above in hopes it will help. – editor Mar 11 '11 at 18:24

I just wanted to say thank you for this article because I've been searching for a solution to this problem for a long time.

It was simply because I had used a plugin to clone my sites and it never updated the wp_##_user_roles properly. When the site copied over from wp_13... it was cloned over to a new site wp_81... but this entry was still stuck at wp_13.

share|improve this answer

I just want to point out that some people may still have an empty site users table—specifically for their root site. If this problem occurs, the way to fix it issue is by doing the following:

  1. Go to the table wp_usermeta
  2. Find any entries with the meta_key wp_capabilities
  3. Change the meta_key from wp_capabilities to wp_1_capabilities

I believe "1" is always the ID of the root site.


share|improve this answer
The wp_ prefix is set sinde wp-config.php and just defaults to wp_. The 1 indeed is the root site. But it does not have to be 1 as this is a unique and incrementing ID that is auto generated. – kaiser Jul 21 at 19:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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