[buddypress-trac] [BuddyPress Trac] #6527: BP mangles $wp_query when viewing member's profile

[buddypress-trac]

#6527: BP mangles $wp_query when viewing member's profile
---------------------------------+------------------------------
 Reporter:  mikelopez            |       Owner:
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  Awaiting Review
Component:  Component - Members  |     Version:  2.3.0
 Severity:  normal               |  Resolution:
 Keywords:  2nd-opinion          |
---------------------------------+------------------------------

Comment (by boonebgorges):

 Replying to [comment:2 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 :-/

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6527#comment:4>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac