Compatibility with language subdirectories

[liongrass]

Hi,

since the introduction of the new Rewrite API, i haven't found a good way to make BP Profiles compatible with language subdirectories (e.g "mydomain.com/en/john-doe").

With the legacy parser, it was possible to hook in at certain points and make the whole thing work, but now there doesn't seem to be a way to do this anymore. From what i understand right now, a filter in BP_Members_Component->parse_query() would be required, just before "bp_rewrites_get_member_data()" gets called:

Before:

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

After:

<?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);

This would allow for the requested URI to be filtered, right before it get's passed to "bp_rewrites_get_member_data" and manipulate it such that this function knows where to look for the username in the string.

[imath]

Hi,

Thanks for your feedback, there’s a way to add a ​root prefix to URLs, but I don’t think it would be a viable solution as I guess the « en » thing can be « fr » or « es » and rewrite rules are saved to the database.

How do you manage what you call language subdirectories with regular WordPress posts or pages ?

[liongrass]

Replying to imath:

Hi,

Thanks for your feedback, there’s a way to add a ​root prefix to URLs, but I don’t think it would be a viable solution as I guess the « en » thing can be « fr » or « es » and rewrite rules are saved to the database.

How do you manage what you call language subdirectories with regular WordPress posts or pages ?

I just use the Polylang plugin, you can set it up to use your site with language subdirectories.

[liongrass]

May i submit a pull request to add the aforementioned filter? If you have a better name for the filter btw let me know!

Adds a filter to the BP_Members_Component->parse_query method, that allows for the request object to be filtered, right before it get's passed to "bp_rewrites_get_member_data".

If member profiles are not used with the default URI, for example when using language subdirectories, BuddyPress will throw a 404. This filter allows for the requested URI to be manipulated such that "bp_rewrites_get_member_data" knows where to look for the username in the URI.

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/9235

[liongrass]

*BUMP*

Patch has been avalaible for some time now

[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.

[liongrass]

Replying to 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
               $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.

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/9235

[espellcaste]

@liongrass Could you test the suggested approach in the pull request above? Just to make sure this solution will work for your use case.

[liongrass]

Replying to espellcaste:

@liongrass Could you test the suggested approach in the pull request above? Just to make sure this solution will work for your use case.

Yep, this works for me.

That being said, I use BuddyPress with root profiles enabled. Using this filter to modify the URI will have no effect if the default URI structure (e.g., "members/john-doe") is used, because in that case the user data to load is determined later. For someone not using root profiles another approach would be required.

In general, getting BuddyPress to be compatible with language subdirectories requires some workarounds, if there were a built-in way to have it dynamically parse URIs with an offset, that would make the whole thing much easier.

[espellcaste]

Thanks for that. I'll postpone this for the future. I'd love someone who could dive into this world in the near future and suggest a good solution.

I personally don't have much experience with communities with different languages. And I think this hook might be incomplete or might need to be reverted/removed.