No. You’re not looking in the right place then.
Normally you have the prefix wp_ and the table wp_options. In that table you have a option named wp_user_roles and everything works.
Remember when I said that? That means if your prefix IS NOT wp_ then the tables are different.
if the prefix is wp_booyah_ then the table is wp_booyah_options AND the options are wp_booyah_user_roles
But I promise you, every single WP install has user roles. It must. It’s a requirement.
Ok, I tried one of my single-user sites using reading glasses, and here’s what its wp_user_roles contained:
a:5:{s:13:"administrator";a:2:{s:4:"name";s:13:"Administrator";s:12:"capabilities";a:62:
{s:13:"switch_themes";b:1;s:11:"edit_themes";b:1;s:16:"activate_plugins";b:1;s:12:"edit_plugins";b:1;s:10:"edit_users";b:1;s:10:"edit_files";b:1;s:14:"manage_options";b:1;s:17:"moderate_comments";b:1;s:17:"manage_categories";b:1;s:12:"manage_links";b:1;s:12:"upload_files";b:1;s:6:"import";b:1;s:15:"unfiltered_html";b:1;s:10:"edit_posts";b:1;s:17:"edit_others_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:10:"edit_pages";b:1;s:4:"read";b:1;s:8:"level_10";b:1;s:7:"level_9";b:1;s:7:"level_8";b:1;s:7:"level_7";b:1;s:7:"level_6";b:1;s:7:"level_5";b:1;s:7:"level_4";b:1;s:7:"level_3";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:17:"edit_others_pages";b:1;s:20:"edit_published_pages";b:1;s:13:"publish_pages";b:1;s:12:"delete_pages";b:1;s:19:"delete_others_pages";b:1;s:22:"delete_published_pages";b:1;s:12:"delete_posts";b:1;s:19:"delete_others_posts";b:1;s:22:"delete_published_posts";b:1;s:20:"delete_private_posts";b:1;s:18:"edit_private_posts";b:1;s:18:"read_private_posts";b:1;s:20:"delete_private_pages";b:1;s:18:"edit_private_pages";b:1;s:18:"read_private_pages";b:1;s:12:"delete_users";b:1;s:12:"create_users";b:1;s:17:"unfiltered_upload";b:1;s:14:"edit_dashboard";b:1;s:14:"update_plugins";b:1;s:14:"delete_plugins";b:1;s:15:"install_plugins";b:1;s:13:"update_themes";b:1;s:14:"install_themes";b:1;s:11:"update_core";b:1;s:10:"list_users";b:1;s:12:"remove_users";b:1;s:9:"add_users";b:1;s:13:"promote_users";b:1;s:18:"edit_theme_options";b:1;s:13:"delete_themes";b:1;s:6:"export";b:1;}}s:6:"editor";a:2:
{s:4:"name";s:6:"Editor";s:12:"capabilities";a:34:{s:17:"moderate_comments";b:1;s:17:"manage_categories";b:1;s:12:"manage_links"
I pasted that over my multisite wp_user_roles then tried login, but got exactly the same redirection problem as before.
This would be so much easier to walk you through if you had WP-CLI *sigh* I’d tell you to type ‘wp user list’ and see what roles popped up for each user.
When I look at wp-users, id 1 is admin
In the table wp_usermeta, look for the meta key wp_capabilities with the user_id of 1
Is it a:1:{s:13:"administrator";b:1;} ?
Also in the table wp_sitemeta, what’s the value for site_admins ?
wp_capabilities contains: a:1:{s:13:”administrator”;s:1:”1″;}
site_admins contains: a:1:{i:0;s:5:”admin”;}
Okay, try changing wp_capabilities for the admin to this:
a:1:{s:13:"administrator";b:1;}
What you have with the s:1 is weird and not right.
wp_capabilities is now a:1:{s:13:”administrator”;b:1;} as requested, but the redirection is still happening on login.
*head scratch* I have no idea how this got so weird.
You don’t have a backup to restore from before this all happened do you?
Enough messing around. I reset wp_capabilities to its original value, but
left wp_user_roles with the single-site data I’d pasted in. I dug out 3.9.2 and re-installed it. Login worked first time. I was able to update plugins and themes, edit a page and clear out the spam queues in all user sites (NB most of these were near empty – just today’s stuff – but two were very big: one with 32k+ entries and one with 3k+.) The system is running pretty slow, but I seemed to be able to access all the components I tried (though I didn’t go through everything). I don’t know how far back my host keeps database copies: they archive daily but I wouldn’t expect more than a month. Can you explain this minor miracle?
I … Huh.
I’m almost afraid to ask what happens if you reinstall 4.0.1 files on top of this.
My guess? You have ‘something’ that hates 4.0.1… The only thing that comes to mind is this: http://halfelf.org/2014/single-site-login-loop/
So if your site thinks it’s BOTH http://www.domain.com and domain.com, the cookies get screwy.
On Multisite, you check in wp_options for siteurl and home and make sure they’re the same as the ones in wp_site and wp_blogs
wp_options contains: http://www.soutarwriters.co.uk in both siteurl and home
wp_site and wp_blogs both contain: http://www.soutarwriters.co.uk
Be not afraid to ask – 4.0.1 is now installed and functioning. I did it the hard way by first trying:
(a) trimming all urls on database to soutarwriters.co.uk – total mess
(b) making them all www.soutarwriters.co.uk – site wouldn’t render correctly
(c) resetting wp_options/siteurl/home to have http:// prefix – site ok
(d) resetting wp_user_roles to include NextGEN values
[NB for (a)-(d) I used 3.9.2 with cookies, cache, etc. cleared before each step, then tried login to test]
(e) installing 4.0.1 and clearing cookies, cache, etc.
Thanks for all the prompts. I still don’t really understand why this should have been so hard, but I can now edit databases which is a plus!
Yeah, that really sounds like you had some messed up URLs in there. WP 3.9 and below was more forgiving about www.domain.com and domain.com being the same idea.
