[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):

 imath's suggestions were helpful in a couple of ways.
 [attachment:6006.2.patch] expands the original patch in the following
 ways:

 * Cache support is added for user member_type values. This is good from a
 performance point of view in general, but it also provides the foundation
 for the next point:
 * When doing a `BP_User_Query`, member type information for each returned
 user is now pre-loaded into the cache with a single database query. This
 means that there is zero additional overhead to using
 `bp_get_member_type()` within the loop.
 * Added some actions and filters.
 * Centralized the logic of member type objects a little bit, so that all
 such requests go through `bp_get_member_types()` instead of touching the
 global directly.

 This last point seems like a small one, but I did it in support of one of
 imath's comments that I did *not* implement. He expressed some remorse
 that I wasn't using `get_terms()` to pull up live taxonomy data as part of
 the member type object(s). By centralizing the logic of pulling up member
 type objects, I make it so that it's possible to do a single `get_terms()`
 query and populate these objects with taxonomy data on the fly.

 However, I've decided not to do this in 2.patch. My reasoning is as
 follows: from the point of view of plugin authors, I would like the member
 type API to be as implementation-agnostic as possible. That is, if you're
 running `bp_register_member_type()` in a plugin, you should not need to
 know or care that member types are a WP taxonomy. This has two benefits.
 (1) If we ever decided that these internals needed to change - even away
 from taxonomy altogether - we wouldn't need to worry too much about
 backward compatibility. (2) It makes it just a little harder for plugin
 authors to do the kinds of weird things with taxonomy terms that might
 backfire down the road. For example, I'm discovering the hard way as I
 work with WP's taxonomy API that a fair number of plugins do odd things
 like cache term_ids in postmeta, which means that they're tied to that
 specific ID being persistent, which it may not be in case of an export or
 some other operation. Now, in theory, I could load the `term_id` and
 `term_taxonomy_id` etc for each member_type into the member type object,
 but that would just encourage plugin authors to do strange stuff like
 that, and I don't think that's something we want to actively encourage.

 As for the point about member type *counts*. Yes, I agree that this is
 something people would like. I do *not* think it should be done by looking
 at term_taxonomy:count, because that value does not take BP activity into
 account. If this is something lots of people want, we can build wrappers
 that use `BP_User_Query` internally, and perhaps have a separate cache for
 this data. This task might be made a bit easier with some minor mods to
 `BP_User_Query` - like support for fields=ids. But I think that all of
 this can be handled in a separate ticket, since IMO it's nice to have, but
 not critical, for v1 of the API.

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