Add a Display Name field to core in addition to Username

Subscribing.

I think the idea definitely has merit.

Yes, this is a great idea and a must-have!

Login/User name and Real/Display name should be separate. They are not the same. It's not only a security issue but also one of readability.

Also, in the real world there are many people with names "John Smith". But in the Drupal world only one "John Smith" can exist. This is very frustrating when your Real name has already been taken - which is a silly situation.

Actually, I would go further to say that the Display name should be admin definable. And that you should be able to define it as a simple function like: $display_name = $first_name + $last_name.

Cheers Daniel

Posting this just for posterity's sake, as I'm sure most of you know this. But, you could always define First name and Last name profile fields and then simply overwrite theme_username() to show those fields instead of the username. That would cover you in 99% of use-cases. But, I suppose this would be nice to have in core by default.

I don't think it would cover 99%. Everyone assumes I am using profile.module when I mention Display Name... I am not. I want my Display Name to come from ldap_integration, and I am sure I am not alone. Almost every LDAP server I subscribe to (for my address books) provides the person's real name. My application for this feature would be a company intranet. We use LDAP for login synchronization across many apps, and I want real names, not short usernames (who the hell is "bsmith"?). I *COULD* do this myself, by modifying each theme that I use, but that seems silly. The concept of a display name should be built into drupal. However it works, it should be supplyable from any module, and then readable from any other module (or theme). Saying that each possible end of this transaction needs to implement support for every possible other end seems ridiculous to me.

Implemented here through the theme layer:

http://brick.policyunplugged.net/the_cast

Agree that it would be much better to have an option in core to concatenate fields into a display name.

Subscribing to issue.

@sparr - You could just as easily pull the names from LDAP in theme_username(), I just mentioned profile.module as most people would be using that. The 99% coverage means that usernames are passed through theme('username',...) in 99% of the site. (Margin of error 48%.)

*subscribe*

I'm setting up Drupal for a university department and we definitely need this. Moreover, creating additional profile fields via LDAP (such as email, etc.) would be helpful but probably not within the scope of this request.

Features will never be added to already released versions. You might look into using profile.module and a custom theme for the profile page.

to clarify, we arent neccessarily talking about the profile (or user) page. we are talking about everywhere else the username shows up, such as when listing story or comment authors. this would require replacing theme_username (i think, theme_user maybe? the name escapes me at the moment) in every theme we want to use.

Also, a point that was brought to my attention recently is that Drupal used to have this feature after Dries indicated on the mailing list that he wanted it. It disappeared at some point between then and now and I can't find any explanation why other than that it happened around the time that support for the extended user info modules was added (but before the profile module was actually written)

Drupal's achilles. Every time - create profile, try to figure out how to hack theme so that the real name displays instead of the system id - which I was doing when I found this post. Real name in user record is a no-brainer - must have priority one in core.

Should a module be created to do this in the short term? Seems crazy but perhaps that's the way to get this done and for us not having to to go hacking any code...

Cheers Daniel

This is really something that I'd consider necessary as early as possible. I've been using Joomla! in the past, but for various reasons I've decided that Drupal would be a better system. But for our newspaper's site, it'll be a dealbreaker if we can't get the following two things:

• Display names for users
• The ability for users with specific privileges to change the name displayed on a content item ('Author Alias' in Joomla!) such that we don't have to create a user account every time someone writes for us (that's several hundred people each term).

A module would be a good idea if it's doable.

Yes, please, a 4.7 module would be a great relief! I can't wait until 6.0!

I'm building a site where the users are couples (actually families), and many have names like "John Smith and Jane Doe", only much longer! I had to override theme_username() to display >15 characters in order to win Jane over, but John thinks that typing such a long user name is a pain — I can't blame him...

Did anyone try my suggestion in #4? This should be possible in 4.6+ by creating two profile fields first name and last name with profile.module, and overwriting theme_username() in template.php.

Subscribing to this.

Definitely a +1.

I have several sites that would like Firstname Lastname for the username, which I think the Display Name option would satisfy. A vote in favor. Subscribing.

Definitely +1 to this...

I've changed the title of the feature request. It used to be "Display Name, different from username, would be very nice to have."

It seems that the consensus here is to add a first name field and a last name field to core, and then allow themers to concatenate those two into a display name variable. Although, now that I've written that, it would seem far easier to just combine them inside the user table automatically. Perhaps core should offer themers a displayName variable upon request, but not allow a site user to change their own displayName?

A site's users don't need the ability to edit their username, firstName, lastName, and displayName too. Sticking with simplicity, I propose that we offer the standard username, add a first and last name field to a user's default profile, and stealthily store a concatenated displayName in the user table for future endeavors. Themers will love it, and this might even make its way into the default Garland theme on d.o? I for one would LOVE to browse the forums without having to decypher who "afenr" is.

I add my ++ to this thread, upping the total number of "yesses" to 11.

Somewhat reverting meaning of title, keeping better wording. I don't feel the consensus here is for firstname/lastname. Looking over my previously linked nodes, and the comments here, we have the following preferences (or implemented patches):

Real Name (including Firstname/Lastname): 12 'votes'
Arbitrary Display Name: 9 'votes'
No stated preference: 5 'votes'

A plurality is not a majority, and even a majority would not be consensus. And when considering these numbers you have to keep in mind that implementing arbitrary (or codifiable) display names is a superset of real name and firstname+lastname. I counted one 'vote' for real name for the guy who linked to his own site, but we don't know if he implemented it that way or if he made it arbitrary and people just used their real names out of convention.

