Opened 10 years ago
Last modified 8 years ago
#34316 new enhancement
User status inconsistent between single-site & multisite
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 1.5 |
Component: | Users | Keywords: | 2nd-opinion needs-patch needs-unit-tests |
Focuses: | multisite | Cc: |
Description
The way a user's status is defined in WordPress differs between single-site and multisite:
- In single-site, the
user_status
column is used - In multisite, there are two additional columns for
spam
anddeleted
Not only this, but the update_user_status()
function is multisite only, and the user_status
column is an integer without an API to help announce what values equate to what results.
On the plus side, user statuses aren't really ever used in core. Marking users as spammers in multisite installations is the only real benefit of this feature as it exists today. I'd like to propose the following:
- Stop creating the the
spam
anddeleted
columns inwp_users
on new installations - ALTER the
user_status
column fromINT(11)
toVARCHAR(20)
alawp_posts
- A bevy of
wp_register_user_status()
like functions to introduce bonafide support for them - A database upgrade routine to move user status
0
toactive
and1
tospammer
- A new index on the
wp_users
table for the updateduser_status
column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc... - Update the
WP_User
andWP_User_Query
classes to suss out anyuser_status
inconsistencies
A few considerations worth noting:
- Large installations would need to manually perform these DB upgrades. I'm embarrassed to say I've personally frozen WordPress.org for several minutes years ago by missing a
DO_NOT_UPGRADE_GLOBAL_TABLES
check on thewp_users
table - Several plugins use their own values in the
users_status
column, assuming their numeric ID is unique and special. The authors of these plugins would need notifying, and their code updating to support the above ideas - This work *could* parlay into the Post Status API that's on infinite back-burner. There are some really excellent ideas floating around about how
post_status
could work that would translate nicely to users, too
Change History (9)
This ticket was mentioned in Slack in #core by jorbin. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-multisite by jjj. View the logs.
8 years ago
#8
@
8 years ago
It make totaly sense to me, like @jeremyfelt said.
I'am just worried about the "migration" about all the plugins and old code listed by @johnjamesjacoby.
Another less obvious but potentially huge cause of breakage with this idea is old-bbPress, GlotPress, & BackPress. They also assume that
wp_users
has anINT
styleuser_status
column.