404 error page not being used when root profiles is enabled

[henrywright]

1. Enable root profiles by adding the following to bp-custom.php

define ( 'BP_ENABLE_ROOT_PROFILES', true );

2. Visit page example.com/username/jahayatsfg

What should happen:
You should be taken to a 404 page because "jahayatsfg" obviously doesn't exist.

What actually happens:
I'm not entirely sure which page it is that you're taken to but it isn't the 404 page as you would expect.

[DJPaul]

Confirmed. Putting this in 1.9 for attention.

[boonebgorges]

The problem is caused by ​http://buddypress.trac.wordpress.org/browser/trunk/bp-core/bp-core-catchuri.php?annotate=blame#L214. It's incorrect that 'members' should be forced into query_args['pagename']. This forces WordPress to populate the Members page, when in fact, BuddyPress doesn't really want the members page to show up as the queried_object - BP is responsible for manually resetting the bits of $wp_query that it needs.

It's all a bit confusing, but I'm going to go ahead and remove the filter. I'll draw attention to the issue during 1.9's beta period, and hopefully if there are problems, they'll be found. We can always revert.

[boonebgorges]

In 7581:

Don't force WP to load the 'members' page when BP_ENABLE_ROOT_PROFILES

Forcing 'members' into the $wp_query query_args forces WP to load the Members
page as the currently queried object. This, in turn, causes problems with the
(somewhat obfuscated) way that BuddyPress manually manages 404 status when root
profiles are enabled. As a result, URLs like example.com/boone/foo (where 'foo'
is a nonexistent component) loaded the raw Members WP page, rather than 404ing
as BP has such a request do under normal circumstances.

We correct the problem by refraining from forcing $wp_query to load Members.

Fixes #5149