[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        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------

Comment (by boonebgorges):

 Thanks for the feedback, imath!

 >  I can see how to use this while building plugins but for regular users
 : it's a bit limited.

 Yes, that's the idea. It doesn't do *anything* for regular users right
 now. It's up to plugins to build interfaces for regular users.

 > So when fetching the user types, we don't get the terms count. I think
 that's the kind of thing people would like to know : how many members are
 from this type ?

 The reasons for not depending on `get_terms()` are the same as not
 depending on `SELECT DISTINCT post_type FROM $wpdb->posts` to get a list
 of post types: (a) it might reference member types that are no longer
 registered in plugins (and thus would not work properly), and (b) this
 query won't contain the necessary information (like labels) to build our
 interfaces. A more subtle reason has to do with the fragileness of the WP
 taxonomy system: there is the issue of terms that are shared between
 taxonomies (at least pre-4.1), the problem of term IDs not being
 persistent after export/import, the problem of occasional orphaned terms.
 For these reasons, the array of member types registered using
 `bp_register_member_type()` must be primary.

 That said, it seems like a fine idea to use `get_terms()` to fetch info
 about the term use. Maybe something like this: when using
 `bp_get_member_types()` or `bp_get_member_type_object()`, do a
 `get_terms()` or `get_term()` query (which would perhaps be optional) that
 would get stuff like `term_id` and `count` and then populate it into the
 member type object(s) before returning. I can see the value in this.
 Though it's worth noting that, at least in the case of user counts, this
 info is also likely to be unreliable: it doesn't account for user last
 activity, and we'd need to be sure to delete member_type relationships for
 users when they're deleted or marked as spam. I guess it might be worth
 caching "true" member type counts (ie those that account for last_activity
 etc) in a separate place, like the options table - much like we do for,
 eg, friend counts.

 > Without a loop parameter, i find it frustrating because to filter
 members by user types, you need to run the same query 2 times

 I am less sympathetic to this. Just use `BP_User_Query` with the
 `member_type` param. That's what it's for.

 > If i'm adding the same widget another time, i'm switching blogs 2 times.
 Is there a way to avoid this ?

 I haven't made any attempt to implement any sort of caching. But yes, at
 the very least, we could put the results of some of these queries into a
 non-persistent cache, so that you only have to run them once per page
 load. (Note that at least some of the underlying stuff is already cached
 in the WP API internals. I think that this works as expected inside of
 `switch_to_blog()`.) I will also say this: I obviously want everything to
 work correctly on subsites and in various network configurations, but it's
 very premature to be *optimizing* for those setups at the moment. I don't
 want to overengineer, at least for the first version. Doing a member_type
 loop on a secondary site is going to account for < 1% of the use of this
 new functionality, at least at first, so I think it makes sense to make
 incremental improvements in this area as it becomes more popular.

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