Just to be a pain, might I recomplicate matters by suggesting that the ability for admins or people with an appropriate role to use an author alias so that people without user accounts can be credited for submissions? It's a box on the content page - if there is a name in the box then it should be used. If there's not, then the username is used. That would be really, very useful.

Just thought I'd mention that on a newly-launched site with imap authentication, we have had several individuals ask for the ability to display an alias or First/Last name instead of their email address on the site. So this functionality definately has end users interested!

I'll see if I can hack up a method to do this for 4.7 and 5, but the odds of me actually finding the time are slim :(

Has there been any movement on this issue?

Use profile. Or even if a contrib wants to do , change users table, Drupal core does support, see user_fields.

To further elaborate on this topic: Adding a display name field adds a specific singular content field to the user profile. But there is already a method to add arbitrary content fields to the user object: profile.module. Adding a display name would therefore “soften” this architecture.

"Use profile" is not a solution. If this isnt in core, or at least supported in core in a way that other modules can and will use consistently, then every time I change (or upgrade) themes I have to re-implement the new method of display in the new theme's theme_username(), or in the theme's node.tpl.php (or other theme engine equivalent). Not only then, but I ALSO have to edit code if and when I decide to switch from profile to *_integration (or to any other module or method) as the source of my display name.

The only remotely consistent way to handle it, as things sit now, would be to edit every new theme that I try out so that it fetches the display name from Profile, and then expect (or modify) every display-name-providing module to populate the appropriate profile field. ldap_integration supports that, from a single field, but not concatenating first+last name. I don't know if the other 'single sign on' soltuions support it at all.

And of course all this is assuming that every module plays nice and fetches the username through theme_username, which of course is untrue. So that's dozens of other places I have to edit every time I make a change in where my display name is coming from, or how it is to be formatted.

It would be helpful if anyone could shed light on why this feature was removed from Drupal. It seems to have happened around the time that support for profile.module was introduced (but well before the actual introduction of profile.module), but I can't find any mention of WHY it was removed then.

I have been told that "because every other major CMS has it" isnt a valid reason to get this into core. I agree that we shouldn't copy every feature from each of our competitors, but in cases where every single competing product 'agrees' that a feature is worth having then I disagree. Unfortunately I know that I can't win that argument, so I am sticking to the merits of the feature instead.

Thank you for your well-thought-out post, sparr! I hope this will be reconsidered...

sparr: For this to get through, you have to approach the problem at another point. Dries will probably never commit a patch that adds in a separate distinct field for user names.

Don’t understand me wrong: I don’t think that generally having a display name is a bad idea, not at all. Nor does chx or other people who have opposed against your approach. They only say that this the wrong way to attack the problem. That’s at least how I perceive it.

Here’s a “roadmap” to get something similar to display names into core:

• Rehaul profile.module, probably using (parts of) CCK
• Implement a kind of “vCard” (http://tools.ietf.org/html/rfc2426) set for describing users
• Add a NAME field for a default Drupal installation (see 2.1.2 NAME Type of the RFC)
• Make theme_username adhere the new (vCard) meta data layer

I have to point out that technically I am not asking for a patch to be committed, I am asking for the patch that removed this feature to be rolled back. I know that doesnt make a difference in this discussion, but its a valid point. Your vCard idea is, as far as it goes, a sound way to basically accomplish what has been asked for. But it completely ignores that many bits of code dont want themed names, and dont use theme_username to get them. If support for a display name existed then various parts of core would have to have "if(profile) ..." conditionals, and I feel that that sort of thing is generally a bad idea. It indicates a failing of the module system, where I would expect any such behavior to be provided (or providABLE) by the module itself. Also, this functionality doesnt seem appropriate at the theming level imho. If users want different names displayed everywhere, it should not be up to the theme whether to display them or not.

Also, a point that was made but mostly ignored is that of security. Exposing usernames is generally considered an undesirable activity. I can only imagine that when display names were removed from Drupal it was assumed by someone that the profile module would reach the point we are only now discussing relatively quickly.

But it completely ignores that many bits of code dont want themed names, and dont use theme_username to get them.

So, if we already have a way to theme the username and so few modules use that function, how do you expect this to change if there’s yet another field for the display name?

If support for a display name existed then various parts of core would have to have “if(profile) …” conditionals

This can be merged into theme_username(), maybe by adding a parameter to it.

Also, this functionality doesnt seem appropriate at the theming level imho.

I think it’s valid to compare user names with dates: The raw data is a plain timestamp and the theme decides how to present this data. I think that the decision of whether to display “sparr” or “Clarence Risher” is not a purely logical one, but merely a choice of the theme. So in my opinion, displaying a user name consists of two parts:

• The knowledge about the abstract user entity (i.e. the user object in Drupal)
• The type the user should be referenced with (91299, sparr, Clarence Risher, Clarence R., C. Risher, clarencerisher, …)

The second question is not something that should be decided at the module/data level but at the - you guess it - theme level. (And yes, I consider the selection of the date format on the “Date and time” settings page as themeing. And I also think that format_date calls should be moved to theme functions since they are part of the theming (“themeing a timestamp”)).

"Also, a point that was made but mostly ignored is that of security. Exposing usernames is generally considered an undesirable activity."

I completely agree. It's an issue of security. But I think we are all agreed here - the option to publish display names instead of user names is a good thing.

What seems to be the issue is how to implement this. I am not a Drupal coder and do not know where to start or know how to rate the options being discussed. But I do know I want it to be easy - a tick box "publish display names instead of user names" - no messing about with code.

All I can do is offer the incentive of financial resources to anyone that can get this into core. I'm not long in Drupal culture so forgive me if that is a crass offer.

I look forward to it!

Cheers Daniel

I've activated this issue again for Drupal 7 as I believe that it is essential to be able to hide the username (and to make it this the default option or at least an available option) for security reasons.

Please give good reasons why this should not be done. We've got to be protecting Drupal users.

Cheers Daniel

Beliefs are irrelevant. Logic isn't. Provide facts to prove that username display is a security issue (and contrast this to the many bulletin board systems and wiki-software's that continue to do so anyways), and provide clearly defined rationale why ignoring profile.module is a good idea. Otherwise, you're just wasting a slot in the issue queue (ie., we're not going to believe you on faith alone; you have to convince people why this is a good idea; if you're not prepared for that uphill battle, then you should close the ticket again.)

