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

 I have not tested this but have done a code review. Here's what I'm
 thinking:

 * Use bp_is_root_blog() prior to switch_to_blog; just for consistency with
 most of our other switch_to_blog calls.
 * wp_get_object_terms() used to be an uncached function call
 (https://vip.wordpress.com/documentation/caching/uncached-functions/) -- I
 don't know if any recent changes have added caching, but if they have not,
 we should use get_the_terms().
 * Instead of `_ex( ' - ' )` which I understand but looks weird, can we re-
 use an existing string we have for this type of thing? See
 https://buddypress.trac.wordpress.org/browser/trunk/src/bp-xprofile/bp-
 xprofile-classes.php#L1701
 * In process_member_type_update(), I can follow through and understand how
 the validation for `$_POST['bp-members-profile-member-type']` works, but:
 a) it's not immediately obvious, and b) I think sanitize_text_field is
 appropriate here in addition to stripslashes. Can we move (duplicate) the
 validation logic into process_member_type_update()?
 * In process_member_type_update(), there are no validation checks to see
 if the current user is entitled to update this field. Is this intentional
 -- can a user update their own user_type field, or are we restricting it
 to super-admins etc? Is there a capability check we should be using?

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