#4329 closed defect (bug) (worksforme)
Changes in function bp_is_user() and bp_actions hook
Reported by: | imath | Owned by: | |
---|---|---|---|
Milestone: | 1.7.1 | Priority: | normal |
Severity: | critical | Version: | 1.6 |
Component: | Core | Keywords: | |
Cc: |
Description
Good evening,
Since 1.6 beta 1, when i want to use bp_is_user() to check after using the hook bp_actions, it returns false even if i'm on displayed user.
exemple :
function my_function() { var_dump( bp_is_user() ); // will return false even if i'm on the displayed user } add_action('bp_actions', 'my_function'); // But : function my_function_bis() { var_dump( bp_is_user()); //will return true } add_action('bp_head', 'my_function_bis');
After some research it appears that when you use bp_actions hook and you are on all the member/user templates is_404 is true... And as bp_is_user return false if is_404 is true, then i cannot use it to check if i'm on a member/user template
Exemple :
function my_function_ter() { var_dump( is_404() ); //wil return true if i'm on http://siteurl/members/imath (activity, profile, messages, ...) } add_action('bp_actions', 'my_function_ter');
So for my plugin i fixed my issue by using bp_displayed_user_id() instead, but i thought i should report this change of behavior.
Good night.
Change History (5)
#1
@
12 years ago
- Keywords 1.7-early added
- Milestone changed from Awaiting Review to Future Release
- Severity changed from normal to critical
#3
@
12 years ago
- Milestone changed from 1.7 to 1.8
No action in months, so moving to 1.8 (when I'd like to switch to core rewrites.)
#4
@
12 years ago
- Milestone changed from 1.8 to 1.7.1
- Resolution set to worksforme
- Status changed from new to closed
In imath's example above, bp_is_user()
now returns true again as of BP 1.7.1:
http://buddypress.trac.wordpress.org/ticket/3815#comment:6
However, the is_404()
example above and which Boone notes here still exists, but is probably not worth looking into until JJJ looks at rewrite rules for 1.8.
Going to mark as resolved since the bp_is_user()
issue is addressed.
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
duringbp_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 runbp_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.