[buddypress-trac] [BuddyPress] #2647: bp_core_catch_uri redirects to root and doesn't pass referer for login redirect
buddypress-trac at lists.automattic.com
buddypress-trac at lists.automattic.com
Fri May 13 19:34:22 UTC 2011
#2647: bp_core_catch_uri redirects to root and doesn't pass referer for login
redirect
-----------------------+-------------------------
Reporter: ethitter | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.4
Component: Core | Version:
Resolution: | Keywords: needs-patch
-----------------------+-------------------------
Comment (by acustica):
Let me preface this by saying that after writing what's below, I took a
look at the current version of bp-core-catchuri.php in version control (in
the trunk, as of r4172) and it has been totally rewritten (and the
bp_core_catch_no_access() function I mention below no longer exists). So
perhaps this is just a waste of time. But I don't actually understand what
version of BP the trunk represents and it's relationship to BP public
releases, so in case this could be fixed before the next major version,
I'll still post my notes and patch (sorry if it is now irrelevant):
This may require serious in-depth development and be beyond the scope of
BP 1.3, as boonebgorges, but I am not yet convinced. The problem, at least
in my case, lies in this one line:
{{{
// If the template file doesn't exist, redirect to the root domain.
if ( !bp_is_blog_page() && !file_exists( apply_filters(
'bp_located_template', locate_template( $filtered_templates, false ),
$filtered_templates ) ) )
bp_core_redirect( $bp->root_domain );
}}}
in the bp_core_catch_no_access() function in bp-core/bp-core-catchuri.php.
To elaborate on this ticket's description, the point seems to be to ensure
that BP actually has a real template file to use to handle the current
request. However, in many cases, what it is really checking is whether a
BP component has to have already called bp_core_load_template(), which
never happens if the component decides the current user doesn't have
permission to access it.
It seems to me that these problems can be remedied by just changing the
order of the checks that happen in the bp_core_catch_no_access() function.
If the above check comes after this check, which handles situations where
$bp_path is not set like I described above:
{{{
if ( !$bp_path && !bp_is_blog_page() ) {
if ( is_user_logged_in() ) {
wp_redirect( $bp->root_domain );
} else {
wp_redirect( site_url( 'wp-login.php?redirect_to=' .
site_url() . $_SERVER['REQUEST_URI'] ) );
}
}
}}}
then it would actually make sense. As it is, the above check, which routes
a non-logged in user to a login page with the proper redirect_to set, is
pointless, because if !$bp_path, then obviously the file_exists() call
will return false.
That's my interpretation, so please correct me if I'm wrong (and if it's
still relevant). I've attached a patch implementing my proposed fix based
on the r3233 version of this file.
And lastly, on my site, I've just added a 'bp_located_template' filter to
bypass the file_exists() check and it currently works like a charm (hoping
there aren't any unforeseen consequences), but it's obviously less than
ideal to remove the check to confirm the template file exists. To see the
code and description, please see my post here:
http://buddypress.org/community/groups/how-to-and-
troubleshooting/forum/topic/friend-request-wp-login-redirects/#post-98565
--
Ticket URL: <https://trac.buddypress.org/ticket/2647#comment:5>
BuddyPress <http://buddypress.org/>
BuddyPress
More information about the buddypress-trac
mailing list