To reiterate: We can't add yet another way to add information to user objects besides profile.module. Either rehaul profile module to include some kind of semantics (see the vCard RFC I pointed at in a previous comment) or leave it.

OK. I hear you. Give me until April 11th to reply in full. But I hope to have a response before that. There is much background work I have to do to satisfy your detailed requirements. Cheers!

Let me add my vote for this feature. We now use Drupal extensively for our community sites. Since usernames are controlled through another enterprise identity system, we desire the ability for users to specify how they appear on stories, forums, comments etc rather than be limited to their usernames alone.

I'm sensitive to potential security problems with displaying usernames but have no evidence to support it should not be used. However, I personally like sites that offer the ability to control how my name is presented rather than be dictated to me

Richard - Novell, Inc.

Richard - your use case is adequately solved with profile.module and theme manipulation.

I am also strongly in favor of a separate display name field.

- That would allow us to make the username field case-insensitive (read, force them to lowercase in the database), which helps with some performance issues.

- No, theme_username is an inadequate solution because the username is used in all sorts of places that do not get passed through theme_username. The title of the user's account page comes to mind. RSS feeds, too. And the author auto-complete textfield on node edit pages. There's probably more cases where a username is used without theme_username.

- theme_username involves an extra database hit to load the profile data. In long listings, say a view of nodes where you're showing an author, that can be expensive.

- I want to be able to *search* for users by their real name, not their login name, without custom-coding something per-site for what the display name profile field is called. Forcing them to use their real name for their login name is not a solution. I have had multiple clients ask me for that.

- This is not a 3rd way to store data. A display name is, I argue, as intrinsic a part of the "core user thingie" as the login name and password. It has, or should have, very specific system use. There's no 3rd here; it's just another first-level user field (if we say profile.module is the second level).

- All that privacy stuff. :-)

- If we want to expand it into a vcard or something later, that's fine, whatever. But there are far too many places in core where I want to use !$username as the display name of a user to be able to do it without direct core support.

Yes this is a deficiency of Drupal right now. Yes it should be fixed. +1 to a display name field in core.

Thanks for weighing in Larry. Nobody in this thread denies that there is a need for a username field. The discussion is merely about how to achieve this.

My favorite solution would be:

• Adopt a “Field-Semantics standard/framework” that is tied both into core and used by CCK to give meaning to an otherwise arbitrarily named field. I pointed out that the vCard RFC could be used to do that since it already specifies all kinds of person-specific information. Another way I could imagine (and now that I think about it) and is probably better is make it compatible to some sort of OpenID attribute exchange standard.
• Modify profile.module to build on these fields (and possibly tie into CCK or the part of CCK that gets into core).

I don’t think that simply adding a “Real name” field to the user table would solve this problem in the long term. After we have this field, other users come and say “Real name is nice, but we also want to store the location of a user. How about adding a location field?” and we’ll end up hardcoding fields into the user object which could have nicely been done using CCK or profile.module or a combination of both.

Even with CCK nodes, "title" is a field with special meaning. It's a "property" rather than a "field", as the DADS report would differentiate it. And the answer for location is simple: "display name" is core-critical and has use throughout the system, and can't really be done separately. Location, and pretty much any other field, can. Core should only have what has to be in core, and "display name" really does have to be in core in order to function properly.

And I really don't want to have to hack around this design flaw for yet another version because we couldn't agree on a vCard implementation, which is non-trivial.

To expand on what Crell said:

Core should only have what has to be in core, and "display name" really does have to be in core in order to function properly.

By this same rationale, if a proper 'display name' becomes part of core, then 'username' is redundant and confusing. All a user should need to log in is their email address and password. This is a proven convention that users are already familiar with: Google, Yahoo, Amazon, Apple (iTunes & .Mac), Aim, MSN, to name a few, all use email addresses instead of 'username'.

This issue is a constant stumbling block for my staff and clients who can't ever seem to remember the exact format of their 'username'. They can't remember it because of the fact that it doubles as a display name and therefore usually contains spaces and mixed case, which makes it no longer look like a username.

Micro-analytics installed on my and my client's drupal sites show the following scenario over and over again:

Client, John Smith registers his account with username jsmith, because he's used that before somewhere else. Then he sees that 'jsmith' displaying all over the place and he wants to look professional so he changes it to John Smith, which seems to work. But next time he logs in he can't remember what is user name is (a problem compounded by his helpful browser, which autofills jsmith since he used that last time).

So he tries jsmith, but that doesn't work. So he tries it again with the same result. Then he tries johnsmith, john_smith, and even his email address, but never 'John Smith' because that doesn't feel like an acceptable user name because of the space. Hell, the username field description even says "Your preferred username; punctuation is not allowed except for periods, hyphens, and underscores." He ends up pissed off, and leaves a message on my voicemail that he is locked out of his website.

As Crell said, this is a is a core design flaw, and a nagging one at that. All of the recommended workarounds are tedious, inconsistent, and unintuitive. We need to address this once and for all in the core.

