Opened 13 years ago
Last modified 6 years ago
#20152 new enhancement
Multisite simplify option name to user_roles
Reported by: |
|
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)
Change History (36)
#4
follow-up:
↓ 5
@
13 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
@
13 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
@
13 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.
#9
@
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
@
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
@
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:
↓ 13
@
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
@
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
@
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
@
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.
#18
@
12 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
#20
@
11 years ago
- Keywords 3.7-early added
- Milestone changed from 3.6 to Future Release
- Type changed from defect (bug) to enhancement
#21
@
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.
#23
@
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.
This ticket was mentioned in Slack in #core by ocean90. View the logs.
9 years ago
#27
follow-up:
↓ 28
@
9 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:
↓ 29
@
9 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
@
9 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
@
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.
I've honestly never understood this either.