WordPress sub folder installation conflicting with component slugs

[sbrajesh]

bp_core_set_uri_globals() is used to setup the current component/other global variables for buddypress.

While working with my most recent project, I discovered a critical bug with it.

Problem: If you install buddypress in a directory 'x' and there exists a component with name 'x' the component will never be loaded, as It resets the component.

How to reproduce: Install wpmu/buddypress in a sub directory say "groups" and then activate buddypress, when you will nagivate to ​http://yoursite.com/groups/members/admin/groups, It will not load groups.
Neither will be this page
​http://yoursite.com/groups/groups

reason: In bp_core_set_uri_globals(), on line 86-90
the code
foreach ( (array)$bp_uri as $key => $uri_chunk ) {

if ( in_array( $uri_chunk, $paths )) {

unset( $bp_uri[$key] );

}

}

resets, the component name too, if the path contains a string with the name of the component.

here I am attaching a diff file, which I tested on suubdirectory install, but I have not tested it on the main domain install/subdomains, so some test may be required.

[sbrajesh]

patches bp-core-catchuri for the component name bug

[apeatling]

This is a fairly major change and in reality is an edge case. I agree it is important to fix this, but it's too risky to start messing with the catch_uri() functions this close to a release. We may bring up many unforseen bugs since you have to do extensive testing on a variety of different setups. I'm bumping this to 1.2.1, with a note in 1.2 about this.

[sbrajesh]

Replying to apeatling:

This is a fairly major change and in reality is an edge case. I agree it is important to fix this, but it's too risky to start messing with the catch_uri() functions this close to a release. We may bring up many unforseen bugs since you have to do extensive testing on a variety of different setups. I'm bumping this to 1.2.1, with a note in 1.2 about this.

Thanks Andy, I understand BP 1.2 is on the verge of release and playing with catch_uri can cause unexpected results. Btw, there are a few helpful people I know, testing this patch on the other setups(subdomains/multiblog etc), and Based on their feedback, I hope It can be easily fixed in bp 1.2.1

[DJPaul]

We're going to have to look at this again due to the changes in trunk to load BuddyPress pages as pages :)

[DJPaul]

Confirmed in trunk

[DJPaul]

When we start to use custom post types, it would make much more sense to see if we can add our own wp_rewrite parsing code/rewrites rather than the approach in bp_core_set_uri_globals() as-is. But I digress:

Now that we are using WordPress pages for the components, and when #2609 is fixed, I believe we should be able to use: global $wp; $wp->request in bp_core_set_uri_globals() in place of this:

	// Ajax or not?
	if ( strpos( $_SERVER['REQUEST_URI'], 'wp-load.php' ) )
		$path = bp_core_referrer();
	else
		$path = esc_url( $_SERVER['REQUEST_URI'] );

	$path = apply_filters( 'bp_uri', $path );

In the case of a subdirectory installation, $wp->request already strips off the directory name(s) as well as any ?query=strings on the URL.

[DJPaul]

Alas, didn't work. $wp->parse_request() happens after wp_loaded, and BuddyPress is necessarily hooked in much earlier. Wonder if it's worth copy+paste the stuff in parse_request() up to where $this->request is set?

[DJPaul]

I spent alot of time looking at this today and I have a patch allowing BuddyPress to work in any directory, but only on non-multisite (subdir sites). Looking at the time it will take to get it working and validate correct functioning, I think we should tackle this in 1.4 when we will get this "for free" as a side benefit of the switch to custom post types... unless someone wants to take on the issue and patch and test.

[boonebgorges]

(In [5398]) When cross-referencing the bp_uri stack against paths in bp_core_set_uri_globals(), only remove matches that appear at the same index. Fixes #1726. Props sbrajesh for an early patch