BuddyPress.org

hi @horroruk

read a bit from here:
https://buddypress.org/support/search/mention+display+name+instead+of+username/

and specially this topic 😉
https://buddypress.org/support/topic/conflict-sort-of-with-social-login-mentions/

Short of giving your users extra hugs and re-assuring them that their WordPress usernames aren’t particularly private bits of data, you’re going to have to get your hands dirty. 🙂

It might be down to how the other plugin creates user accounts. Most plugins that allow sign-in using other services’ authentication systems (such as Facebook) don’t “properly” create WordPress user accounts; they use MySQL statements directly instead of using WordPress’ APIs.

This can cause problems with plugins that expect certain user record fields to be in a particular format (if some other plugin came along and just inserted something in a custom format in place). I am not saying that this is the case with this plugin, as I haven’t looked at its code, but I’ve seen this sort of thing before.

If you can create a test account and then go into your DB’s wp_users table and find your test user, and let us know what the values of the user_login, user_nicename, display_name fields are — and which one of these @mentions is using, and which one you would like it to use.

I built @mentions in the last BuddyPress release and while I’m not sure if it’s possible to get it to change how it behaves like this, understanding what you’d want different with real data from a test account will help us help you, and at worse, give a suggestion for ways we could make advanced customisations possible for this in future BuddyPress releases.

Hey! for BP 6.1 :
Lous thinking!
Working on the same problem. Maybe try this advice. The problem is; you cant send private not-friend-messages or mentions or scale up to blog-user-based systems with whitepaced usernames. In the end the user gonna need to enter no-whitepace-names. So interacting nicely would be better approach:

1) To accept the user to type whitespace, but not record them, using jQuery
2) Use EMAIL also to login https://wordpress.org/extend/plugins/wp-email-login/

Example for 1) :

– Leave the register process AS IT IS in bp 6.1 -as now accepts:

Donald Duck = donAld duCK = or HOWEVER a user choose their username with lowercase/ uppercase (This is good for loggin back in – many forgot their cases). The username avabililty checker don alows any other combinations either by default (DonaLD-DUCK is occupied).

– Run a jQuery on(‘keyup’) function as a validator when form appears at :

a) register
b) Loggin in
c) Changing username (if enabled by any plugin)
d)* Display name (xprofile required field) = profile edit BASE submit

OBS : The keyup replaces any whitepsace on the fly when user typing in their Username with hyphens. Diffrent browser handle this diffrent, so a onfocus need to be provided if user PASTE their name. NOTE : YES The user with no javascript has to look at the instructions instead …

The results will become : “Donald-Duck” as username, loggin in however letters cased.

If you don wanna show this white-space replacement, Use ‘onsubmit’ instead of keyup -so it can be added silent. But I think its better to LEARN the user to use Hypens – by see the “forced action”. The user will need to write correct usernames when sending/ composing messages and mentions and feeds and…if you scale up.

GOOD: “donald-duck” as the sitewide username = key (private messages, mentions and slugs for blogfarms etc etc)

Also – for user exp – Use a tooltip to make it CLEAR that we are replacing their favorite username with hyphens.

* Display name field, change in the template to ‘hidden’ in xprofile situations. Menaing: NEVER let the user be avaible to fill that out. So the trick comes to the register process. This field is hardcoded required. Let the field be hidden by CSS, added a clone of Username field in the submit. Let the username be Masterfield so avabililty check running ok. Then you get rid of Display name showing SAME for diffrent users – if they can type by themselfs.

Special if you dont wanna display/ using First and Last names:

I have hidden the Display name field in register/ everywhere, cloning username data on Submit, splitting hypens so it displays Donald Duck.

In the payment forms Firstname = Donald Last name = Duck
OTHERWISE the first name will be Donald-Duck and last name Empty.

Summary:

Don mess with php tweaks so urls get crazy, you loose quality of your collected database if ya cant scale up or migrate in the future. I tried everything and belive me, a small site will starting have problems very soon. Don core files, its security reasons why no filtering is easy to do here – I suppose, after trying everything with authenticate filters and hooks.

