[buddypress-trac] [BuddyPress] #2600: WP pages as component slugs causes redirect problems

[buddypress-trac at lists.automattic.com]

#2600: WP pages as component slugs causes redirect problems
---------------------------+-----------------
  Reporter:  boonebgorges  |      Owner:
      Type:  defect        |     Status:  new
  Priority:  critical      |  Milestone:  1.3
 Component:  Activity      |    Version:
Resolution:                |   Keywords:
---------------------------+-----------------

Comment (by boonebgorges):

 2600-1.patch is a proof of concept for the third option I mentioned above,
 done for the groups component. I have chosen to call the new value a
 'mid_slug', because it appears in the middle of paths rather than toward
 the beginning as in the case of the top-level directories, but I am
 certainly welcome to better suggestions.

 Most of it is straightforward. The only bit of trickiness is in the
 definition of $bp->groups->mid_slug. If BP_GROUPS_SLUG has no slashes in
 it (ie is a top-level page) then it gets copied over to mid_slug.
 Otherwise it defaults to 'groups'.

 One (perhaps minor) concern is that some components do not have top-level
 directories associated with them (friends, messages). If this proposal is
 applied to those components, then things like $bp->friends->slug will, in
 effect, never be used. Alternatively, since those components don't have
 top-level pages associated with them, maybe it makes sense to handle them
 separately.

 Another concern is that this change will almost certainly break some
 plugins. I don't see a way around that. If we wanted a potentially more
 consistent and less harmful solution, we could instead keep using
 $bp->[component]->slug for middle-of-path uses, and instead make the
 directory-level slug the new piece of data. Eg,
 $bp->groups->directory_slug would be set by looking at $bp_pages, and
 $bp->groups->slug would be set in the same way as I'm setting mid_slug in
 this patch. Actually, the more I think about it, the more I think that
 this solution will seem more consistent to plugin devs.

 Thoughts?

-- 
Ticket URL: <http://trac.buddypress.org/ticket/2600#comment:2>
BuddyPress <http://buddypress.org/>
BuddyPress