[wp-trac] [WordPress Trac] #34316: User status inconsistent between single-site & multisite

[WordPress Trac]

#34316: User status inconsistent between single-site & multisite
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:
  johnjamesjacoby        |     Status:  new
     Type:  enhancement  |  Milestone:  Awaiting Review
 Priority:  normal       |    Version:  1.5
Component:  Users        |   Keywords:  2nd-opinion needs-patch needs-unit-
 Severity:  normal       |  tests
  Focuses:               |
-------------------------+-------------------------------------------------
 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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34316>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform