Skip to:

Opened 14 years ago

Closed 13 years ago

#2642 closed defect (bug) (fixed)

Updating profile in back-end appends characters to user_nicename

Reported by: jfarthing84's profile jfarthing84 Owned by:
Milestone: 1.5 Priority: normal
Severity: Version:
Component: Core Keywords: reporter-feedback
Cc: jeff@…


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 or, depending on how many times it has been updated,

WP 3.0.1

Change History (16)

#1 @jfarthing84
14 years ago

  • Milestone changed from 1.3 to 1.2.6
  • Priority changed from major to blocker


#2 @DJPaul
14 years ago

  • Milestone changed from 1.2.6 to 1.3

It is too late for anything for 1.2.6.

#4 @DJPaul
14 years ago

  • Keywords reporter-feedback added; dev-feedback removed
  • Priority changed from blocker to normal

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.

#5 @DJPaul
14 years ago

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

#6 @jfarthing84
14 years ago

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.

#7 @DJPaul
14 years ago

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.

#8 @DJPaul
14 years ago

And that happens even with BP disabled.

#9 @hnla
14 years ago

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

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

#10 @jfarthing84
14 years ago

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.

#11 @jfarthing84
14 years ago

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.

#12 @nuprn1
14 years ago

bp_core_strip_username_spaces - probably required for catch_uri for the member url

#13 @jfarthing84
14 years ago

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.

#14 @nuprn1
14 years ago

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

#15 @jfarthing84
14 years ago

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.

#16 @boonebgorges
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.