WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 8 months ago

#34316 new enhancement

User status inconsistent between single-site & multisite

Reported by: johnjamesjacoby 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 and deleted

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 and deleted columns in wp_users on new installations
  • ALTER the user_status column from INT(11) to VARCHAR(20) ala wp_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 to active and 1 to spammer
  • A new index on the wp_users table for the updated user_status column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc...
  • Update the WP_User and WP_User_Query classes to suss out any user_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 the wp_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)

#1 @johnjamesjacoby
3 years ago

Another less obvious but potentially huge cause of breakage with this idea is old-bbPress, GlotPress, & BackPress. They also assume that wp_users has an INT style user_status column.

#2 @jeremyfelt
3 years ago

  • Focuses multisite added

I think this is worth exploration. Aligning single site and multisite to track a user status makes sense. Having separate fields in the database for spam and deleted has seemed strange.

Related: #20854, #34615

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


2 years ago

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


2 years ago

#5 @lukecavanagh
19 months ago

@jeremyfelt

Makes sense to define both correctly for user_status.

#6 @Mista-Flo
17 months ago

+1 for this usefull change.

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


11 months ago

#8 @MaximeCulea
11 months 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.

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


8 months ago

Note: See TracTickets for help on using tickets.