I woluld like a plugin to Change ALL custom messages provided in the sign up processes in WP. Including The boring email without username provided. The Welcome Pack can do this with some trix. So the user-name is shown in confirm message.

/ Hope it helps.

Hm…I’m not 100%, but you might think of username as just that–the username one uses to login. Something shorter than John Smith, like jsmith, is ideal. But then the name is the display name. It can be first & last (even with a middle name or initial) and provides useful, attractive information, but isn’t something everybody wants to type out all the time (whether for logging in or for [at]mentions….

R-A-Y you are brilliant. With regards to seeing the users full name on the site, you mention the profile loop.

What exactly is that and where will it show up? Also will this be in 1.2.4 for sure?

Thanks so much for this. If it works, they’ll be a donation coming your way for sure.

I haven’t tried Cometchat, but the demo is quite impressive. Integration with groups would be killer.

Forgot to mention that you’ll need to modify Bowob if you want BP display names shown instead of usernames.

Also chat data for Bowob, Footerchat and Webbychat resides on their servers. So if that’s an issue, you might not want to use these scripts.

Andy, it sounds to me like you are storing the @ tag, you’re just storing it in the message content, which is what I don’t like.

You’re right that it is simple, which is good, but that doesn’t make it easy to use. A command line console is simple, and if you know the right commands it is efficient and easy to use. Yet, most people are confused by command lines. GUIs are far more user-friendly, but compared to a command line – a GUI is just UI bloat.

You said you plan on addressing the confusion between usernames and display names “probably though autocomplete, or accepting display names somehow.” I don’t know how you are going to do that without UI bloat.

I think the tag box idea minimizes UI bloat as much as possible, while keeping a healthy separation between content and meta data. I think that separation will be more important as BuddyPress develops and as more plugins are created.

Also, you said “It’s just a filter on the content that is posted to look for @mentions”. So, does that mean that every update message gets searched for the string “@rvenable” every time I want see my messages. Isn’t that going to get slow fast? Wouldn’t it be faster to have the message be stored in the DB with the user_id so you can just search a table of numbers instead of parsing thousands of string messages?

As much as I agree that you want to keep it simple, the last thing I want to do is a. auto-generate usernames (you have to tell them and they have to remember – let them decide) or b. parse a field into various name fields (parsing is just begging for errors – too may what-ifs)

FYI – Facebook has you do the same 4 fields you mention you are doing. Fine. But look deeper: they then auto-generate a username. why? who knows since you always login with an email address. Additionally they auto-gen a drop down list of “display names”

So what’s the diff between me and FB? I let you pick your display name up front in addition to your username. Ideal no but better than the alternative…for me.

Bottom line is: let’s keep this discussion to how to do our own work arounds. The core way of doing does not appear to be changing. Fine (we can always leave the BP-sphere) Instead, let’s make it work.

I hearby declare it off limits to refer to Andy’s decision not to include firsname/lastname ever again. We get it.

Howdy, We\\\’ve got several ways of referring to a user:

In code:

1) The user id from the wp_users table.

2) The users *login* username

Pretty stuff that gets displayed:

3) The user name that wp has for the user (Display name publicly as: in wp profile)

4) The bp user\\\’s full name

bp uses the user id in most cases to refer to a user. Most of the core template tags take a user id as a parameter. The var $bp->loggedin_user->username doesn\\\’t exist. Nor does the var $bp->displayed_user->username. They aren\\\’t currently being set to anything.

I\\\’m kinda guessing you were shooting for the login username there. The global wp var $userdata->user_login and $current_user->user_login have what you want there.

One thing you have to be aware of is that the $bp->loggedin_user is available throughout bp no matter where you are. The var $bp->displayed_user is only available when the user is in the member theme.

Instead of using the vars directly it might be best to use the template tags in bp-core.php that are like bp_get_user<somthing>() or the template tags in bp-core-templatetags.php for some other user related items: bp_loggedinuser_<somthing>() functions. If things change in bp and the vars change then the wrapper functions just mentioned should shield you from rewriting code.