Make WordPress Core

Opened 12 years ago

Last modified 6 years ago

#20152 new enhancement

Multisite simplify option name to user_roles

Reported by: colind's profile colind Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3.1
Component: Role/Capability Keywords: needs-patch needs-refresh
Focuses: multisite Cc:

Description

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.

Attachments (4)

user-roles-option.diff (7.0 KB) - added by wonderboymusic 12 years ago.
user-roles-option-plus-regeneration.diff (15.4 KB) - added by wonderboymusic 12 years ago.
20152.diff (15.5 KB) - added by wonderboymusic 11 years ago.
20152.patch (1008 bytes) - added by jdgrimes 8 years ago.
Just docs explaining why this is the way it currently is

Download all attachments as: .zip

Change History (36)

#1 @nacin
12 years ago

I've honestly never understood this either.

#2 @scribu
12 years ago

  • Keywords needs-patch added

#3 @johnbillion
12 years ago

  • Cc johnbillion added

#4 follow-up: @dd32
12 years ago

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.

#5 in reply to: ↑ 4 @nacin
12 years ago

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.

#6 @dd32
12 years ago

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.

#7 @ocean90
12 years ago

  • Cc ocean90 added

#8 @knutsp
12 years ago

  • Cc knut@… added

#9 @wonderboymusic
12 years ago

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.

#10 @wonderboymusic
12 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

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.)

#11 @nacin
12 years ago

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

#12 follow-up: @wonderboymusic
12 years ago

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.

#13 in reply to: ↑ 12 @nacin
12 years ago

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.

#14 @wonderboymusic
12 years ago

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

#15 @wonderboymusic
12 years ago

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.

Last edited 12 years ago by wonderboymusic (previous) (diff)

#16 @wonderboymusic
11 years ago

  • Cc scribu added

#17 @pbaylies
11 years ago

  • Cc pbaylies added

#18 @wonderboymusic
11 years ago

  • Milestone changed from Awaiting Review to 3.6

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

#19 @nacin
11 years ago

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

#20 @SergeyBiryukov
11 years ago

  • Keywords 3.7-early added
  • Milestone changed from 3.6 to Future Release
  • Type changed from defect (bug) to enhancement

#21 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.7

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.

#22 @wonderboymusic
11 years ago

these are all marked 3.7-early

#23 @jeremyfelt
11 years ago

  • Keywords 3.7-early removed
  • Milestone changed from 3.7 to Future Release

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.

#24 @jeremyfelt
10 years ago

  • Component changed from Multisite to Role/Capability
  • Focuses multisite added

#25 @chriscct7
8 years ago

  • Keywords needs-refresh added; has-patch removed

This ticket was mentioned in Slack in #core by ocean90. View the logs.


8 years ago

@jdgrimes
8 years ago

Just docs explaining why this is the way it currently is

#27 follow-up: @jdgrimes
8 years ago

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. :-)

#28 in reply to: ↑ 27 ; follow-up: @DrewAPicture
8 years ago

  • Keywords needs-refresh removed

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 ...?

#29 in reply to: ↑ 28 @jeremyfelt
8 years ago

  • Keywords needs-patch needs-refresh added; dev-feedback removed

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.

This ticket was mentioned in Slack in #core by ocean90. View the logs.


8 years ago

#31 @knutsp
8 years ago

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.

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


6 years ago

Note: See TracTickets for help on using tickets.