[buddypress-trac] [BuddyPress Trac] #6006: User Types API
noreply at wordpress.org
Sun Nov 23 20:37:35 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):
imath's suggestions were helpful in a couple of ways.
[attachment:6006.2.patch] expands the original patch in the following
* 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
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/>
More information about the buddypress-trac