[buddypress-trac] [BuddyPress Trac] #9235: Compatibility with language subdirectories

[buddypress-trac]

#9235: Compatibility with language subdirectories
------------------------------------+----------------------------------
 Reporter:  liongrass               |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Under Consideration
Component:  Members                 |     Version:  12.0.0
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+----------------------------------

Comment (by liongrass):

 Replying to [comment:7 espellcaste]:
 > I'd like to spend more time on this one. The patch looks simple but I
 think I'm missing something here. I wonder why the Polylang plugin can't
 create this rewrite rule itself, since it is providing the support for the
 language subdirectories.
 >
 > I've never used this plugin, so I can't tell.
 >
 > About the patch: it looks correct, but there are other places where the
 `$GLOBALS['wp']->request` is used which this hook doesn't take that into
 account.

 You are correct, after the request is filtered, all occurences of
 `$GLOBALS['wp']->request` within the method should be replaced with the
 filtered $request. I did miss a line, here is the updated solution:

 {{{#!php
 <?php
                $request = apply_filters('bp_members_parse_query_request',
 $GLOBALS['wp']->request);

                 // Init the current member and member type.
                 $member      = false;
                 $member_type = false;
                 $member_data = bp_rewrites_get_member_data($request);

                 if ( isset( $member_data['object'] ) &&
 $member_data['object'] ) {
                         bp_reset_query( trailingslashit( $this->root_slug
 ) . $request, $query );  // $GLOBALS['wp']->request replaced with
 $request, so filtered request is used
 //  [...]
 }
 }}}

 I am not sure about other places where `$GLOBALS['wp']->request` might be
 used, but from what i understand, the BP_Members_Component->parse_query
 method is the only place where it is used to determine which member
 profile to load.

 As to why Polylang doesn't support BuddyPress Member Profiles, i think it
 just never did. But i am also not sure how it would achieve that, without
 leveraging a filter on the BuddyPress side of things.

 Polylang does it's language stuff first and after that, BuddyPress comes
 in, looks at the URI and tries to determine the member profile to load.
 But since the language subdirectory is now where BuddyPress expects the
 username, user lookup fails and we get the 404.

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