WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 3 months 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: has-patch dev-feedback
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 (3)

user-roles-option.diff (7.0 KB) - added by wonderboymusic 20 months ago.
user-roles-option-plus-regeneration.diff (15.4 KB) - added by wonderboymusic 20 months ago.
20152.diff (15.5 KB) - added by wonderboymusic 9 months ago.

Download all attachments as: .zip

Change History (27)

comment:1 nacin2 years ago

I've honestly never understood this either.

comment:2 scribu2 years ago

  • Keywords needs-patch added

comment:3 johnbillion2 years ago

  • Cc johnbillion added

comment:4 follow-up: dd322 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.

comment:5 in reply to: ↑ 4 nacin2 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.

comment:6 dd322 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.

comment:7 ocean902 years ago

  • Cc ocean90 added

comment:8 knutsp2 years ago

  • Cc knut@… added

comment:9 wonderboymusic20 months 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.

comment:10 wonderboymusic20 months 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.)

comment:11 nacin20 months 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

comment:12 follow-up: wonderboymusic20 months 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.

comment:13 in reply to: ↑ 12 nacin20 months 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.

comment:14 wonderboymusic20 months ago

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

comment:15 wonderboymusic20 months 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 20 months ago by wonderboymusic (next)

comment:16 wonderboymusic18 months ago

  • Cc scribu added

comment:17 pbaylies16 months ago

  • Cc pbaylies added

comment:18 wonderboymusic16 months 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

comment:19 nacin14 months ago

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

comment:20 SergeyBiryukov14 months ago

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

wonderboymusic9 months ago

comment:21 wonderboymusic9 months 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.

comment:22 wonderboymusic9 months ago

these are all marked 3.7-early

comment:23 jeremyfelt7 months 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.

comment:24 jeremyfelt3 months ago

  • Component changed from Multisite to Role/Capability
  • Focuses multisite added
Note: See TracTickets for help on using tickets.