Indeed, I'm seeing the same thing: people trying to log in with their email address over and over again, and having a very hard time to come up with their "user name," almost as if they were deliberately avoiding it.

I can't help but be amused that there is so much static against having a display name in core, yet there is core support for seemingly trivialities as user picture and signature. If anything belongs in core it would seem to be a display name; and if anything belonged in profile.module it would seem to be picture and signature.

I'd go one step further and argue for the inclusion of age and location. At one time there was U.S. legislation under discussion to make the age element mandatory on 'social sites', and there are still laws mandating the stripping of or full disclosure of the storage of certain particulars in profiles (such as full name and location) for those under a certain age (13 in many but not all cases).

By not providing a display name (and age) in core, Drupal is essentially side-stepping the issue and putting the burden on modules or custom code to comply with legal restrictions. Profile.module does not currently appear to have the infrastructure to handle these legal requirements, so site builders are forced to provide custom code to build a community website that is in compliance with federal and international regulations. Regardless of the outcome of this issue, unless all of these fields are managed in core by an 'age-aware' function, the age-awareness should be presented as an issue for profile.module, cck, and any other modules which can provide custom profile fields. - Which is why it all belongs in core.

@Zach: The points you raise are absolutely valid. I opened an other issue for this particular problem. I don’t think however, that this is fully related to the issue of being able to use a “display name” instead of the user name.

@macgirvin: Nobody is against a display name, not even in core. And I also think that your point about the user picture is valid and should be taken into account when redesigning the user.module/profile.module landscape.

@Crell: See? Now it’s not only a display name, but also age and location. Next up will be “gender”, “favorite books” and “most commonly used mean of transport for vacation trips”.

@kkaefer: I believe display name is an identifier of the user. Look at it this way, as an American, I am uniquely identified by my social security number. However, I wouldn't expect my friends to address me that way, instead they address me by my name. My name is still an identifier for me, but it is more usable than my social security number. On the other hand, things like age, location, etc. are merely descriptors of my life, they do not identify me.

@jscheel: A display name is by definition not an identifier. It is what should be displayed, not something that uniquely identifies you. As an example, there are probably hundreds of people called “David Smith” (I already know two and I’m not in an English speaking country). They might want to use “David Smith” as display name, but for obvious reasons, they can’t all use that name as username. Besides that, I can’t see the point you want to make with that post.

(And age and location do identify you. At least those two characteristics are used to uniquely identify people in Germany.)

Age, location, user picture (now with the new templating system in D6), and favorite stuffed animal *can* all be implemented by a contrib. They don't integrate into the wider site. "Display name" needs to integrate into the system too tightly to be done in contrib properly. Therefore, it must be in ocr.e That's the routine answer to "core or contrib?", and it is a good one.

Is anyone else able to make a patch for this, or am I going to have find time to? :-)

@Crell - That was my precise argument for including displayname, age, and location. But it was a bit of a hijack, so if it helps the argument for display name, I'm all for it. I'll have to get more ammunition for core support of little things like making the code comply with international laws (which includes controlling when you can legally store/display a display name).

Theme Manipulation vs It Just Works:

Morbus Iff suggests manipulating the theme to implement the display name. This goes against Dries' idea of making things easy. Also, webmasters will have to hack each theme they want to use. That's a lot of laborious work. As far as I can tell Morbus Iff is the only person suggesting not moving forward with display names in core. Not to single him out but just to say we are pretty much all in agreement here.

Core Module vs Contributed Module:

Morbus Iff also suggests using the core profile.module. But not all webmasters are happy with the profile.module. In fact there seems to be loads of alternatives springing up. For just one see Nodeprofile vs Profile.

Refactoring the whole user profile is not what we are doing here. We should be really careful not to hardcode any solution that ties the display name into a particular module but will allow any one of these profile would-bes to hook in the display name - hence the idea of a webmaster option to use a pointer to a data field to find the display name for a given user. Note I'm not a Drupal coder so there may be a far more elegant way of doing this in a Drupal way.

Authentication vs Attribution

A username is for logging in to a system. It's unique. It's one half of a security question. The other half being the password. When we display a username we have lost a portion of our security to a potential "hacker". We should enable users to keep the usernames private. This will in turn mean that more "serious" websites, that demand higher security for their users, can use Drupal.

Hhow we identify an author can be any number of ways. Names of authors are not necessarily unique - look at the real world. It's up to the webmaster to decide how they want the website to identify the author. It may even be that a webmaster would choose a username but it's their shout.

We should encourage webmasters to identify authors in some way other than an author's username (or email address for that matter).

Best Practices vs The Way It's Been Done For Years:

Just because it has been done in the past doesn't mean we should stick with it. In fact that's sometimes a good reason not to. What we should be doing is making sense and innovating and doing the best thing. So, even though Facebook has the concept of a real/display name and others do not it's not so relevant because Drupal is a framework that should enable webmasters to create websites in the way they wish. And, by the way, Joomla has an 'Author Alias'.

The default set up for new Drupal installation should present what the Drupal community sees as the best practice for how to build your website. This should includes hints at proper passwords (as it does already) and also best authentication models. We should be encouraging more secure websites to be created.

Short Term vs Long Term:

kkaefer suggests doing large overhaul of various modules but I would caution against it considering timescales for D7. So, let's keep it as simple as we can. Also, let's just do one thing: put display names in core. And, if we are clever, it will be really useful for many other module (core and contributed) developers. And hopefully allow for the type of work that kkaefer wants to see done.

Keeping It Loose:

