Updating profile in back-end appends characters to user_nicename

[jfarthing84]

Just like the title says, when using user-edit.php in the back-end to edit a user with BP installed, it oddly appends a "-2" to the user_nicename field in the database. This, in turn, makes the author posts URL mysite.com/author/author_nicename-2 or, depending on how many times it has been updated, mysite.com/author/author_nicename-2-2-2-2.

BP 1.2.5.2
WP 3.0.1

[jfarthing84]

Nothing?

[DJPaul]

It is too late for anything for 1.2.6.

[nuprn1]

discussion on the ticket
http://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/buddypress-changing-profile-urls-when-profile-is-updated/

[DJPaul]

I can't recreate this on WordPress (not multisite) with BuddyPress 1.2.6. I also can't find anywhere in the code where BuddyPress ever changes a user's user_nicename. Is this on multisite, and does the behaviour remain if you disable all other plugins and revert to BP-Default? We can bump the priority back up once we can recreate it.

[DJPaul]

Also, please clarify which field(s) you are changing.

[jfarthing84]

Not multisite. Still happens with all other plugins disabled, and does'nt happen with BP disabled. Doesn't matter what field. You don't have to change anything. Just click "Update User" and it happens.

[DJPaul]

Per Rich's post on the forum topic, unless this was something fixed in/for BP 1.2.6 (I don't think it was), the only way I can sort-of recreate this is to edit a user whose user_login matches another user's user_nicename.

[DJPaul]

And that happens even with BP disabled.

[hnla]

Can't re-create: WP 3.0.1 MS / BP 1.2.5.2

Changed all name fields in WP backend edit-user: changed display name, changed user biographical info, changed email, or simply clicking update user.

[jfarthing84]

I figured it out. Try it with a user_login with spaces. You will see the results I reported.

It is caused by bp_core_strip_username_spaces() being applied to the "pre_user_login" filter.

Then, within wp_insert_user(), it checks for an existing user_nicename that doesn't match with the user_login being updated. In this case, BP changes the user_login from it's real value. So, wordpress thinks that the nicename already exists for a different user and appends a suffix.

[jfarthing84]

So, I guess BP tries to circumvent users from signing up with spaced user login by adding dashes. In this particular case, the users existed pre-BP with spaces.

In other words, this BP filter shouldn't run when UPDATING a user.

[nuprn1]

bp_core_strip_username_spaces - probably required for catch_uri for the member url

[jfarthing84]

Not sure why it is used, but it is used improperly.

If the case were what you say, this is ill-advised as the user_nicename field is already sanitized. So, it should be used over user_login.

[nuprn1]

i don't know the original intention - a question for Andy but nicename is by default, if BP_ENABLE_USERNAME_COMPATIBILITY_MODE then user_login is used in catchuri

[jfarthing84]

In this particular case, no custom constants have been defined, so it's the default value.

In the case of the constant, if it works as you say, then the callback for "pre_user_login" should only be applied when the constant is defined anyway.

[boonebgorges]

(In [3675]) Prevents BP from stripping spaces from usernames for existing users, to prevent user_nicename clashes. Fixes #2642. Props jfarthing84