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

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Thu Jan 6 17:09:51 UTC 2011

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

Comment (by boonebgorges):

 I spent some time this morning to sketch out a mostly complete patch for
 the groups component, along the lines of what was discussed yesterday in
 the dev chat. A brief intro to 2600-3.patch:
 - It takes the general direction of 2600-2.patch, which is to say that it
 creates a new root_slug that is used for top pages
 - It adds a bp_core_is_root_component() function that can be used to test
 for current_component in a way that is flexible.

 The patch is, as you can see, enormous (and not even complete with respect
 to groups - there are some finer points having to do with $bp->bp_nav that
 I have not solved yet). In order to make groups tabs work, I had to
 rejigger the kinds of arguments that go into bp_core_new_subnav_item in
 some cases - $root_slug instead of $slug for $parent_slug.

 The bottom line is that the current system - where top-level nav (like
 /groups/group-name/) is one and the same with profile subnav (like
 /members/boonebgorges/groups/) - simply does not cooperate when you want
 the first kind of slug (root_slug) to be different  from the regular slug.
 No matter what we do, we can't guarantee backward compatibility for
 plugins that add nav and subnav pages - they will break when root_slug and
 slug diverge.

 I can go ahead and complete a full patch along the lines of 2600-3.patch,
 but I would like some feedback first.

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

More information about the buddypress-trac mailing list