This issue has always been a really tricky one. Usernames get typed quite often, e.g. in a 'quote' tag, so people need to know usernames. But if human names are shown, people won't, or at least will get confused.
So the pragmatic thing is just to tell people to enter their real names as their usernames. However if people have the same name it gets nasty.
This is only a problem on large sites though, and not a huge one - people can just qualify it a bit, like with a birth-year or a country.
Note that v8 introduced a half-way solution that I like. Architecturally nothing changed, however (via an enabled option) signup was made to ask for human names rather than usernames and help the user ensure those were also unique, via automated suffixing.
This has been pushed as Composr is increasingly used on large sites where either:
1) people want to use their unadulterated real names, without worry of conflict
2) when accounts are imported and usernames never explicitly chosen (so they may actually be horrible but required auto-generated codes, that we don't want to display in most circumstances)
3) when we really do need usernames that are more like codes (e.g. used in URLs, such as how Facebook uses them, or for email addresses) AND human display names
Commandr, chat, security/audit tools - these will continue to use usernames, as distinguishing is needed in those cases.
Most other code now uses display names.
Rather than making all get_username calls default to display names, a full review was carried out. This is safer. In a lot of cases we pass through both to language strings. For templates, we usually pass the username, but templates now make the decision whether to actually convert that to a display name.
Forum drivers of third party forums supporting display names have been extended (OTTOMH: SMF and IPB).
The display name generation is configurable, so you may bind against a single name CPF, or against multiple name CPFs (e.g. separate forename -and- surname fields).
Most form_input_username inputs are confirmed to have actions to prepopulate them. The main exceptions are admin ones (the admin is presumed competent to find usernames). Upon initial click, it will show your friends for selection.
The get_member_from_username field is programmed to accept member IDs as a parameter (although still is preferential towards usernames).
Native things that take usernames now will take member IDs.
"This issue has always been a really tricky one. Usernames get typed quite often, e.g. in a 'quote' tag, so people need to know usernames. But if human names are shown, people won't, or at least will get confused."
This isn't such a big deal, as the quote tag is usually generated by a button. The user doesn't really need to type the username. The quote tag does support member IDs now, so if they don't know about usernames and put in a member ID instead, it won't break.
The username is shown explicitly on the member profile screen (via a template) so that it can be found.
The login box shows the username rather than the display name, but that is changeable if desired. Username is shown as the primary understood context of this box is logging in and out, rather than your personal identity. It's a close call though.
So the pragmatic thing is just to tell people to enter their real names as their usernames. However if people have the same name it gets nasty.
This is only a problem on large sites though, and not a huge one - people can just qualify it a bit, like with a birth-year or a country.
1) people want to use their unadulterated real names, without worry of conflict
2) when accounts are imported and usernames never explicitly chosen (so they may actually be horrible but required auto-generated codes, that we don't want to display in most circumstances)
3) when we really do need usernames that are more like codes (e.g. used in URLs, such as how Facebook uses them, or for email addresses) AND human display names
Commandr, chat, security/audit tools - these will continue to use usernames, as distinguishing is needed in those cases.
Most other code now uses display names.
Rather than making all get_username calls default to display names, a full review was carried out. This is safer. In a lot of cases we pass through both to language strings. For templates, we usually pass the username, but templates now make the decision whether to actually convert that to a display name.
Forum drivers of third party forums supporting display names have been extended (OTTOMH: SMF and IPB).
The display name generation is configurable, so you may bind against a single name CPF, or against multiple name CPFs (e.g. separate forename -and- surname fields).
Most form_input_username inputs are confirmed to have actions to prepopulate them. The main exceptions are admin ones (the admin is presumed competent to find usernames). Upon initial click, it will show your friends for selection.
The get_member_from_username field is programmed to accept member IDs as a parameter (although still is preferential towards usernames).
Native things that take usernames now will take member IDs.
"This issue has always been a really tricky one. Usernames get typed quite often, e.g. in a 'quote' tag, so people need to know usernames. But if human names are shown, people won't, or at least will get confused."
This isn't such a big deal, as the quote tag is usually generated by a button. The user doesn't really need to type the username. The quote tag does support member IDs now, so if they don't know about usernames and put in a member ID instead, it won't break.
The username is shown explicitly on the member profile screen (via a template) so that it can be found.
The login box shows the username rather than the display name, but that is changeable if desired. Username is shown as the primary understood context of this box is logging in and out, rather than your personal identity. It's a close call though.
Some related API cleanups happened in this commit also.