[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