Zach Harkey suggests that webmasters want to choose the email address to be the login username. Not all webmasters want this for sure. I don't. However, it should be an option.

Function vs Content

We should aim to decouple function from content. Email addresses are for messaging. Usernames are for authenticating access to an account. Display names are for attribution and public identity.

If a webmaster wants a username = display name = email address then let them do it and let it be on their head. It's not for us to decide for them. But it is for us to subtly hint that this may not be the best course of action - see the password strength hint for what I mean.

And it is definitely not for us to say that username = display name. Hence this passionate discussion.

There Is A Need:

We want to make Drupal flexible and easy to use for all webmasters. Dries was adamant at his State of Drupal presentation in Boston 2008 that we need to "Make Drupal really easy to use". There is obviously a desire for a display name option from Drupal webmasters - you just need to see the evidence on this page or by searching around for suggestions on how to hack it to life.

Functionality that is commonly required should made easier to implement if we want to see the Drupal community grow. Custom coding is "out" for commonly required functionality. The more convenient we make commonly used functions the more popular Drupal will become. So, the question is now not "if" we have a display name in core in D7 but "how".

Implementation:

The display name should be a setting located in the user.module and accessed via:
"Home > Administer > User management > User settings"

Rather than the "display name setting" being just enabling a text field in the "Home > My account" area for each user, it should be a list of options:

Please make the display name be:

1. (Proposed default) A free text box in "Home > My account" for each user. This is not unique for each user - a real name is not unique.
2. (Current default) A "same as" pointer to the username for each user. This is unique for each user.
3. A "same as" pointer to a field created by another module (such as core profile.module or nodeprofile.module). This option allows for the type of development that kkaefer wants to see but without relying on it.

Along with this we could also enable an option list for the username:

1. (Current and proposed default) A free text box in "Home > My account" for each user. This is unique for each user.
2. A "same as" pointer to the valid email address for each user. This is unique for each user. This would satisfy Zach Harkey desire for username = email address.

One possible way of doing this off the top of my head... When you create "Author Name" using core profile.module or "Ident Disp" using nodeprofile.module (these are meant to be arbitrary / user defined labels by the way) there should be be a way to identify these as being offered up as candidates for the display name options menu in the user.module. Or perhaps there is a way to enable webmasters to "browse" datatypes for those fields?

Getting Display Names In D7 Core:

How do we do this? I am not a Drupal coder but I can help in other ways. Let me know. Let's do this...

Cheers Daniel

Thank you for the summary, dahacouk, I agree with most everything you wrote.

There is a contrib module that already implements a large part of what we're discussing here: Alternate Login. Rather than adding a display name, it adds a second username and thus pushes the original username towards the display name function.

Alternate Login still allows logging in with the original username. If we had an option to turn this off (and an option to enable logging in by email address), we'd have all the ingredients for extending core.

Some of the sites I run have a large percentage of complete newbies and they also meet in the physical world. I insist that they use their real names as usernames, but they often sign up with a fantasy name. Alternate Login allows me to swap the fantasy name to the alternate username and add the real name as the primary username (= display name).

"Morbus Iff is the only person suggesting not moving forward with display names in core". I don't much care if people single me out, but if you do so, make sure your rationale is solid. In this case, it's not: I suggested using profile.module (as many others in this thread did), and that getting display names in core will be a battle. Likewise, chx in #25 "won't fixed" the issue, and if that's not an admonition of "not moving forward", I don't know what is. In #26, kkaefer suggests that singling out display name in core softens the profile.module. He, certainly, then agrees that this would be a good thing for core (#29) and offers alternative ways for approaching the problem, of which no one has yet attempted.

Which is to say: people can agree that Display Name is a good idea, but can healthily disagree how it should be part of core. And note that "profile.module" is, in fact, considered part of core. There's a distinction between "hard-coded in core" and "implementable in core".

One of the more idiotic arguments I've seen is that the reveal of a username is some sort of security issue. It's not, as evidenced by the many applications and software that gladly reveal it, such as a) nearly every web-based email provider (Hotmail, Yahoo, Gmail, etc.) which use your email address as the login name, b) other well known applications [to repaste from #42: "Google, Yahoo, Amazon, Apple (iTunes & .Mac), Aim, MSN] and any other instant messenging software (including Skype) c) utilities and applications built into Linux (finger, EXTR commands in mail servers, the default inclination to use USERNAME@PROVIDER.COM, Apache's mod_userdir), and d) many other hosts (such as Flickr and Digg) which place usernames in the URL. Trying to push this into core as a security issue is folly, so I'd suggest simply dropping the argument. I don't mind if you believe it though... ;)

The other straw man is the "if we put it in core, contributed modules will magically know about it". That's just not gonna be the case, and one of the proponents of "display names in core" proves it in #27: "And of course all this is assuming that every module plays nice and fetches the username through theme_username, which of course is untrue." If contributed modules aren't using theme_username() properly (which, note, they should be), then they're not going to use theme_display_name() (or whatever it'll be) either. Adding display names into core is not going to make your life rosy: it's going to allow people to INPUT their display name, but it's not going to make the OUTPUT any easier - you'll still have to run around and edit "dozens of other places". If contrib isn't using theme_username() NOW properly, then it's a safe bet they're not going to use theme_display_name() properly either (much less when they now have a CHOICE to use theme_username() and theme_display_name()).

Likewise, note that Display Names, because they are changeable (unlike usernames, the ability of which to change is disabled by default), can create problems with URLs. Many sites want clean[er] URLs - using node/this-is-the-title or user/morbus-iff instead of node/1234 and user/4321. Pathauto facilitates setting up both of those masks as a default install. Staying true to the rationale of hiding usernames, you'd have to use Display Names for the URLs which, because they're changeable, can cause healthy bits of URL pollution (if one person changes his display name one hundred times, he has earned 100 URLs).

To be more specific about specific arguments in your comment: "This goes against Dries' idea of making things easy." That argument leads down the path of "but, but, I want to ask for my user's favorite color and doing it via profile.module is HharRrrdddD." The solution isn't to hardcode color into core, but to make profile.module easier to use.

"So, even though Facebook has the concept of a real/display name and others do not it's not so relevant because Drupal is a framework that should enable webmasters to create websites in the way they wish. And, by the way, Joomla has an 'Author Alias'." Mixed signals. On one hand, you're saying "Drupal shouldn't listen to anyone else [because that allows me to healthily ignore all the apps that expose usernames]", and then you're assuming that we'll put more weight into your argument "because Joomla does it". As for "The default set up for new Drupal installation should present what the Drupal community sees as the best practice for how to build your website.", I would argue that that's what install profiles are for, NOT what the default core distribution of Drupal is. Would you be OK if there was a Drupal distribution available that came /pre-enabled/ with a Display Name field, whilst the vanilla Drupal core remained as it is?

"Zach Harkey suggests that webmasters want to choose the email address to be the login username." Already possible with Login Toboggan.

"Functionality that is commonly required should made easier to implement if we want to see the Drupal community grow. Custom coding is "out" for commonly required functionality." As you yourself suggested in #13, a custom module COULD be built to do this, and it's made all the more easier in Drupal 6 with the theme altering component. A "display_name.module" could implement a Display Name field, could alter/takeover theme_username() so that all modules that do currently use the right theme function (which would be all of core, and some of contrib; see earlier argument) would be value-added with the Display Name. And it could provide a standard API to retrieve or receive it from other sources (LDAP, etc.). Installing a module is easier than configuring profile.module and then modifying the theme. A Drupal install profile could come with the module pre-enabled. It accomplishes what you want, and satisfies the flexibility and choice you keep touting.

http://drupal.org/node/188734 was duplicate (and has a patch).

I'm not sure about this either way to be honest.

Allow e-mail address login: +1
Fix profile module: +1000
Add another column to the user table: meh. Worth doing if we can kill some of the LOWER() queries and the denormalisation argument is valid. I'd support it on that basis. The profile/property/field arguments are inconclusive each way IMO.

@Morbus: Please quote my entire paragraph when objecting to it:

- No, theme_username is an inadequate solution because the username is used in all sorts of places that do not get passed through theme_username. The title of the user's account page comes to mind. RSS feeds, too. And the author auto-complete textfield on node edit pages. There's probably more cases where a username is used without theme_username.

And also:

- theme_username involves an extra database hit to load the profile data. In long listings, say a view of nodes where you're showing an author, that can be expensive.

Yes, if a contrib is printing $user->name directly, that's a bug in the module. That's also one more strawman for this thread. The title of a user account page is generated straight from user.module in core. RSS feeds are generated mostly from core, and I don't think are even themeable (although I may be incorrect about that). The callback for the author field auto-complete for node edit pages is in core, as is the save routine for that form (and dear god in heaven I don't want to replace that submit function via contrib, as that whole workflow is a nightmare). The user-search page (user.module and search.module in core) have no facility to search on anything but the login name.

This is not a fictional case. I have three sites I'm working on right now where this is a PITA for precisely these reasons, and all of the above have bitten me.

The task at hand is "use a human-friendly string for *all* user-display, that is not the login id, without hacking core".

There are three possible conclusions about how that can be done:

1) Core must be modified to support it directly.
2) It can be done from contrib but in a sucky and hacky way that is error-prone and ugly. ("Use profile module and theme_username" falls into this category.)
3) It can be done from contrib in a clean fashion.

#2 is a stupid answer, IMO. It should be done cleanly, one way or another. So the question is, can the above-stated task be done from contrib in a clean, portable, fashion. I submit that the answer is no, and have provided evidence to support that claim. (Contrib cannot modify certain core behavior in a non-crappy way.) Thus, conclusion #1 is the only alternative.

For Morbus or anyone else that objects to core handling of display names: Please provide evidence to support alternative #3, preferably in the form of a module (D6 only is fine) that demonstrates successful completion of this task. In the absence of such a counter-example, the conclusion that alternative #1 is correct stands.

I am perfectly happy if someone is able to provide such a counter-example, and will won't-fix this issue myself if such a module can be demonstrated. Until then, I operate on the assumption that we need core support.

Crell - I didn't quote you at all. What are you talking about?

For what it's worth, I think a good first step to hardcoded display names in core (which, again, I'm not against) would be to fix the various areas Crell pointed out - things that should be going through a 'username' filter, but aren't. One could imagine theme_username() expanding to include a param such as $link = TRUE|FALSE. Also, Crell: what part of theme_username() actually hits the database? I'm not seeing it. In your example, a long listing of nodes, one would either have the complete node (which would contain both uid and name), or a set of database results that would have loaded in, at the least, u.name. theme_username() itself, though, doesn't seem to pull in any database information at all (much less profile.module stuff).

theme_username() does not, now, have any queries in it. However, if you are going to use data from profile then you need to call profile_load_profile(), which has a query inside it, from within an override function. Now list 50 users on one page.

@salvis - Alternate Login has many issues that make it a non-starter but the most obvious one here is that the alternate username has to be unique. And real names are just not unique. Also, as Crell suggests this really does need to be in core so that module developers can rely on it always being there. Thanks for the suggestion though - it's helping me clarify what we do actually need.

@Morbus Iff - Security: I wouldn't say that the impressive list of applications/sites you mention are doing it the wrong way, just that their requirement for high security is low. Those that argue that the current lack of display_names is a security are not saying that there is no security in exposing half of the login, just that this lowers the security level. So, when Drupal presents this as the de-facto setup we turn many people away who want a higher level of security for their site.

For example, I wouldn't want people knowing the username component of my bank login but I'm OK with people knowing the username for my Yahoo account. See the difference? How about you? We want to attract developers that want more secure websites - let's make it easy for them.

BTW in Flickr, your chosen URL_name is independent from the screen_name - the former can't be changed once set but the latter can be changed at any time. The former can also be set to whatever the user wishes - so long as it's unique - and it doesn't have to represent their login username.

The point is there are many ways of running a website and we should not be proscribing any way in particular but should be presenting a menu of options that can cater for many different scenarios and diverse requirements.

@Morbus Iff - Output: Good point about the output. No, there is no way we can force module developers to use display_name but if it is there then we on to a first step. One of the reasons that module developers may not be sticking to the current theme_username() is that it is too restrictive/limiting for their current needs - I'm just speculating here because none of us have actual figures. All I do know is that it's better to have set concepts that developers can hang their code off of - otherwise we are all lost.

If we had the core concept of a display_name as distinct from a username then theme developers could use display_name in their themes and webmasters wouldn't need to hack themes in order to get display_names to work. Also, if a webmaster wanted to have usernames displayed then they'd just set display_name = username somewhere. And we'd be catering for both scenarios without the need for laborious hacking in either case.

@Morbus Iff - URL name: A lot of this comes down to webmaster policy - it's up to them. But you raise a good point which leads me to suggest a further addition to the variables that need to go into core: url_name. Read above the way Flickr handles this. What you are talking about here is a nickname or url_name. A nickname is quite distinct from a username and a display_name. LinkedIn calls it my 'custom URL'. Plaxo call it 'my nickname'. Couch Surfing call it my 'Direct Profile URL'. Some allow you to modify afterward first set. Some, as Flickr, do not allow you to change once set. This is a webmaster choice and we should just provide the tools to enable them to do it. See Crell's #54.

So, we now need to cater for:
- username - used for login purposes.
- display_name - used for attribution and authorship.
- nickname - aka screenname used for URLs.

On this discussion: When we have long forum threads like this it's easy to loose the thread. What is the best way to associate a Drupal wiki page with this thread? It would enable us to build a summary document of current thinking.

Cheers Daniel

@dahacouk: I'm not sure I want display names to be non-unique, even if real names can coincide, of course. It's first-come first-served. Duplicate display names could cause quite a bit of confusion, and I'd want to have the option to prohibit this.

I have no interest in pushing Alternate Login, but it neatly solves the (unsolvable) problem of how to get everyone to support a newly created display_name by promoting the current username to display_name (absolutely no changes needed!) and introducing a new login_name instead (which is hardly ever displayed in the UI).

Whether any of the Alternate Login code could be used or not, this concept might be worth some thought.

@salvis: To clarify... I fully support you, as a webmaster of your site, in your decision to only have unique display_names. However, I do not support you, as a developer of Drupal, to only allow unique display_names. There's a big difference.

Again, this is a webmaster option: to have a unique or non-unique display_name. So, we should have a switch that would option unique or non-unique - set by the webmaster in the administration area.

Also, could you elaborate on "hardly ever displayed in the UI" and explain where it may pop-up?

Cheers Daniel

@dahacouk: Oh, yes, I certainly didn't mean my way should be the one and only, but I feared it was going completely the other way.

Also, could you elaborate on "hardly ever displayed in the UI" and explain where it may pop-up?

On My Account and on administrative pages. As admin I would want to know my users by a unique name, and preferably one that they can't change.

http://lists.drupal.org/archives/development/2001-07/msg00011.html

http://lists.drupal.org/archives/development/2001-08/msg00131.html
http://lists.drupal.org/archives/development/2001-08/msg00134.html
http://lists.drupal.org/archives/development/2001-08/msg00151.html

http://lists.drupal.org/archives/development/2001-06/msg00187.html (long thread)

http://lists.drupal.org/archives/development/2001-08/msg00060.html

I am unable to locate the cvs commits when this feature was removed. My google-fu is weaker than it was when I initially researched this, because I know that I found it then.

From that last message:

I still think that, if you want to post with your real name, you should
create an account with the username set to your real name. Simple as
that.

I'm still not sure exactly why this is a problem - especially if we allowed e-mail address login, and once apostrophes are allowed in usernames.

Because "the name I want to use to login with" and "the name I want people to know me by" are not necessarily the same thing? And because it's impossible to enforce them being so, but a display name field has a natural "intuitive" meaning for "what I want shown" vs. "what I want to login with".

But how does e-mail address + password login not deal with the "name I want to use to login with" issue? (assuming that was supported)

edit: or OpenID login for that matter...

You're assuming I want to be forced to use my email address or start an OpenID account.

I'm assuming there are existing alternatives to logging in with your username (which for argument's sake is used on a site as the display name), using uniquely identifiable information which Drupal already stores and/or supports. If a site really wanted a separate login name and display name - why not implement the login name using external_auth - then you get rid of the performance hit from using profile.module or whatever.

subscribing

@catch: So somebody wants a human-readable name. We give them a page full of instructions and tell them to go and get an openid or log onto some other site and set their name correctly and then come back and try again, using a different name.

Right. Have you ever been in business? These are your customers. Or at least they used to be...

I'm +1 for this change. Having to type in "Angela Byron" every time I login as opposed to "webchick" would get really annoying. ;P

macgarvin: No, I have a day job and run a community site with over 5k registered users in my spare time, one that has seen many, many dozens of trolls, fake accounts, multiple returning bannees and the rest on the forums. Allowing anything other than a single username on that site would be an absolute nightmare.

But it seems like I'm in a minority, so meh.

As long as I can enforce only one name per user without having to do any additional work, do what you like.

@catch: Of course. Changing display name would hinge on the "change username" permission, same as always. The difference would be that a user could never modify their internal username; this permission would instead modify a user's display name. So if anything it becomes easier for admins to track down trolls, because instead of remembering user ID 348945 was a pain in the ass, you can now remember that user name "trollheaven" was, and catch any other names he tries to use if for some reason he was given access to that permission (maybe a jaded former mod or something).

Why not use CCK fields for users (hint hint) so that admins can add whatever fields they would like?

@webchick: yes I realise that, but I'd also want username and display name synced both for current and future users. In addition to guaranteed uniqueness for display names. What's to stop a new user setting their display name to another user's username for example? The issue isn't with people changing their own usrnames, it's people trying to register 4-5 accounts for various nefarious or comedic reasons.

dmitrig01: the argument here is that cck fields cost an extra join, and that display name should be considered a "property", like node titles.

"Use CCK fields on users" would be exactly the same as "use profile.module", which is the answer now and is not acceptable.

@catch: The display name doesn't necessarily have to be user-editable. For instance, auto_username could set it based off of profile fields (or anything else) without messing up a user's login ability. Once we have a real display_name concept, contrib can do all sorts of weird things to it depending on the needs of the site.

@webchick, Crell, catch: We need to differentiate between policy and mechanism. It seems much of what is being discussed in last few posts is about policy about how each of you would like to run your websites. As webmasters you should have control over how login/user names and display/real names appear on your website and also filters for how these names are created/derived - like uniqueness and capitalisation, etc. So, we need to capture all the possible policy permutations and derive a flexible mechanism that will enable us all (as webmasters) to make our own policy for our own website.

For example, I don't want to stop you from making display names unique on your website but I sure don't and can't have them unique on mine. So, uniqueness should not be part of the mechanism built into Drupal. Uniqueness of display names should be a policy (an option) set by the webmaster.

So, here's my first stab at defining terms. These definitions are intended to describe these "names" so that module and theme developers know where and how to use them in their themes and modules. It seems that a bit of standardisation of "names" terminology could help a lot in bringing "slick" to Drupal:

* Display name is intended to appear in web text and not in web links or URLs. The default setting is not unique as real names are not unique. But webmaster can change this filter to unique. Hence, no good as as part of a URL nor as username.
* URL name is intended to appear in link text and URLs and not in web text. Always unique as URIs need to be unique for each user to reference their account.
* Username is for login purposes only and never to appear on public parts of a drupal website. Always unique. Only to appear in settings page for each user. Never used to refer to users in web text or web links.

In all cases the webmaster should set name policy as they wish. Choose options for restraints: length, numerics, alphas, capitalisation. For instance they could set: username = display name = url name. Which would give us the current situation where display name and URL name slave off of the username.

Cheers Daniel

I want to create a collaborative editable wiki/book page that can be attached to this issue/thread that we can all work on. This will enable us to capture ideas in a more formal/structured way and so not loose any of the options that we need to put in place. Where can I do this on drupal.org? Create a book? Can we all edit it?

Cheers Daniel

@dahacouk: probably somewhere on groups.drupal.org - I think this issue in general would be appropriate for the usability group, and/or the 'improvements to core' group.

I have created a wiki page at http://groups.drupal.org/node/11092 - I hope that it will serve to bring clarity and structure to this proposal. It should serve as a distillation of the salient points of this discussion. Please add structure and clarity to it.

@sparr: If you are able to edit the issue at the top of this issue thread please can you link to the wiki page so that people don't have to wade through this discussion in order to get the proposal's finer points?

Cheers Daniel

Just to come back on url names, I don't see how this fits in at all. Although I can see the arguments for having display/real name fields, the path module works perfectly well for aliases - and user/uid is already unique. You could use path_auto to set this from somewhere, or just form_alter the user account page to set aliases directly from there without pathauto (which would be a very tiny contrib module). I'd like to see inline editing of path aliases for taxonomy etc. (there's a patch by chx/gupartap somewhere) and if this could be abstracted enough to apply to users too, then it's just a case of permissions. But having an path alias in the user table is very far from how things happen now - why not for nodes too then?

I am a new Drupal admin. I chose Drupal (5.x) because it was supported by the CRM I wanted to use (CiviCRM).

I love how easy it is to add various things to customize my site, but I find it absolutely UNBELIEVABLE that a simple free text field for a Real Name 1) does not exist, 2) is not trivial to add (a module even), and 3) generates this much discussion!

AND THEN, when I log in to post this comment, lo and behold; a free text Real Name field on *this* site!

I require this for effective use of my CRM. Please tell me how to add this to my site, without a lot of (any) php hackage. I dont want it to be the users login, or anything else, just a simple free text field that could be used to populate the same fields in the CRM. It would be nice if it appeared instead of the users login name in posts as well.

Is a free text field REALLY that difficult to implement? Is Drupal THAT complicated/unorganized/whatever that this is a major problem?

Lily

I agree with Catch. There is ZERO need for a “URL name” in core. Core already uses /user/USERID for its URLs (/user/99862, /user/32095, etc.) And since you can't login using the USERID, I don't see how displaying it affects security at all; and, thus, no harm in displaying it. And the path_auto module clearly shows that you can easily (and clean