BP mangles $wp_query when viewing member's profile

[mikelopez]

Hi guys,

Mike here from WishList Products. We have a customer that filed a support request saying that WishList Member cannot protect the BP member's profile page (ex. sitename.com/members/membername)

I investigated the issue and found out though BP successfully loads the page, is_404() actually returns true.

Our plugin already makes use of template_redirect as recommended in #6230 but this doesn't seem to work with the member's profile page. The issue apparently is WP returns a 404 because /members/membername does not exist thus the is_404() thing.

This prevents plugins that deal with the parent page from functioning properly such as WishList Member.

I wonder if BP should just load the content of the parent page and just modify its content? Not sure what trouble this would entail (hopefully not much).

Thoughts?

Thanks.

Mike

[r-a-y]

Your best option is to test if you're on a BP user page with the conditional bp_is_user() function instead of having to do checks on $wp_query.

The same function for testing if you're on a single group page is bp_is_group().

[DJPaul]

I think the question being asked is "why does is_404() return false when on a valid BuddyPress page", which I think it is a fair question as it's counter-intuitive.

[r-a-y]

Mike is doing checks on 'template_redirect' as early as possible. See:
​https://buddypress.trac.wordpress.org/ticket/6230#comment:11

As a consequence, BP hasn't manipulated $wp_query yet, so WP still sees BP single pages as a 404.

His is a special use case for a plugin dealing with access control. Since he wants to add BuddyPress support, in my opinion, he should be using BuddyPress conditional functions due to the current way we are dealing with pages in BuddyPress.

[boonebgorges]

Replying to DJPaul:

I think the question being asked is "why does is_404() return false when on a valid BuddyPress page", which I think it is a fair question as it's counter-intuitive.

I think you mean "why does is_404() return *true*?". r-a-y's answer is right. We do kind of a complicated dance. WP's native page router (WP::parse_request()) interprets BP member URLs as 404s (since there is no WP content located at example.com/members/boone/, which would presumably be a page boone with a page members as the parent). In bp_core_load_template(), which is called from our template controllers, is_404 is manually flipped back to false if BP determines that there is, in fact, BP content to look at. This means that from parse_request until bp_screens - run on bp_template_redirect, which in turn is run at template_redirect - WP thinks the current content is a 404. If WishList Member is also loading at template_redirect, it's likely that WishList Member is being loaded before BP has had a chance to do these resets.

The whole situation is not ideal. I guess I agree with r-a-y that, in the short term, WLM will have to work around BP in some way, either by using a BP function like bp_is_user() or by delaying its check until after template_redirect:10, though it appears that the latter suggestion will interfere with what r-a-y suggested in #6230. This is another problem that would go away with proper use of rewrite rules. In the meantime, we could and perhaps should try to do the wp_query manipulation (like is_404=false) earlier than bp_core_load_template(). Is that even possible?

There was another ticket about this very issue a couple years ago, though in 30 minutes of looking I was unable to find it :-/

[mikelopez]

A quick question, why is that activity pages such as /activity/xxxx return the proper page ID even though the requested URL is not valid?

Is it possible to do the same handling for /members/aaaaaa and other similar URLs?

[r-a-y]

A quick question, why is that activity pages such as /activity/xxxx return the proper page ID even though the requested URL is not valid?

Good question. This is due to WP's split page parsing when a number is used after a page slug. For example, you could go to a URL like this:
example.com/sample-page/999/ (replace 999 with any number)

And that will still render the page with the sample-page queried object because WP thinks 999 is a split page (to me, this is a WP bug). An authentic split page uses the <!--nextpage--> tag in the post content:
​http://codex.wordpress.org/Styling_Page-Links

If you add an invalid non-numeric page slug after sample-page like /sample-page/blah/, this would render a 404.

Since /activity/ is a valid WP post slug and you are using a number after the slug, the behavior above describes what is happening.

Is it possible to do the same handling for /members/aaaaaa and other similar URLs?

Knowing the loophole above, you can get the queried object if the username is numeric :) But that's about it.

[mikelopez]

@r-a-y - Gotcha. Thanks for the explanation. Didn't know that before.

[DJPaul]

So... do we need to do anything here for this ticket?

[mikelopez]

Replying to DJPaul:

So... do we need to do anything here for this ticket?

It would be nice if it could be "fixed" but based on discussions, it's not a bug. Sounds like there's nothing to be done. We made changes to WLM and we're just waiting for feedback from our client whether it works or not.

[mikelopez]

Just for the record, got word from our client and said that our update fixed the issue reported here.

Here's what we did in WishList Member just in case someone experiencing the same problem is looking for a solution and stumbles on this ticket.

In our template_redirect hook, we added the following on top:

global $wp_query;

// Start: Compatibiltiy fix for BuddyPress members and groups
if ( function_exists( 'bp_is_user' ) && function_exists( 'bp_is_group' ) ) {
	if ( bp_is_user() ) {
		$bp_content_slug = $GLOBALS['bp']->pages->members->slug;
	} elseif ( bp_is_group() ) {
		$bp_content_slug = $GLOBALS['bp']->pages->groups->slug;
	}
	if ( !empty( $bp_content_slug ) ) {
		$wp_query = new WP_Query( array( 'pagename' => $bp_content_slug ) );
	}
}
// End: Compatibiltiy fix for BuddyPress members and groups

Unless anyone from BP thinks that this should be fix, then I think it's fine to mark this as resolved already.

Thanks guys!

Mike

[DJPaul]

Moving to FR so the issue isn't overlooked when we work on the router in the future.

[espellcaste]

This might not be relevant anymore since BuddyPress 12.0.