[buddypress-trac] [BuddyPress Trac] #6006: User Types API
noreply at wordpress.org
Sun Nov 23 15:02:57 UTC 2014
#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/>
More information about the buddypress-trac