Multisite simplify option name to user_roles

[colind]

Currently each blog in a MS install of WP stores an array of user roles in it's [prefix]_[$blog_id]_options table as an entry with the key [prefix]_[$blog_id]_user_roles

This makes it much harder to migrate MS install of WP to a different db prefix, etc. because not only do you need to change the table prefixes you need to go into each blog's options table and then properly update that option's key.

Because the table itself is sufficiently unique there isn't a need for this. The user roles array could be stored in an option called "user_roles" for each blog.

[nacin]

I've honestly never understood this either.

[dd32]

of course, when you're using a shared usermeta table, having a non-prefixed option would cause roles to be shared across all sites, Prefixing with the blog ID instead of the database prefix would've made better sense to me.

[nacin]

Replying to dd32:

of course, when you're using a shared usermeta table, having a non-prefixed option would cause roles to be shared across all sites, Prefixing with the blog ID instead of the database prefix would've made better sense to me.

This is for wp_options, not wp_usermeta. They're prefixed in both. The prefix is useless in wp_options.

[dd32]

This is for wp_options, not wp_usermeta. They're prefixed in both. The prefix is useless in wp_options.

Ah.. read it completely wrong.

[wonderboymusic]

I added a patch to change the option name - but there are some serious deal breakers with doing so.

Namely: go to your database and delete wp_2_user_roles or wp_user_roles. You're totally screwed. Those roles are saved during the upgrade routine in schema.php and create circular references til fatal error for WP_Roles if you try to do it in the class or in a function at runtime. Here is how the one option is generated:

function populate_roles() {
	populate_roles_160();
	populate_roles_210();
	populate_roles_230();
	populate_roles_250();
	populate_roles_260();
	populate_roles_270();
	populate_roles_280();
	populate_roles_300();
}

So yeah.... There's that. The newly-named option CAN'T be created without an upgrade.

[wonderboymusic]

Introduce _WP_User_Roles class. _WP_User_Roles::init() can regenerate the roles option on the fly. You can delete the option, no probs. Currently, if you delete the option you are completely screwed (code is in the schema.php). Schema now calls _WP_User_Roles::init() which swallows up all of the populate_* functions and deprecates wp_user_roles option for each blog.

(Be Gentle.)

[nacin]

What about:

• An upgrade routine (e.g. upgrade_350, 360, etc) renames $wpdb->prefix . 'user_roles' to 'user_roles'
• We change any reference(s) in core to 'user_roles', which is mostly just the change in WP_Roles
• In WP_Roles, if 'user_roles' doesn't exist, it falls back to $wpdb->prefix . 'user_roles'. If it does this in the admin, it renames the option
• We use the option_{$wpdb->prefix}_user_roles filter (maybe default_option_*) to fall back to 'user_roles' in case anyone is referencing it directly

[wonderboymusic]

That all sounds good. My only fear was someone deleting the option (or both, old and new) and then not being able to get them back. Also, currently the generation of the roles calls update_option on every add_role and add_cap invocation, rather than once per role or (like _WP_User_Roles::init) once only for all default roles.

[nacin]

Replying to wonderboymusic:

Also, currently the generation of the roles calls update_option on every add_role and add_cap invocation, rather than once per role or (like _WP_User_Roles::init) once only for all default roles.

I've noticed — and this is painful when adding a new blog in multisite. It would be nice if we made this less painful, though I doubt a whole new class is necessary. Similar to what we did for wp_get_db_schema(). In fact the whole thing could probably sit in populate_roles() and replace all of the child functions there.

[wonderboymusic]

I am down for whatever - just wanted to proof of concept it. 1) option can be regenerated 2) it can be done faster.

[wonderboymusic]

I just went back to my install where I deleted the option after reverting my patch, and I had to delete wp-config.php and reinstall to get the option back. IMO, regeneration in the API is needed. +1 for my patch. Just sayin.

[wonderboymusic]

scribu and JJJ both showed interest in this thing, we should revisit the issue in a more comprehensive way

[nacin]

There is a lot here. I'm interested, but bandwidth is limited. Early 3.7?

[wonderboymusic]

Refreshed the patch so the changes to schema.php apply - I just tested this and it works, but I'm sure needs some discussion. Best way to test: delete user_roles from your options table and then try to use WP. Stuff breaks. Apply patch. Stuff works again, option is regenerated passively.

[wonderboymusic]

these are all marked 3.7-early

[jeremyfelt]

Punting this to a future release. We need a bunch more testing and probably some discussion before this will be ready. We should revisit sooner in a cycle.

[jdgrimes]

Just docs explaining why this is the way it currently is

[jdgrimes]

20152.patch​ just adds a short note in the docblock of WP_Roles::_init() explaining why the database prefix is used, so that people like myself don't spend precious time searching for the answer. Of course, it would be better if this was just fixed, but that could take a while. :-)

[DrewAPicture]

Replying to jdgrimes:

20152.patch​ just adds a short note in the docblock of WP_Roles::_init() explaining why the database prefix is used, so that people like myself don't spend precious time searching for the answer. Of course, it would be better if this was just fixed, but that could take a while. :-)

Should use an @link tag for an external link. +1

@jeremyfelt Shall we make the docs improvement in 4.5 and punt the rest or ...?

[jeremyfelt]

Replying to DrewAPicture:

@jeremyfelt Shall we make the docs improvement in 4.5 and punt the rest or ...?

Let's wait a bit. IMO, adding the docs starts to make things even more confusing.

FWIW, this was introduced in [2703].

I'm going to spend some time with the patches. This seems solvable and I would love it for moving sites.

[knutsp]

This convention (prefixing an option in a table that's already prefixed and thereby site specific) just creates extra work and possible confusion when moving sites.

If two sites in some strange way are able to be sharing their options then they share user roles, too. If this is happening in som rare cases, using config contants for site_url and home_url, add a constant for user_roles to override the option, like WP_USER_ROLES (simple array of strings).

Please fix.