[buddypress-trac] [BuddyPress Trac] #6006: User Types API
noreply at wordpress.org
Wed Nov 12 17:40:44 UTC 2014
#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
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.
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'.
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()`.
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.
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/>
More information about the buddypress-trac