Member Types API: bp_has_user_member_type()

[Offereins]

Since #6006 the Member Types API came available for developers. Since I'm trying to use this set of functions in conditionals for the current user, I propose an additional core function that checks for a (current) user's member types. See patch for an implementation for single or a set of member type names.

PS. I'm not familiar with unit testing yet, so I hope someone can jump in on that.
PPS. If I'm not mistaken, member types may be registered with label-like type names, i.e. they are not sanitized in any way within BP's functions. Hence checking for member types cannot be done with slug-like type names

[boonebgorges]

Yes, let's do something like this for 2.3. I want to spend some more time thinking about the desired behavior of this function: you're referencing the *logged-in* user, but we don't have many functions like that in BP (and the ones that are are called _loggedin_). Usually our template functions like this refer to the *displayed* user, or the current user in a template loop.

PPS. If I'm not mistaken, member types may be registered with label-like type names, i.e. they are not sanitized in any way within BP's functions. Hence checking for member types cannot be done with slug-like type names

You are correct that we're not running the $member_type through sanitize_slug() like register_post_type() does - I'll open a separate ticket about that. However, I don't see what this has to do with checking "slug-like type names". in_array() in your proposed function will work fine in any case, right? Array keys can contain spaces and capital letters.

[Mamaduka]

Updated patch. I think it's better to support only single member type, like we do in other bp_*_member_type() functions.

[boonebgorges]

In 9611:

Introduce bp_has_member_type().

This function allows developers to test whether a given user has a given member
type. Thus the clever function name.

Props Offereins, Mamaduka.
Fixes #6138.

[Offereins]

Nice job guys!