[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 helpful feedback, DJPaul. See [6006.3.patch].

 > Use bp_is_root_blog() prior to switch_to_blog; just for consistency with
 most of our other switch_to_blog calls.

 I think we might want to revisit whether this is necessary at some point,
 but yes, let's be consistent. Change made. (Note that the same check
 shouldn't happen around `restore_current_blog()`, since it will cause the
 switch-back not to occur.)

 > we should use get_the_terms()

 Yes, `wp_get_object_terms()` is uncached. However, we can't use
 `get_the_terms()`, as it's for posts only, and bp_member_type is a
 taxonomy on users. What `get_the_terms()` is is a wrapper for
 `wp_get_object_terms()` that uses the object term cache. I don't see a
 corresponding tool for user taxonomies in WP. We could build one, but (a)
 this is redundant with the cache implementation currently in the patch
 (which is specific to member types, and ignores other taxonomies), and (b)
 it might cause negative performance issues if the installation is using
 other plugins that have user taxonomies. I'm actually pretty on the fence
 about this, and could go either way; but definitely we should either stick
 with the specific caching already in the patch, or scrap it and build our
 own taxonomy term caching for users - but not both. For the moment, I've
 done nothing.

 > Instead of _ex( ' - ' ) which I understand but looks weird, can we re-
 use an existing string we have for this type of thing

 Done.

 > Can we move (duplicate) the validation logic into
 process_member_type_update()?

 Done.

 >  Is there a capability check we should be using?

 This method is hooked to 'bp_members_admin_load', which only fires on the
 member edit page, which itself is protected via the logic used to generate
 that admin page in the first place. That said, there's no harm in adding
 the additional cap check, and it does make the protection clearer, so I've
 done it.

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