[buddypress-trac] [BuddyPress Trac] #6125: Small improvements to Member Types functions

[buddypress-trac]

#6125: Small improvements to Member Types functions
--------------------------+---------------------------
 Reporter:  Offereins     |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  2.2
Component:  Members       |     Version:
 Severity:  normal        |  Resolution:  fixed
 Keywords:  has-patch     |
--------------------------+---------------------------

Comment (by boonebgorges):

 > My only concern with it how it is now, is the hardcoded limitation we
 put on names vs. any other possible field that someone may want to pluck
 by, and the odd position it puts the filter in. As it sits now, we've
 whitelisted names for no reason, as each usage overrides it to objects,
 which makes it look accidental or unfinished.

 Not for no reason: because this is how `get_post_types()` does it. When
 pulling up a list of member types, what you generally want is either (a)
 to have a flat list of the member types (ie names), or (b) to have all
 available information about them (ie objects). I just happened to use
 `wp_list_pluck()` to make it happen. IMHO, it would add little value to
 support any member type key (like, say, 'labels') when it's just as simple
 for devs to pull the objects and `wp_list_pluck()` whatever they want
 themselves. By limiting what's officially supported in terms of parameter
 values (and, importantly, by making the documentation more limited -
 'names' and 'objects', period), we make it clearer what the purpose of the
 function is. That said, if it bothers you a lot, I don't have a huge
 problem with just passing 'output' to `wp_list_pluck()` and having a
 special case for 'objects'.

 The filter comes before the pluck so that filtering functions don't need
 to worry about checking to see if the values passed to the filter are
 objects or strings. If you think about the various ways you might use this
 filter in real life, I think that this setup makes more sense.

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