[buddypress-trac] [BuddyPress] #4329: Changes in function bp_is_user() and bp_actions hook

[buddypress-trac at lists.automattic.com]

#4329: Changes in function bp_is_user() and bp_actions hook
--------------------------+-----------------------------
 Reporter:  imath         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Core          |     Version:  1.6-beta
 Severity:  critical      |  Resolution:
 Keywords:  1.7-early     |
--------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:   => 1.7-early
 * severity:  normal => critical
 * milestone:  Awaiting Review => Future Release


Comment:

 Confirmed.

 Here's the issue. During the main WP query, is_404 gets marked true,
 because while there may be a page at /members/, there is no page at
 /members/foo/. We unset the 404 and manually set
 `$wp_query->queried_object` during `bp_core_load_template()`. As a result,
 there is a period, between when the main query is run and when the
 template is loaded, where WP thinks that it'll be sending a 404. As imath
 notes, when you run `bp_is_user()` inside of the template itself, it works
 as expected.

 This is not a regression. It's been this way, as far as I can tell, since
 when BuddyPress's URL parser was first written.

 There are a few different possible solutions. The first, fairly easy
 solution is to move the first half of `bp_core_load_template()` (which is
 responsible for manually setting the queried_object) to its own function,
 which runs much much earlier in the load process. We should probably do
 this for 1.7. The second, complex solution is to chuck our URL parser
 altogether and switch to proper use of WP's rewrite rules + filters on
 parse_request, etc. This is what we should shoot for in two or three
 releases.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4329#comment:1>
BuddyPress <http://buddypress.org/>
BuddyPress