Spaces allowed in screen names since 1.6 update

[oceanwidedesigns]

More details here:
http://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/1-6-allowing-users-to-register-with-spaces-in-sn-1/?#post-141606

basically since the 1.6 update, the system has allowed people to register with spaces in their usernames AND with uppercase characters. The spaces are being converted to hyphens, but the user is unaware of that since they never receive their username via email after registering. This has become a customer service NIGHTMARE!

[Mqlte]

I totally agree with you, this is really confusing for new users. Anyway, why is it a problem to allow useres "real" spaces? I would appreciate it.

[r-a-y]

BuddyPress made a change in 1.6 to validate usernames against WordPress' ​validate_username() function.

Apparently, that function allows spaces.

I can see how this is a regression from v1.5; I'm going to see if the other devs have a problem with adding back the space check.

[boonebgorges]

Where are spaces being converted to hyphens? I don't see it in validate_username() or in sanitize_user() (which validate_username() uses). It's possible that there's a stray filter in there or something.

In any case, I am wary of adding our own username validation back in. We're using WP for authorization, so we should have exactly the same restrictions on usernames that WP has.

[r-a-y]

The hyphens are caused by the pre_user_login filter. We could remove that filter and that would probably address this issue; we'd need to do some testing to see what would happen though especially with profile URLs and user_login vs. user_nicename.

If you use a space in the username, an error will not be shown when you submit the form. validate_username() is responsible for this.

[boonebgorges]

We could remove that filter and that would probably address this issue; we'd need to do some testing to see what would happen though especially with profile URLs and user_login vs. user_nicename.

Right. Aesthetically, I would like to get rid of this filter, but as you note, we need to research what's going to happen. The only problem would be with username-compatibility mode, I think (since we use user_nicename by default). In those cases, I wonder if we can just fix the issue with the judicious use of urlencode() and urldecode().

Let's figure something out for 1.7, if we can.

[DJPaul]

Not keen on interfering with username validation again; that's why we took it out.

but the user is unaware of that since they never receive their username via email after registering.

Emails not being received is beyond the scope of the ticket. We could add the username to the 'activate your account' email.

[oceanwidedesigns]

Replying to DJPaul:

but the user is unaware of that since they never receive their username via email after registering.

Emails not being received is beyond the scope of the ticket. We could add the username to the 'activate your account' email.

I never said emails weren't being received, but that there is no way of the user knowing that their desired username was modified with hyphens since the activation email doesn't mention their username.

Is there any way this can be worked around until there's an actual fix? I'm pretty flabbergasted that this is the first time the bug has been reported here, since there's dozens of threads in the support forums about this customer service nightmare.

[boonebgorges]

Is there any way this can be worked around until there's an actual fix?

To prevent the conversion of spaces to hyphens:

remove_action( 'pre_user_login', 'bp_core_strip_username_spaces' );

To keep the conversion in place but throw an error during registration when someone attempts to create a user with spaces in the username, a quick and dirty fix is:

function bp_4622_check_for_spaces_at_registration( $valid, $username ) {
    if ( false !== strpos( $username, ' ' ) ) {
        $valid = false;
    }
    return $valid;
}
add_filter( 'validate_username', 'bp_4622_check_for_spaces_at_registration', 10, 2 );

Haven't tested it, but it should result in the "Only lowercase letters and numbers allowed" error being thrown.

We could add the username to the 'activate your account' email.

These seems like a sensible thing to do, regardless of how the username validation stuff is resolved.

[mercime]

Recalled this ticket when I was reading @sbrajesh's post ​re same issue

[DJPaul]

I'm bumping this from 1.7 to help clear the milestone. This ticket's been up for 3 months and no-one's suggested a good solution to this problem yet.

[deltafactory]

Weighing in that I'd like to see this fixed earlier in the name normalization process.

For some added complexity, we use WooCommerce's registration forms to create the user. In the current production version, they improperly handle when the $user_id comes back as a WP_Error object. The resulting cast to int messes up the admin user: no fun. I've already submitted a patch for this.

Our current solution is to add a filter for sanitize_user (which I believe validate_username() calls). I couldn't use bp_core_strip_username_spaces() because it uses username_exists() which eventually calls sanitize_user() resulting in an endless loop until memory_limit was reached.

I understand that it's a tricky issue to fix in a compatible way. I think sanitize_user is the likely choice.

[boonebgorges]

The WooCommerce issue sounds like a nasty bug, though as you note, it's not really ours to fix.

If you're having problems with an infinite loop, you can fix it like this:

function my_sanitizing_function() {
    remove_filter( 'sanitize_user', 'my_sanitizing_function' );
    $foo = bp_core_strip_username_spaces( $bar );
    /// etc
}
add_filter( 'sanitize_user', 'my_sanitizing_function' );

