WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 4 weeks ago

#20152 new enhancement

Multisite simplify option name to user_roles

Reported by: colind Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3.1
Component: Role/Capability Keywords: dev-feedback 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 3 years ago.
user-roles-option-plus-regeneration.diff (15.4 KB) - added by wonderboymusic 3 years ago.
20152.diff (15.5 KB) - added by wonderboymusic 3 years ago.
20152.patch (1008 bytes) - added by jdgrimes 4 weeks ago.
Just docs explaining why this is the way it currently is

Download all attachments as: .zip

Change History (31)

#1 @nacin
4 years ago

I've honestly never understood this either.

#2 @scribu
4 years ago

  • Keywords needs-patch added

#3 @johnbillion
4 years ago

  • Cc johnbillion added

#4 follow-up: @dd32
4 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
4 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
4 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
4 years ago

  • Cc ocean90 added

#8 @knutsp
4 years ago

  • Cc knut@… added

#9 @wonderboymusic
3 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
3 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
3 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
3 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
3 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
3 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
3 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 on the front end is needed. +1 for my patch. Just sayin.

Version 0, edited 3 years ago by wonderboymusic (next)

#16 @wonderboymusic
3 years ago

  • Cc scribu added

#17 @pbaylies
3 years ago

  • Cc pbaylies added

#18 @wonderboymusic
3 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
3 years ago

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

#20 @SergeyBiryukov
3 years ago

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

@wonderboymusic
3 years ago

#21 @wonderboymusic
3 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
3 years ago

these are all marked 3.7-early

#23 @jeremyfelt
2 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
2 years ago

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

#25 @chriscct7
4 months ago

  • Keywords needs-refresh added; has-patch removed

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


4 weeks ago

@jdgrimes
4 weeks ago

Just docs explaining why this is the way it currently is

#27 @jdgrimes
4 weeks 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. :-)

Note: See TracTickets for help on using tickets.