Skip to:
Content

Opened 9 years ago

Closed 7 years ago

#1726 closed defect (bug) (fixed)

WordPress sub folder installation conflicting with component slugs

Reported by: sbrajesh Owned by:
Milestone: 1.6 Priority: major
Severity: Version:
Component: Core Keywords:
Cc: sbrajesh

Description

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.

Attachments (1)

bp-core-catchuri.patch (2.0 KB) - added by sbrajesh 9 years ago.
patches bp-core-catchuri for the component name bug

Download all attachments as: .zip

Change History (11)

@sbrajesh
9 years ago

patches bp-core-catchuri for the component name bug

#1 follow-up: @apeatling
9 years ago

  • Milestone changed from 1.2 to 1.2.1
  • Priority changed from critical to major

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.

#2 in reply to: ↑ 1 @sbrajesh
9 years ago

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

#3 @cnorris23
9 years ago

  • Keywords has-patch needs-testing added

#4 @paulhastings0
8 years ago

  • Component set to Core
  • Summary changed from bug in bp_core_set_uri_globals() to [patch] bug in bp_core_set_uri_globals()

#5 @DJPaul
8 years ago

  • Keywords has-patch needs-testing removed

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

#6 @DJPaul
8 years ago

Confirmed in trunk

#7 @DJPaul
8 years ago

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.

#8 @DJPaul
8 years ago

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?

#9 @DJPaul
8 years ago

  • Milestone changed from 1.3 to 1.4
  • Summary changed from [patch] bug in bp_core_set_uri_globals() to WordPress sub folder installation conflicting with component slugs

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.

#10 @boonebgorges
7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(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

Note: See TracTickets for help on using tickets.