[buddypress-trac] [BuddyPress Trac] #6286: Directories filtered by member roles

[buddypress-trac]

#6286: Directories filtered by member roles
--------------------------+------------------
 Reporter:  sooskriszta   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  2.3
Component:  API           |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------

Comment (by boonebgorges):

 Replying to [comment:18 imath]:
 > @boonebgorges i know you find it ugly but i think there should be a type
 slug like members/type/teacher. Because once it will be possible to use
 this feature users will ask for editable slugs and we could arrive to the
 situation where registering with a teacher username would not be possible
 one day and possible another one as soon as the teacher member type slug
 will be edited or removed.

 I think "editable slugs" (by which I guess you mean "editable
 user_login/nicename"?) is a red herring. But I'm starting to be convinced
 about the problem of user_nicename clashes. If someone registers with the
 name 'teacher', and then the admin activates a plugin that activates the
 member type 'teacher', there will be unpreventable problems. Though, to be
 fair, the same thing could happen in WP with a page called 'foo' and a
 plugin that registers a post_type 'foo'.

 Then again, I think there's also an argument to be made that nearly all
 installations will want to prevent users from using member type names as
 user_login, URL issues aside - it's confusing, bordering on a security
 issue, for users to have names like 'teacher' if you also have a
 member_type called 'teacher'. And the implementation details of a 'type'
 slug are also very ugly: you suggest a filter, but I think that's a
 terrible piece of UX for something so public; a translatable string would
 be better, but causes its own problems.

 Let me sleep on this. I really hate the idea of making the URLs hideous.
 `example.com/members/type/foo` implies a hierarchy that does not exist:
 "type" is not a type of member - "foo" is! But maybe there's no way around
 it.

 > About the feature, i have another question once i arrived on the page
 filtered how i know i'm viewing members having the url member type without
 looking at the url ?

 Yeah, I forgot about this. I'll figure something out.

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