filter for $after_member_slug in bp-core-catchuri.php

[kmb@…]

Hi,

one can modify the user_domain with the filter "bp_core_get_user_domain".
But there is no way to map this back, so I need a patch like this:

+++ wp-content/plugins/bp-custom.php
@@ -265,6 +265,8 @@ function bp_core_set_uri_globals() {
 
 			// Are we viewing a specific user?
 			if ( $after_member_slug ) {
+				$after_member_slug = apply_filters( 'bp_core_catchuri_after_member_slug', $after_member_slug);
+
 				// Switch the displayed_user based on compatibility mode
 				if ( bp_is_username_compatibility_mode() ) {
 					$bp->displayed_user->id = (int) bp_core_get_userid( urldecode( $after_member_slug ) );

The reason behind this:
I need to create "anonymous" URLs for selected members. The next code-snipped is an example on how to do this.
But be aware, this is just a test to create URLs based on the member-id - not a real anonymizer.

function TEST_anonymize_url($domain, $user_id, $user_nicename, $user_login) {
	$after_domain = bp_core_enable_root_profiles() ? $user_id : bp_get_members_root_slug() . '/' . $user_id;
	$domain       = trailingslashit( bp_get_root_domain() . '/' . $after_domain );

	return $domain;
}
add_action('bp_core_get_user_domain', 'TEST_anonymize_url', 20, 4);

function TEST_de_anonymize_url($after_member_slug) {
	return bp_members_get_user_nicename($after_member_slug);
}
add_action('bp_core_catchuri_after_member_slug', 'TEST_de_anonymize_url', 20);

Would be nice, if you could include this in 2.5.

thanks
Klaus

[DJPaul]

Hi @kmb@…
I can't see any immediate problem with adding a filter here! We'll definitely take a look.

I think this is your third trac ticket for BuddyPress, so thank you for contributing!

[DJPaul]

@boonebgorges or @r-a-y - any concerns with adding this in?

[dcavins]

In bp_core_set_uri_globals() add a filter for $after_member_slug, the portion of the URI immediately following /members/.

[boonebgorges]

I don't have a problem adding a filter, but putting it inside this conditional block seems like it limits its functionality (and has the potential to introduce bugs). See 6694.diff​. This will make callbacks somewhat more complicated; in the situation described by @kmb@…, there may have to be an additional if ( false !== $after_member_slug ) check inside TEST_de_anonymize_url(). But this seems like a reasonable trade-off for a much more flexible filter.

[r-a-y]

02.patch adds the filter to root profile lookups as well. I've also renamed the filter to 'bp_core_set_uri_globals_member_slug'.

One thing to note is for root profiles, we do a check for a WP User with get_user_by(). For regular member lookups, we use bp_core_get_userid() / bp_core_get_userid_from_nicename().

We should probably switch to one method instead of using two different types of lookups here. Might be better to switch to using our BP functions since we have filters in those functions and get_user_by() doesn't.

[boonebgorges]

6694.02.patch​ looks good to me!

One thing to note is for root profiles, we do a check for a WP User with get_user_by(). For regular member lookups, we use bp_core_get_userid() / bp_core_get_userid_from_nicename().

Yeah. Let's look at that in a separate ticket. I would like to see that there is test coverage of root profile routing before it happens. (I think there is, but it should be verified.)

[boonebgorges]

In 10714:

URL routing: Filter the portion of the URI immediately after the 'members' slug.

This allows customizations for routing that is based on something other than
user_nicename.

Props kmb@…, r-a-y.
Fixes #6694.