I'll reiterate the core team's belief that BP has no business intervening in the username validation process. If you want to impose specific username requirements, there should be core filters in place to allow you to do so. I haven't seen any compelling reason why BP needs to add any global restrictions on top of WP's.

That said, it does look like there's still an issue to be addressed here, which is that sometimes BP replaces spaces with hyphens but doesn't tell the user about it. We need to clear up this situation with better error reporting. As far as I can see, that's the reason the ticket is still open.

[JoeDorocak]

I hope this gets fixed in BP 1.7. I reported this in Ticket #4838, which was closed because it duplicated this ticket. In #4838 I described what amounts to a workaround:

With BuddyPress1.7Beta1 ACTIVATED on WordPress 3.5.1, when I Add New User named "New Person", the resulting item in the All Users menu comes up as "New-Person".

When I DEACTIVATE BuddyPress1.7Beta1 and Add New User named "Sven Notmyname", NO HYPHEN IS INSERTED. And the resulting item in the All Users menu comes up as "Sven Notmyname".

When I re-ACTIVATE BuddyPress1.7Beta1, and look at the All Users menu:
The entry for "New Person" shows "New-Person". [See screen shot file. [in #4838]]
The entry for "Sven Notmyname" shows "Sven Notmyname". [NO HYPHEN ADDED]

But this is a pain.

Anyway, thanks for the GREAT plugin.

Love and peace,

Joe

[JoeDorocak]

When I click on the More details here link in the ticket, i get "Error 404 - Destination Not Found".

I don't have too much experience with WordPress/BuddyPress, but maybe i can do some research that will help.

Anyway, thanks for the GREAT plugin.

Love and peace,

Joe

[boonebgorges]

Not sure why the original link is broken, but here's the thread: http://buddypress.org/support/topic/1-6-allowing-users-to-register-with-spaces-in-sn/

[r-a-y]

01.patch allows users to register with spaces.

Because we're allowing users to register with spaces, there are a couple of things that needed to be addressed if 'BP_ENABLE_USERNAME_COMPATIBILITY_MODE' is defined.

The patch addresses:

• Member permalinks in the member loop shouldn't fallback to user_nicename when a space is found in the username

• For @mentions to work, we cannot allow spaces to be used, so in the patch, we will always use the user_nicename.

• Needed to add additional template functions so we could grab the logged-in user nicename and the displayed user nicename to be used for the @mention name in the member header.

---

The big problem here is changing the member-header.php template to use the new template function.

This is a backpat problem for themes that have already overriden member-header.php in their custom themes.

I see two options here:

1. Make the change in the member-header.php and do a post on bpdevel.wordpress.com about this.

2. Do not make the change and instead filter bp_displayed_user_username() to use the user_nicename for the member header only. This kinda sucks.

This is only a problem if 'BP_ENABLE_USERNAME_COMPATIBILITY_MODE' is defined and if there are users with spaces in their user_login.

[boonebgorges]

See also ​https://buddypress.trac.wordpress.org/ticket/4057#comment:7

[jakewho]

Any updated information about when a fix to this issue is going to be available?

[boonebgorges]

Going to close this ticket in favor of #5185, where I'm about to post a patch.

[boonebgorges]

In 7570:

Remove BuddyPress's restriction spaces in user_login

BuddyPress has historically enforced a no-spaces rule on user_login during
user registration. Originally this was rooted in WPMU's own peculiar character
restrictions, and when the MU requirement was dropped, the same restrictions
were carried over to WordPress Single.

However, these restrictions have caused various problems. BP enforced the "no
spaces" rule during registration by simply swapping out spaces with hyphens and
not telling users. This caused immense confusion. Moreover, the restriction
caused problems when bypassing BP's native user registration, as when
integrating with an external authentication service; these external usernames
*can* sometimes have spaces, and certain areas of BuddyPress were not equipped
to deal with them.

This changeset removes the no-spaces restriction from BuddyPress, and hands
off user_login validation to WordPress Multisite when possible (meaning that on
MS, spaces will still not be allowed during native registration). It also
makes the necessary adjustments throughout BuddyPress to ensure that spaces
in user_login will not break related functionality. On a normal setup, BP (and
WP) only use user_login for authentication, but several changes were necessary
to account for "username compatibility mode", where the user_login is displayed
publicly:

• Refactor the way that activity @-mentions work in username compatibility mode. We now have functions for converting user IDs to "mentionname" (and vice versa) which will produce @-mention-safe versions of user_nicename or user_login, as appropriate.
• Use proper URL encoding when building and parsing URLs that contain usernames when compatibility mode is enabled.
• Fix private messaging autocomplete to work with spaces.

See #4622

Fixes #5185