[buddypress-trac] [BuddyPress Trac] #6006: User Types API

[buddypress-trac]

#6006: User Types API
--------------------------+-----------------
 Reporter:  boonebgorges  |      Owner:
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  2.2
Component:  Core          |    Version:
 Severity:  normal        |   Keywords:
--------------------------+-----------------
 For almost every BP client site I've ever built, I've had to build some
 kind of support for "user types". Sometimes it's so that the member
 directory could be filtered; sometimes it's so different types of users
 can have different permissions; sometimes it's so different types can have
 different kinds of profiles; and so forth. But it always comes down to a
 system that involves sorting users into buckets. In the past, I've used
 xprofile, taxonomies, and usermeta for the purpose, all to various levels
 of success.

 It's time for BP to provide the basics of a user type API, so that plugin
 devs and site builders will have some common tools for building the user
 type functionality required by their implementation. Here are some initial
 proposals on how I think it should work. I'm glad to own this task for
 2.2, but I'd be very happy to hear feedback.

 __Data storage__

 At WCSF 2014 http://bpdevel.wordpress.com/2014/11/12/at-wcsf-some-
 attendees-of/, we talked about storing user types as usermeta. I think
 this would work. But the more I think about it, the more I think that a
 taxonomy suits this purpose better. Taxonomies perform better and are
 designed for one-to-many relationships, which will make it more elegant to
 support multiple user types per member in the future.

 So I'm proposing that BP register a private taxonomy 'bp_user_type'.

 __CRUD functions__

 If we go the taxonomy route, then individual user types will be terms in
 the 'bp_user_type' taxonomy, user-usertype relationships will be rows in
 `wp_term_relationships`, and our CRUD functions will be wrappers for WP's
 `_terms()` functions. `bp_set_type_for_user()` will wrap
 `wp_set_object_terms()`, `bp_get_type_for_user()` will wrap
 `wp_get_object_terms()`, `bp_get_user_types()` will wrap `get_terms()`,
 and so forth.

 __Registering user types__

 I propose a function `bp_register_user_type( $type, $args )`. Syntax will
 parallel `register_post_type()`, `register_taxonomy()` etc as much as
 possible. User type data will be stored in the `$bp` global at 'bp_init'.
 We'll need functions like `bp_get_user_type_object()`.

 __UI__

 At a first pass, I propose that the only UI provided by BP is a user-type
 selector metabox on Dashboard > Users > Community Profile. We'll only show
 this selector if any user types have been registered. I'm leaning toward
 making the selector a dropdown, which will mean that we'll only formally
 support having a user in a single user type at least in the first
 revision, but I would be willing to be overruled on this.

 __Querying__

 We should add a parameter 'user_type' to `BP_User_Query`. It will support
 a string or an array of values, and do an IN tax query to generate the
 necessary SQL clauses.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6006>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac