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.

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.

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.

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.

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

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.

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 cleanly) override that URL in a contrib module.

The whole "URL Name" section of the wiki page should be struck; the rest of the wiki page pre-supposes that having a "URL name" field in core is needed. And with the "no deleting other peoples' ideas" clause, the only one who can edit anything is you, Daniel. So much for a wiki page. :-\

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

That's the profile module. It allows you to put your real name on your profile page and only on your profile page. A "true" display name would display that name everywhere instead of the username. For example, your comment is prefixed with your username, not your "real name."

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

Lily, seriously. Most of us want that feature. We are debating how to add it while still allowing flexible site policies regarding usernames/displaynames. Its because we want the code to be as clean and as flexible as possible that there is such a long debate. Your comment is pretty insulting.

JohnAlbin, thank you for explaining.

Im sorry you feel insulted; imagine how I felt when I discovered this pretty basic item simply doesnt exist, and cannot be (trivially) added! Furthermore, there appears to be significant resistance to adding it! Forgive me for relating my impressions, but I do want to understand why this seemingly simple item is so difficult to implement, and has not been a part of the core functionality to this point. As has been pointed out many times, separate user/login name and realname fields are a part of virtually every site large and small these days, and its quite confusing and disappointing to a new user/admin of Drupal to discover its not even available.

Lily

starlilyth: you can add a real name field via the profile module, which is in core. This isn't an ideal solution though, for a number of reasons, which is why it's being discussed here.

@Lily: Is there significant resistance to adding it?

Catch seems to be ok with inclusion as long as the current username==displayname is still an option (possibly the default config?), and especially if we can fix #83738: LOWER(name) queries perform badly; add column name_lower and index. at the same time (which I suggested in #42 of that issue.) And most of the other "opposing" opinions were along the lines "why not use Profile module?" (Morbus, chx, etc.) But I believe the points made since those comments have convinced people that display name has to be a core "property" of user.

If anyone still has reservations about including this in core (and I really don't think there is anyone, Lily), please read comments #39, #54, and #57 and provide counter-arguments to those points.

I’m hoping we are at the “Where’s the patch?” phase of this discussion. :-)

Regarding the URL name, that's supposed to be the login name part, which is actually mentioned in the wiki. Do we still plan on allowing login to be separate from display name to be separate from username?

Allowing a "login name" that is separate from the username is already possible in contrib. And you can do it cleanly in contrib (well, as clean as possible until we re-do user.module.) For example, logintoboggan allows users to login using their email address.

Right now, today, you could add a user field with Profile module (or use some external field using HOOK_auth or LDAP) and, with some existing hooks into user.module, write a module that uses that new field as a "login name." And you could use existing hooks into the path.module to add aliases for the /user/USERID pages. I've actually done this on website recently; the user logs in using an external website's username, but the drupal username is distinct from the external website username. No modifications to core needed.

So we don't need a "login name" field as a core "property" of $user. But we still need "display name".

I'm tackling this. Hope to have something up by Friday.

@Senpai: Let's brake out the champagne! ;-) Wow! Almost 4 years since the issue was first raised. We finally have someone take it on. Well done! Nice one. Cheers Daniel.

Summary: The whole point of this issue, as I understand it, is to address webmaster ease of implementing a Display Name in a given Drupal installation. The easier we make Drupal the more people will adopt it for their websites. So, even though a feature can be implemented by diving through hoops whilst doing the crossword it isn't attractive to lesser techie gods. Also, issue is to address security issues regarding exposing the Username (one half of the login) on a public website; to provide clear, consistent and document procedures and variables that developers can (re)use to create clean and consistent themes and modules.

@catch, JohnAlbin: When one uses the path_auto module for a user what does the path_auto module putin the URL? The Username? Or is it totally user-definable? Where? Excuse my ignorance here. Is the the path_auto module a contributed module? Can I always rely on it being released in tandem with Drupal core releases?

@JohnAlbin: The whole point about the wiki page is to produce an all inclusive set of ideas that have been generated in this discussion. I'm not editing out anybody's ideas. Add 'em and see. If you want to add additional ideas then cool. But we should discuss these ideas here before they get taken out of the wiki to avoid chompers. But I am taking responsibility to ensure that all views are represented - someone has to, see?

@starlilyth: Thanks for your comments. Don't worry about "insulting" people. Sometimes that's the only way we get things moving is to make a noise. Keep on shouting. Hopefully you guys will come over for DrupalCon in Szeged and we'll buy JohnAlbin a drink and make him feel better. ;-)

@Susurrus: As JohnAlbin says all this stuff of having separate Username, Display Name and URL Name is already possible using contributed modules. And there is a big desire to have the options of keeping these items separate and applying different rules to them - ie uniqueness. The whole point of this thread to get them into core so that it is easier for webmasters to build their websites without having to resort to hacking themes or code; and it's easier for developers to maintain their themes and modules because there will be clear and consistent places for these fields to be stored.

Cheers Daniel

@dahacouk: pathauto is in contrib, but is well maintained, and used on thousands of sites. I'm not sure what options are available for username paths at the moment, but it'd be easy to do what you want (or form_alter the my account page to set an alias directly from there). Either way, a url name is a completely separate issue to the idea of a display name, and needs it's own feature request. Implementing it by itself as a field in the user table would be "won't fix" - the idea of 'pathauto in core' has been mooted before and might have more traction though, so I'd start by looking there.

@Susurrus: As JohnAlbin says all this stuff of having separate Username, Display Name and URL Name is already possible using contributed modules. And there is a big desire to have the options of keeping these items separate and applying different rules to them - ie uniqueness. The whole point of this thread to get them into core so that it is easier for webmasters to build their websites without having to resort to hacking themes or code; and it's easier for developers to maintain their themes and modules because there will be clear and consistent places for these fields to be stored.

So what are the rules you are applying? that for some sites a unique username should be required, but for others it should not? Thats considerable complexity to add to this patch.

@mikey_p: no one is has so far suggested that Username and URL Name should be anything other than unique. But there is differing opinion when it comes to a Display Name. Some are adamant that a Display Name should be unique and some want it to be like real names where you get many people called John Smith. So, it seems, that the uniqueness switch should be able to be set by the webmaster when it comes to a Display Name.

Other rules ("input filters" is more accurate, I guess) could be length, numerics, alphas, case, capitalisation, punctuation. See http://groups.drupal.org/node/11092 for a better list of options that people seem to want from scouring this discussion.

As JohnAlbin says all this stuff of having separate Username, Display Name and URL Name is already possible using contributed modules.

Actually, I didn't say that (see comment #90 above.) "Display name" most certainly cannot be done in contrib easily. So let me re-phrase it:

Login name (what the user types into the login form) and URL Name (what is displayed in the /user/SOMEUNIQUETOKEN url) can both be done easily with a contrib module. And there are already many examples of existing contrib modules that do those 2 things; path_auto and logintoboggan are just two examples. (And to answer your aside about path_auto, by default it uses /user/USERNAME, but thats configurable.)

Plus, path aliases are handling in a completely separate (and much more flexible) manner than using 1 field in the user object; so adding a single field in the user object would be a significant step backwords in being able to configure the user URL. It will NOT ever be added to the core's representation of a user; hopefully I've explained it sufficiently this time. Let me know if I haven't.

So, to sum up, putting a "login name" or a "url name" into the core representation of user would actually make Drupal less flexible. But "display name" must be a property of the user (See Crell's arguments in #39, #54, and #57 for the reasons.)

The g.d.o. wiki sent me back here for issues and disagreement, so once more I'd like to bring up the sticky legal issue of age sensitivity. Display Name (which is likely to be implemented as 'real name' in many cases) carries with it some legal baggage related to disclosure of personal details of minors.

These policy/legal issues are probably best handled in a module rather than core, and I'm not suggesting abandoning the concept of display name in core (which will provide significant performance advantages in rendering nodes which use a display name attribute); but it must be done in a manner whereby a site builder can create a site that is in full compliance with legal restrictions. Perhaps (??) this might involve a display name hook that is called prior to rendering; whereby such policy can be implemented.

If age is not a core field as well, this brings us full circle to the performance degradation of requiring a profile load to determine if the display name can in fact be displayed. I'm mostly agnostic w/r/t the implementation, however I'm not seeing anybody else that is concerned with the legal ramifications of moving forward. The US and EU have some very specific regulations regarding usage of real name by sites accessible to minors - that IMO must be taken into consideration.

About the time that I left the US there was also a pending Senate bill to *require* the age attribute on the accounts of 'social sites'. I do not know the outcome of this bill so perhaps somebody else can comment on whether this has been written into US law or whether it died in committee. I'm not trying to hijack this issue as this is seemingly unrelated, but intimately tied to the issue of implementing Display Names - as the existing laws are specific to the handling/disclosure of 'real names' within certain age boundaries.

general subscribe-fu

Since the users themselves decide what to type in Display Name (as well as other core user fields), I don't really see that these legal ramifications are of concern to Drupal core. It would probably be of concern to sites that are gathering more detailed information, such as first name/last name, birthdate, etc. but they're taking the performance hit of profile module (or Bio module or whatever) anyway.

In fact, in my head, the core implementation of Display Name would just be the username field as it was typed in by the user, with users.name being the lowercase equivalent of it, and would not be exposed to the end user. In other words, no difference to what users see now, with the exception that all of our user queries no longer have to LOWER(name) in comparisons so we gain a performance benefit right out of the gate.

Then, a contrib module like Auto User Name or something (akin to Auto Node Titles) could be written to automatically generate the display name based on first name + last name fields or whatever weird site-specific logic there is.

webchick: You mean something like this: http://drupal.org/project/auto_username ? :-)

I see it in essentially the same way. Add a "display_name" column to the user table. By default, set it to the same as the username (give or take capitalization). Make *all* places in core that show a username show that field instead. Allow contrib modules to disable the "set same as username" logic and put their own in there, however they feel like doing so. Done.

@Crell: That sounds like a good option but definitely shouldn't be hard-coded as it doesn't fit with many people's desires.

@dahacouk: ... Not to be snarky, but what part of "allow contrib modules to... put their own logic in there, however they feel like doing so" implies hard coding anything? How did you get any sense of hard-coding out of my statement at all?

The closest it comes is having the display_name calculated at edit time and saved rather than determined on the fly at runtime. That's for performance, which is one of the key failures of the "just use profile.module" solution. We've been over that.

@All

Thanks for being active on this. Drupal++

As it turns out, part of my frustration was lack of understanding how all the pieces fit together, so, my bad. I built a suitable profile form in CiviCRM, then removed the default Drupal profile fields, and Taa Daa! Users now see one unified Profile form to fill out with all my required fields, and it inputs directly into my CRM.

I would still like to have a useable Real Name field in the CMS that would be used in places like forums and blogs, and possibly have the CMS read those values out of the CRM (or vice versa), but that is less essential for my site at this time.

Again, thanks to all for your hard work, and patience.

Lily

The route I'm taking to make this patch is approximately what Crell just said.

1. Make a new field in the user table.

2. Insert the contents of the username field into the displayname field at user registration, lest the displayname field be NULL, which would cause MySQL to cough, since that's not allowed (by me).

3. Create a new fieldset at admin/user/settings, and add an admin checkbox that toggles the use of displayname sitewide.

4. Add a pair of yes/no radios to the new admin/user/settings fieldset that toggles $unique == TRUE, but this setting will be disabled by default until the first checkbox becomes checked. (Am I allowed to put little jQuery usability stuff like this into core?)

5. Add a second pair of yes/no radios to the admin/user/settings fieldset that toggle whether users are allowed to edit their own displayname. Also disabled unless the parent checkbox has been checked.

6. Convince all uses of $user->name within core to reference $user->displayed_name instead, but only if the variable_get('user_displayed_name') is true. (Not sure if this will be a performance penalty yet, or not. Might have to take it the other way.)

7. Look up all uses of theme('username') and modify appropriately.

8. Create a theme function for the user form's #description text underneath the displayname field. This text must become dynamic depending on what settings the admin has selected, or disabled.

9. Collect underwear.

10. Profits!

Slight modification to points 3, 4 and 5 above. The admin/user/settings form already utilizes radio buttonsets to toggle the Signature Support or Picture support on and off. In the interests of UI consistency, I'm going with that same method for a radioset that toggles 'enables' or 'disabled' for Displayed Usernames.

I'll change points 4 and 5 to checkboxes though, so there's not three sets of radios that all do similar things. Might even make the checkboxes slide open just like the Picture Support ones do.

This is the administrative settings form for $displayed_name thus far. The two checkboxes don't show up on the page until you enable the Displayed Name. I'll be adding some jQuery to disable the Unique checkbox unless the Allow Changes checkbox is clicked.

Comments? Ideas? Changes?

______________________________
Senpai (also see my Drupal Dojo account)
I work for Achieve Internet.

This is the user's own account page. I've chosen to add a field in between the username and email address fields. It's mandatory, but only if the site admin has enabled $displayed_name AND the user has elected to edit their own profile.

When a user is registering on the site, the displayname database field will steal the username field, and thus it will always be populated with a value. If the user saves their account form after having changed the autofilled value from $user->name, the db will respect that change. The only drawback to this approach that I can think of is that existing users don't have a value in here, and should the site admin switch on "Show displayname instead of username", there will be a lot of empty page titles!

I thought, perhaps, that during the upgrade cycle, a site having thousands of users might want to run a script that automatically populated this field, but to run it in batches is beyond my capabilities. Flobruit suggested to me that if I were to modify the theme username preprocess, I could query for the displayname, and if it doesn't exist, fall back to the username. I like that idea. A lot.

Comments? Ideas? Changes?

______________________________
Senpai (also see my Drupal Dojo account)
I work for Achieve Internet.

There is an argument for letting admin add a custom field to the core registration form.
I read today a post on an innovative way to fight spam:
http://www.humpa.com/forums/ptopic300.html&sid=eb91da269a0a6b02fe556196f...
Basically, it is adding a field "not to be filled if you are a human".
Most bots seem to have found a way around captcha, but a new field could be set as a "spam trap".
Probably not 100% proof, but any new way to fight spam is welcome.

Senpai: do you have any plans to deal with the LOWER() issue as part of this patch? On first thought I think the display should be set to 'display name' whatever happens, and the login name only shown if it's different - this seems like it'd be more resilient to changes while sites are already running.

From looking through this and talking to catch, it seems like some problems have not yet been thoroughly considered. For example - what about auotcomplete fields that look up by username? Will they look up by "display name" if so, are we back to having a LOWER() in the query? What if those "display names" are not unique? Essentially that autocomplete becomes fundamentally broken.

Alternatively, if the "display name" is allowed to radically diverge from the username the username is never displayed except perhaps on some admin pages, it would seem that autocompletes on the username again become much less useful since an admin will often needs extra steps to figure out the desired username.

One small idea: if we do have a "display name" then it would seem we could make the username format even more restrictive and/or not bother storing anything other than the lower-case version. Basically the update path would be that the current username become the "display name".

The issue with forcing the username to be lowercased - which'd be good for removing those nasty queries, is if my username is Catch, I'd have to log in as catch, or if it was keith.smith as keithsmith. That's not such a big deal since we could lowercase username input on the login form using the same rules as anywhere else and make this happen transparently. However if usernames are changed at any point we have no reference copy, and there's also no way to display it anywhere (which we might well want to do on 'my account' or in registration/user reminder e-mails). I think this probably means a third column - it's also probably what we'd want to display from the autocomplete results.

@Crell: yes I saw the "display_name calculated at edit time" and jumped. But I think we're looking at different levels of the interface. I'm thinking of what the user/webmaster sees and you're thinking about what how the system functions (?). Yes, reckon both compatible, yeah?... Cheers!

@Senpai: Bravo! This is looking real good. You're taking on all the issues that I can see.

I would echo roaming's idea of "letting admin add a custom field to the core registration form".

Also, if an admin wanted to restrict the user input with a form filter say on length, case, capitalisation, punctuation, etc where/how would this be done? Is there a standard way for Drupal to do this? I can see that putting in all the tick/radio boxes for all these permutations at this stage could be seen as bloat when we don't even have the patch accepted yet but it'd be good to know how this was possible in future either by another patch or by a bit of admin work.

@pwolanin: Regarding: "What if those "display names" are not unique? Essentially that autocomplete becomes fundamentally broken." Well, it's very likely that display_names will not be unique in many sites that want the display name to be the real name. To tell users apart would we need to have a disambiguity (see Wikipeadia) results view - either in drop-down or page form - which included some other information such as location or date of registration? Hmm... Would it be easy (ha!) for admin to do this?

Is this something that needs to be solved for the patch to get accepted?

Node title auto-complete already runs into this problem, and solves it by sending/showing both the node title and the nid. Since login names have to be unique, we could do the same here and on user autocomplete return something like: Larry Garfield [login: Crell] to easily differentiate between me and all of those other Larry Garfields out there. (There are some, actually.)

It almost sounds like on an implementation level like we're not adding display names, we're integrating http://drupal.org/project/alt_login into core. That's not a bad way to think about it, I suppose, and might even be easier on the upgrade path for other modules. ($user->name is the display name, and we add $user->login_name and change core's logic.) Or maybe I'm just over thinking this.

@catch - my suggestion was to still allow you to log in as "Catch" "CATCH", etc. Just as you can now. The point would be to only store the lowercase version since there would be a "nice" display name that you could capitalize or make into your real name, etc.

In other words, the system could only ever display back for you the lower-case version. But since it would be rarely used and only for more admin-type reasons, that seems like a reasonable trade-off to me.

@pwolanin: hmm, well I guess that's alright. We're not stripping punctuation either - 'cos I can easily register a name like "--__--" at the moment.

Crell: good plan with the autocomplete. And yes I reckon treating the login field as the extra field is probably the cleanest way to do it - just have to make sure user name display is consistent throughout core (and get the apostrophe patch in).

In comment #110, Roaming said:

There is an argument for letting admin add a custom field to the core registration form... in order to combat spammers.

Roaming, it's my view that core should not evolve to deal with every method of spammer out there. There are plenty of great contrib modules that can handle the addition of an extra form field to the user registration form, if desired. While it's a fantastic idea for a logic trap, I won't be incorporating your idea into this patch, as it would take things way off scope.

In comment #111, Catch said:

Do you have any plans to deal with the LOWER() issue as part of this patch? On first thought I think the display should be set to 'display name' whatever happens, and the login name only shown if it's different - this seems like it'd be more resilient to changes while sites are already running.

Catch, I'm completely ignoring the lower() aspect of $displayed_name, because I want it to be as generic and flexible as possible. It should store whatever the user inputs, up to 60 characters, and including punctuation, dashes, slashes, and capital letters. Whatever you, as a user, envision your "tag", or "handle" to be, you can type it in here and be known by it. It will utilize a strip_tags() and a regexp that whitelists every character I can think of that might be cool to display without breaking a site. I'm also using most of the existing validation functions of the 'username', such as the "You can't put multiple spaces in here", or the "illegal characters" stuff.

In comment #112, Pwolanin said:

what about auotcomplete fields that look up by username? Will they look up by "display name" if so, are we back to having a LOWER() in the query? What if those "display names" are not unique? Essentially that autocomplete becomes fundamentally broken.

Peter, I don't envision this patch addressing the need to look up or search for users by their display name. Yes, I agree that it'd be cool, but right now, the drupal.org site offers a Users local task tab, which does a fair job of returning results which contain the user's username or their first name or their last name. Maybe at some point we could revisit this after code freeze, and implement this type of search directly into core, but for now, it;s a no-go. Too time consuming.

In comment #117, Crell said:

It almost sounds like on an implementation level like we're not adding display names, we're integrating http://drupal.org/project/alt_login into core. That's not a bad way to think about it, I suppose, and might even be easier on the upgrade path for other modules. ($user->name is the display name, and we add $user->login_name and change core's logic.) Or maybe I'm just over thinking this.

Larry, it seems to me that everything in the Drupal world relies on $user->name and $user->uid. If we were to uproot that concept for core and 100% of contrib modules in a single version release, wouldn't we cause mass confusion? I can think of several modules that call $user->name directly when performing operations, and if that data were now a string containing dashes, capital letters, and periods, I think things would not be too happy in the issue queues.

In comment #119, Catch said:

Crell: good plan with the autocomplete. And yes I reckon treating the login field as the extra field is probably the cleanest way to do it - just have to make sure user name display is consistent throughout core (and get the apostrophe patch in).

Catch, I also agree with Crell's autocomplete idea. I do, however, question the idealism of your above statement in the context of a site owner who's been using Drupal for years now, has usernames, and usernames only, and doesn't want to turn on a display-name capability. If we do the "roll alt_login.module into core" method, which makes $user->name == $user->displayed_name, and adds a $user->login_name, how do I handle the situation where the site is NOT using displayed names, but needs to show the $user->name in, say, logintoboggan's logged_in block, or perhaps the breadcrumb array wants to show a username as part of it's array but the $user->name is blank cause the site owner never turned it on?

Can it be done? Talk to me.

Senpai - if admins don't want to use seperate displayed names, you'd just sync user/login_name and display name so they're identical. That way $user->name is used consistently whatever the setting.

What about an approach something like this (I'm thinking aloud):

- Add users.login as a new column.
- On upgrade, copy users.name to users.login.
- Alter core to use users.login for authentication and users.name for display. (This should be a minor change.)
- Create a a hook that a module can implement which defines a display-name-generation mechanism. Something like:

function hook_user_display_name() {
  return array(
    'same_as_login' => array(
      'title' => t('Use login name as display name'),
      'callback' => 'example_display_name',
  );
}

/**
 * The default implementation.
 */
function example_display_name($account) {
  return $account->login;
}

The admin can then select a display-name-generating engine from a list on the user admin page (radio buttons; it doesn't make any sense to have more than one active at a time). Then on user save (NOT user edit; user save, because it could be updated from a non-form pathway), pass a complete, saved $account object through the specified function, get back a display name, and save that as users.name. All of the display logic built off of $user->name then continues to behave normally. Engines that need to get user data can form_alter their way into the process. A "user-defined display name" can be another core engine. Auto_username can be another. LDAP and OpenID and such can add their own, too, if they feel like it.

The reason I suggest a formal process rather than just "oh, you can do it in hook_user" is that the user save/submit work flow is totally wacky and ugly and horrid and the data you want may not be accessible at anything resembling a sane point in time; plus there's the whole object/array mess in hook_user(), etc. Completely crazy. If we want to go there, though, we need to clean up that work flow first so that things like auto_username don't get race conditions.

-1 for some special hook to deal with display names. It should be consistent with nodes. So let's clean up hook_user instead. That'd probably be nice to do as part of Data API anyway.

I do not expect users to get revamped as part of a larger data api push in the near future, so a "current generation" solution is therefore necessary. Maybe another op for hook_user? (I can't believe I just said that.)

@Crell - most of #122 sounds reasonable. However, I'm with webchick - if we don't get some serious hook_user cleanup into 7 it will be bad.

So, maybe this patch should just assume that greater sanity is coming to hook_user, and just get the basic functioning in.

OK, so get in how? I'm all for making hook_user suck less, I just don't think it's going to be full-on data-api at the moment. I am unclear where in the process we'd want the display name changed, given that the data you have available in each current step of hook_user is structured differently or stale or flat out wrong at various times.

This field should just be for getting the field in and that's about it. some module could use hook_user op update could do a straight-up query against the table, even if we don't end up doing the whole reworking it to be sane shenanigans.

@Pwolanin in #125: Yes. I'm pushing this patch as fast as it will go in the direction of "make a field for all of us to have access to whenever we need a user's Real Name". True, there's lots of cleanup to do in hook_user, and I'm encountering a bunch of it this morning, in fact. My assumption is that whenever I find something that doesn't work as it should, either work around it or ignore it altogether. This patch tries not to make sweeping changes to existing functionality whist introducing new functionality. That's my philosophy, anyway.

@Crell in #126: Yes, hook_user needs to be de-suckified. I am attempting to change the displayed name everywhere I can without breaking stuff that needs to be fixored, but isn't yet. I hope this approach works for the time being, I really do.

@webchick: The problem with op update is that it stacks, and this logically doesn't make sense stacking. Core hook_user will, presumably, set display name to be the login name, to maintain the current behavior. Now install auto_username. Both are now trying to modify that field at the same time, and only one can win. Now what happens if ldap module decides to set display name based on the LDAP server? I see a lot of ugly collisions here unless an admin can pick one; relying on module weight for this makes me wince.

@Senpai: I think you'll have a much easier time (and make it easier for module upgrades) if you just redefine $user->name as the display name and add $user->login for the login name, then update the login-related code. It's less code to change, fewer places to miss something, and we get reasonably good variable names out of it with limited work.

Subscribe

It's taken some time to get a handle on everything that is being tossed around and examine the details. However it seems obvious that there's likely to be a mess in mostly obscure places if theme_username() returns display name; which may be truncated to 15 chars for a lot of folks (strlen($display_name) > 20) and aren't likely to be URL safe by default. We can increase the display length with the side effect of potentially messing up blocks and other stuff which have been designed with this limit in place.

There of course will be dissent from those who want to abolish username completely for display, but the primary impetus for display name is in node attribution; and I'd suggest leaving username alone in most other places. This is obviously a compromise between a lot of competing ideas. Wanted to bring up the possibility of creating theme_realname() for use primarily in node display, which falls back to theme_username() when display name is empty but is otherwise a clone of theme_username() which just tacks on the display name to $output. I've encountered many attributions elsewhere such as 'bob123 (Bob Smith)' which would provide the functionality many of us are looking for; leaving profile links and 'who is online' displays with shorter 'handles' that can be made URL safe if necessary. I just fear that replacing username with display name across the board is going to create a nightmare of issues down the road. One huge advantage is that this would be backward compatible wherever realname wasn't used. Display name in this case wouldn't have to be pre-populated or be a required field unless site policy mandates it - and lets folks like me wipe it clean for young members without messing up any site functionality.

@Senpai - I agree with Crell in #129 re: $user->name becoming the display name.

@Crell - I'm not sure even cleaning up hook_user is going to solve that problem. What I thought you were suggesting is some sort of settings page where other modules could inject their operation into the select/radios. So, the core hook_user would check if the setting is designating an operation handled by core. If so, it acts, if not, it does nothing and assumes some other module is acting at some other time.

Crell and Pwolanin,

I've already done the work to make a new field, and it's integrated into most of the core functions by now. With another hour or two of cleanup, and some peer review, I'll be ready to release this patch for community testing and comment.

I agree that your collective idea is valid, and probably needs to be seriously considered, especially in light of some of the other office mate's input, which also seem to favor this same idea of creating a $user->login_name to replace the current username.

Here's the two final drawbacks that need to be overcome before this could become a reality and convince me to abandon what I've created thus far and move toward a new approach.

1. Making $user->name into the displayname forces all users to pick a unique name, which doesn't accurately represent the masses of people on a very large site or corporate intranet. For example, if there's another person who's registered as "joelfarris", I can't be "JoelFarris", or even "Joel Farris", even though I am, in fact, THE Joel Farris. Bah! In fast, what if there were already a "senpai", and thus I couldn't be "Senpai"? I'd cry, that's what. It happened to me on the Playstation Network, and I wasn't the same for a week.

Turning $user->name into the $user->displayname (or whatever we call it) would require a lot of cross-checking for the admin-selected variables which may or may not allow $user->displayname to be unique, which allow users to edit their own displayname, or even whether or not to use that as the displayed name or not. It a site admin doesn't forcibly turn this displayname "feature" on, they're gonna get the $user->name everywhere, just like they've always done. Since this is an elective feature to core, at least in the community's eyes (see comments above that read, "Don't force this upon meeee") we need to be very careful not to re-invent the wheel. Making $user->name into the displayname will result in a lot of code deletion as we attempt to make the existing $user->name field into a non-unique, case-insensitive, punctuation-agnostic, length-variable (set by the admin) string with argument-based truncation set via the brand spankin new theme('username', $object, $displayname = FALSE, $truncate = TRUE, $length = 20) function.

Once $user->name is bastardised in this way, we still have to go back and create a field called $user-login_name that contains 100% of the existing functionality of the already perfect $user->name. That seems like an awful lot of work? Even more so when you consider that my patch has all this stuff already working.

2. We need admins to see username all the time lest they get confused, but we need users to see displaynames, and they have to be generated from the same theme function. The way I've decided to address this is to make the calling theme declare the $displayname = TRUE argument, and thus, core is not affected in any of it's current dealings with $usr->name. Since some type of Drupal 7 work will undoubtedly be done on hook_user before the bats migrate to Cuba again, I'm trying to keep from changing too much of core's code, and trying to keep the contrib module's upgrade paths clean of FOD debris.

Should we all decide that $user->name IS now the displayname, and $user->login_name is what you use to login with, we'll need a way to allow site admins to see both names side by side (as has already been suggested above) when viewing things like admin/user/user, and to do so we'll probably have to create separate theme functions for loginnames vs. displayednames. Again, sounds like a lot of work for a bunch of lazy-ass programmer types...

Thoughts?

@Senpai: Not much to add but your position seems very sound. Cheers!

Patch attached

Oooooh boy. I just created a really cool set of admin/user/settings for this baby, but I have the distinct feeling that I'm gonna get my ass roasted by the community for going above and beyond the basic spirit of a patch. I really hope you guys like the way this works. I do. In the new spirit of usability, the settings form is smooth, and understandable by the merest mortal. See what you think.

How to test this patch

The way to test this new field is to visit admin/user/settings, and take a look at the options within the Displayed Name fieldset. Once displayname is enabled, other settings become available. The site admin can elect to allow/prevent the displayed names from being edited by mere mortals, and even enforce a unique displayed name per each user.

Once you're familiar with these settings, turn on Displayed names, and go edit your own profile. You'll see a new, non-required field that's automatically defaulting to your current username, regardless of whether or not you have access to edit your own username. (I chose not to automatically store everyone's username as their displayname for the simple reason that several people have expressed the desire to hide usernames whenever possible for corporate security reasons). Anyone who edits their profile is very likely to store a displayname for themselves, because even though the field is not required, it's #default_value *is* the username, and therefore we've given the user a choice to create one or use the current default. If a user has never visited their profile before, and therefore has no displayname, the patch presumes to use the admin-defined token text that's been set within admin/user/settings in place of that particular user's displayname.

When a user creates a node or a comment, their displayname will show if they've saved one. If they've never edited their profile before, and they are viewing a node or comment that they own (created), a call-to-action link is present to allow them to change the sitewide admin-selected text of their displayname to something that they like.

Revised patch attached. Code formatting cleanup and better comments.

I also changed the approach to a couple of things, thanks to some input from kscheirer. Now, user_perm() no longer has a database call in it (whew, that one really bothered me), and system_user_settings_submit() is no longer bastardized, but rather, a user_admin_settings_submit() was created to handle the specificity of the displayname settings.

@Senpai: It's all looking real cool...

1. Is it possible to add a "Require users to create a displayed name" checkbox in the /admin/user/settings ? That would be real sweet!

2. If a displayed name was required it would have a red star by it, right? And that would also be required at the time of creating an account in /user/register, right? Great!

3. So glad you put the "Displayed name:" field in /user/register - but found this: notice: Undefined property: stdClass::$name in /www/drupal/modules/user/user.module on line 1454.

4. Is the wording "Use displayed names instead of usernames" correct? As if displayed name support radio button is enabled and there is no input from either the user or the admin then doesn't the displayed name default to the username anyway? Hence, wouldn't the title for the section best be "Displayed name support:". I'm just aping the Signatures and Pictures way of doing things.

5. Not sure if this is the correct way but when I disable displayed name support the "Displayed name:" field still appears in the /user/3/edit area. I have to untick the "Allow users to change their own name" checkbox to get it out of the /user/3/edit area. This is the case if displayed name support is enabled or disabled. Surely if displayed name support is disabled then it should automatically remove the "Displayed name:" field from the /user/3/edit area...? I notice that it seems to be the Drupal way of doing things that when you disable an option it remembers the settings for when you enable the option again. But in this case it seems like the options are still active.

6. "Enforce unique displayed name" doesn't seem to be enforced. I set up two users with the same displayed name without a problem whilst this option was checked.

Cheers Daniel

@Senpai - I still feel that we would be better off with the opposite approach.

I can also immediately see that the patch misses some things - e.g. if you want to do it this way, node_load() needs to be changed to add both fields since you added calls like theme('username', $node, variable_get('user_displayed_name', 0))

I've not had a chance to test the patch yet (just got back from vacation), but I wanted to comment on:

Making $user->name into the displayname will result in a lot of code deletion as we attempt to make the existing $user->name field into a non-unique, case-insensitive, punctuation-agnostic, length-variable...

OK, so let's not do that. Why can't display names be unique? Do you really want to allow a "senpai" or "crell" to post on Drupal.org and masquerade as us? I don't. :-)

If anything, it's login names that need extra attention. they should follow more conventional login name standards, such as case-insensitive, no wacky characters (for some definition of wacky), etc.

Relying on the non-presence of a display name value to trigger "some other display name logic" is also the wrong approach, IMO. That makes it too easy to override an admin-defined mechanism in favor of your personal preference, even if the admin wants to enforce a pattern (or pull from LDAP or some other 3rd party system).

@dahacouk in #138:

1. Is it possible to add a "Require users to create a displayed name" checkbox in the /admin/user/settings ? That would be real sweet!

No. The short answer is no, and here's why. I originally made this field mandatory, but after testing and deliberation and discussions with the fellows, it's come to my attention that forcing a user into filling this additional field would increase the complexity needed for a new user registration process. Right now, users need only a username and an email address in order to make an account. That's a relatively low barrier to entry for a site, which is good. As it stands right now, the displayname field is optional, so if you type something in there, it'll save, but leave it blank and it takes on the value of your username. (Come to think about it, I'd rather have this field take on the default_value of the admin-selected string of "Name withheld" or some such. That way it would be strikingly clear that if you don't fill in this field, you'll be known as "a-nony-mouse" or "Name withheld", or whatever the admin specified.)

Should the registration form ever become part of (or replace) the Add A Comment form as some developers have suggested it could, having the displayname field be required would further complicate the process of posting a comment.

Contrib modules such as logintoboggan allow users to sign up with their email address and be instantly logged in. If an admin had turned on the "displayname is required" checkbox six months ago, and is just now installing logintoboggan, what are we supposed to do with that displayname* field now? Sticky situation, to be sure.

Site admins can create new users by hand. This process utilizes the same user registration form that brand new users see, so if that field was required*, site admins would have to choose a new user's alias before being able to submit that Create A User form. Sucky.

4. Is the wording "Use displayed names instead of usernames" correct? As if displayed name support radio button is enabled and there is no input from either the user or the admin then doesn't the displayed name default to the username anyway? Hence, wouldn't the title for the section best be "Displayed name support:". I'm just aping the Signatures and Pictures way of doing things.

I took the approach of making this radio buttonset not only a toggle switch, but also an activator. Thus, if an admin enables "Use displayed names instead of usernames", usernames will be hidden and all site users will see the displaynames even if that happens to be "name withheld".

5. Not sure if this is the correct way but when I disable displayed name support the "Displayed name:" field still appears in the /user/3/edit area.

I missed that. I will change it so that the displayed name field only show up when editing an account if the "Use displayed names" AND the "allow users to edit their names" are on. Good catch, thanks.

As to your point #6, I have no idea why that's occurring, but I'll check it out and see. That begs the question of how specific to get? Should "force unique" be as unique as a username? Should it disregard capital letters, thus allowing 'joel' and 'Joel' as two different user's displaynames? Avoiding the lower() when running queries would be good, in my opinion, but if we really need to be that specific, I'll do it.

@pwolanin in #139:
Woops! I thought I'd addressed that already! You said,

I can also immediately see that the patch misses some things - e.g. if you want to do it this way, node_load() needs to be changed to add both fields since you added calls like theme('username', $node, variable_get('user_displayed_name', 0))

I shall attempt to add the author's displayname to the $node object during the node_load() building cycle. I hope this doesn't slow down the node_load ? We certainly don't need any extra sluggishness when building node objects, now do we?

I don't see an issue with forcing a display name in the database if that's switched on - just migrate existing usernames to the new table, and save the username as both fields on user save/edit if the display name field is either empty or disabled. There could also be javascript auto-complete suggestion on the form itself to speed up the registration process.

Overall, I agree with pwolanin that adding a login-name field seems like a much better option for this. That way, even on sites which retain current username behaviour - you wouldn't need do all this variable checking in theme_user_name() and if && !empty($object->displayed_name) - you'd always print displayed name regardless of the setting and the rest would be handled at a much lower level. At the moment it feels like a lot of complexity is being added to solve a problem that I don't think is there.

SUBSCRIBE

Revised patch attached.

Added the displayname to node_load().
Fixed the extra form field being visible when it shouldn't.
Squashed the notice: Undefined property: stdClass::$name on line 1454.
Unique names are now properly enforced, and include a LOWER() comparator so that 'crell' cannot be used if 'Crell' already exists.
If an anonymouse user is creating an account, default their displayed_name to the admin-chosen token, but only allow them to change it if they have edit permission for that field.

@ pwolanin and catch:

I feel that although this sounds like a good idea on the outside, it would force every contrib module that deals with logins or usernames into a re-write for D7. It wasn't my intention to make things that complicated.

I really don't think that we need to re-create the user login system within core just to add what amounts to an additional user profile field. I would be more than happy to do so, however, and would only need a core maintainer's blessing before galloping off down that path.

If we all agree that it's cleaner to do it your way, at least to stay true to core, then so be it. I'm in.

I'm just not going to make my very first sizable core patch into an "I wanna re-write the user login system, and make every other contrib module maintainer adapt to it". If you guys know anything about me, it's that I don't wanna be presumptuous like that.

@Senpai - I think many more modules deal with printing the user name than rework the login process, so I see the balance being in the other direction.

I see the balance being in the other direction.

+1

"layout breakage"?

You use displayname in some places, and displayed_name in others.

Displayname should be display_name, or displayed_name

'...' should be run through t()

some places you use variable_get('user_displayed_name_token', '...') and others just '...'

+define('DISPLAYED_NAME_MAX_LENGTH', 60); // TODO: Make this an admin-setting.

If there is a TODO, then the patch needs work :)

+    $sitecreator = TRUE;

uhm

this is all Ih ave time for atm b/c I am tired

I've run into this problem lately, so I'm happy to discover this issue. +1.

I'd like to point out there is an analogous feature already in drupal: path aliases. So, if we wanted to make "user aliases" similar to path aliases, we would allow more than one alias per user and provide an API like drupal_get_user_alias() similar to drupal_get_path_alias(), perhaps allowing for custom_user_rewrite() similar to custom_url_rewrite(). I'm not certain this is the way to go (might be bad for performance), but it has the advantage of being familiar to those who know path alias API.

@Dmitri in #149

"layout breakage"?

I don't know what is meant by "layout breakage".

You use displayname in some places, and displayed_name in others. Displayname should be display_name, or displayed_name.

I fixed this. Good catch. It was a leftover from when we were debating about what this thing should be called.

'...' should be run through t()

Actually, it is being run through the t(). The line in question looks like this:
<?php $name = t(variable_get('user_displayed_name_token', '...')); ?>

I've since changed it to <?php $name = t(variable_get('user_displayed_name_token', '&hellip;')); ?> because I didn't realize that I'd left a 'three-period' string behind when it should have been an HTML ellipses.

In some places you use <?php variable_get('user_displayed_name_token', '...'); ?> and others just '...'

The one line where the '...' occurs by itself is a last-ditch failsafe for when the displayed_name is switched on, the user has purposefully deleted their displayed_name, the admin hasn't set a default token string to be used even though there's supposed to be a default token there, and the theme calls for a theme('username', $displayname = TRUE). In this far-fetched yet possible scenario, I don't want the site to be printing 'anonymous' for everybuddy or worse yet, a hard-coded string of my choosing in place of everyone name, so I elected to make this failsafe into a three-dot ellipse as well.

<?php define('DISPLAYED_NAME_MAX_LENGTH', 60); // TODO: Make this an admin-setting. ?>

I went ahead and turned this into an admin setting, so now site admins can define the max length of the Displayed Name and themers can truncate that length to anything of their choosing within the theme('username') function call.

<?php $sitecreator = TRUE; ?>

I added additional inline documentation to clarify this line's purpose.

The one line where the '...' occurs by itself is a last-ditch failsafe for when the displayed_name is switched on, the user has purposefully deleted their displayed_name, the admin hasn't set a default token string to be used even though there's supposed to be a default token there, and the theme calls for a theme('username', $displayname = TRUE).

This would be solved so easily if the default behaviour was simply that username = display name, and admin setting determined whether it was synced with login name or not. Then empty usernames are simply populated with the login name no?

@Catch in #152: True, but only up to a point? What about those enterprise level clientele who do not want, under any circumstances, to reveal a user's login name? What then? I'm not sure your argument works in that instance.

Don't get me wrong, though. I'm not saying that $user->login and $user->name could not become the defacto standard. I'm just playing the advocate here.

@Senpai - then display name becomes a required field.

Why are you checking if UID = 1? Shoudln't it be by permission?
&& $uid = 1 this looks wrong. very long.

About layout breakage: you have that in one of your docblocks

@pwolanin and catch: You two keep on suggesting that "username = display name". Please clarify for me just one thing. If Senpai followed your suggestion could a display name be non-unique or would it force us all to have unique display names?

Cheers Daniel

Yes, we absolutely want everyone to have a unique display name. I do NOT want another 'webchick' running around posting Nike ads.

I seem to recall several people suggesting earlier in this thread that there might actually be two people named Ron Huber on a single site. Should we prohibit all Drupal sites from letting two users display their own names, even if those names happen to be identical?

Hm. I guess I don't understand how this became so complicated.

1. User A signs up to site, enters "Ron Huber" as their name. "Ron Huber" gets stored as $user->display_name, "ronhuber" gets stored as $user->name.

2. User B signs up to site, enters "Ron Huber" as their name. System comes back and says "Hey stupid, there's already a Ron Huber. Pick something else." They enter "Ron J. Huber" as their name. "Ron J. Huber" gets stored as $user->display_name, "ronjhuber" gets stored as $user->name.

3. User C signs up to the site, enters "Ron J Huber" as their name. System doesn't come back and say anything, because "Ron J Huber" and "Ron J. Huber" are different. $user->display_name = "Ron J Huber", $user->name = "ronjhuber1" (since there's already a ronjhuber)

Any other crazy use cases people come up with get handled by contrib.

Drupal attributes every post for a non-logged-in user to "Anonymous." I am looking for how to allow anonymous users to hand enter a name, so as to differentiate from each anonymous user. I don't want to require registration to everyone who posts a comment, but I want to require them to enter some name to distinguish posters. THis is desirable in some cases, and Wordpress supports this. But I see no easy way in Drupal to do this except by doing a lot of coding which is beyond my rudimentary php knowledge. Or am I missing something?

FWIW, I am working with Drupal 6.2

@mikeque please post a separate support request.

@webchick in #157:

Yes, we absolutely want everyone to have a unique display name.

Please state exactly who you are referring to when you say "we". Because you're not speaking for me, Senpai, kkaefer (#47) and all the other people that want to be able to display real names.

The usefulness of any system is proportional it's ability to model the real world. In the real world many people have real names that are the same. I want to be known as "Daniel Harris". Now, just because I got to some registration page first, I don't want to lock out all the other people called "Daniel Harris" from having a display name of "Daniel Harris" also. In the realms that I control that's the policy I'll choose.

I do NOT want another 'webchick' running around posting Nike ads.

On websites that you control as webadmin you can ensure that display names are unique. But please don't force me to run my websites like yours. I want users on my websites to be able to have their display name as their real name. In the real world, real names are not unique. Therefor Drupal must give me the option to have non-unique display names. Otherwise, it's usefulness to myself and many other website creators is diminished.

There is not one way to do something. We all have different ways we like to work. You must respect that. Just as I respect yours. Keep the options open and let people decide freely.

In summary, it is for the website creators to decide if display names are unique or non-unique on websites that they create and not for us, as Drupal developers, to dictate one way or the other. It is our role to provide functionality and flexibility to enable those website creators to build the sites they want.

Let's be clear here. We are not deciding policy for drupal.org but deciding functionality for Drupal 7. I'm sure a committee will debate long and hard on whether to have display names that are unique or non-unique on drupal.org. I'm not interested in that debate. I'm only interested that they have the option and freedom to decide for themselves and not be forced into a particular way of working as a result of our work here on the display name in core patch.

@Senpai: You're doing great work. Please ensure that the webadmin option for display names to be unique or non-unique remains in the patch.

Cheers Daniel

Ok. Then #159 + one checkbox that, if checked, removes the validation on username on signup. I still don't understand why this got so complicated.

If:

1) Display name is the only field that non-admins ever get to see;
2) Display name is not unique;

Then:

3) It is possible for someone to masquerade as another user by just setting the same display name, and it is then impossible for non-admins to tell the difference.

That is a security hole. +1 to unique display names. -1 to security holes.

I don't understand how this got so complicated either. Adding a login name field to Drupal and a mechanism for swappable display name-setting engines should not be this difficult.

1. User A signs up to site, enters "Ron Huber" as their name. "Ron Huber" gets stored as $user->display_name, "ronhuber" gets stored as $user->name.

How about even simpler, "Ron Huber" get stored as both the display name and the login name?
A custom transformation like "Ron Huber" to "ronhuber" is one of those "crazy use cases" that can be handled by contrib. I'm all for keeping core as simple as possible.

Personally, I plan to allow duplicate display names and use email address as the login name.

At the risk of repeating myself, I still think this could be done simplest this way:

The current username field becomes display name, and is used in theme_user_name() whatever the setting.

A login-name field is added, which is a lowercased version of the username (to save LOWER() queries per: http://drupal.org/node/83738)

By default, login-name is populated automatically from registration and user/edit forms via a single 'user name' field.

When display names are enabled in core, the only difference is you get to set the value of these fields manually via the UI (although login-name would still be forced to lower case). We already have something in both fields whatever happens. In fact you could even not have this setting in core if it's going to complicate things.

Additionally, contrib could populate the display name field in other ways (like auto node title or similar).

If you were to disable display names on a live site, you'd get a warning that all existing display names would be wiped and replaced with login-name. To save people's usernames going from John to John Smith to john we might need to store an 'as typed' username in a third field (maybe even seperate table since this would rarely be accessed) - this could be used to display user names to their owners as well if desired so the lowercasing would be completely transparent.

Admin gets the following options:

Enable display names []
The permission for 'change own username' is split into change username and change login name - or not if we wanted a fixed and immutable login name (in which case it'd stay the same).
Unique display names are on by default, non-unique is either an option, or in contrib along with other weird and wonderful ways of populating that field.

@Dave: I want $user->name to always be lowercase so that we can address this critical performance bug as part of this patch: #83738: LOWER(name) queries perform badly; add column name_lower and index. It also means that pathauto could use them in URLs like drupal.org/user/davecohen/edit without them being all ugly like drupal.org/user/Dave+Cohen/edit

I'm ambivalent about allowing users to edit $user->name. Personally, I wouldn't, at least in core. We don't let them edit their user ID, and $user->name is going to become the same: just an internal identifier for Drupal to find that user.

I really don't want this patch or this issue to be complicated at all. The debate right now is not about the validity of unique or non-unique displayed names, cause I've given us the option for either. The unique/non-unique will stay in the patch, cause it doesn't affect anything security wise, or user search ability. The search function will have to be improved if this patch gets in, however, or searches for "Ron Huber" will return six identical-looking results without the benefit of an attached username or userID. I.E., "Ron Huber (rhuber)" or "Ron Huber (user#342)"

The real debate, and apparently the last one we need to solve before this patch would be considered done, is how to enforce the request for "Make displayed names required for all site members". The problem is this. If I make the displayed_name field required on the user/123/edit form, anyone with 'administer users' permission will have to fill out that field before being able to successfully modify another user's account. There's only one form, it's just presented in different ways depending on whether you're an admin of users, a user editing their own account, or a new user registering for an account.

I can't see a good way to make a single form field required for 100% of users under the above three mentioned scenarios. I'm not allowed to substitute the username as the displayname, cause that's a potential security risk (in some people's eyes, but they might have big checkbooks) so I have to have something to put in there. If the field can't be blank, but an admin editing a user doesn't want to have to think up a displayname for every user they edit (which I admit would be tedious and borderline insanity-inducing) then what?

Gimme some ideas.

I'd like to see some response to Crell's #164 from the advocates for non-unique display names. Drupal has a reputation for being secure out of the box, and this change seems to actively work against that.

@catch in #166:

Admin gets the following options:

Enable display names []
If display names are enabled, force display names to be unique [] (checked by default)
The permission for 'change own username' is split into change username and change login name.

If we go this route, we 'll need a better naming convention. A username *is* what people use to login with. Example: "Please Login with your Username and Password". If we make $user->name into $user->displayname, and then add another field called $user->username, that'd be ok, right? Now, I'm not saying I'll run off and code this quite yet. So far, there's only two people advocating for the replacement of the traditional user->name field within core, and neither one of them has decision-making ability. OR should I say, committal-ability. (Is that even a word? Ah well, it is now, cause it's on the internets!)

@webchick in #169:

I'd like to see some response to Crell's #164 from the advocates for non-unique display names. Drupal has a reputation for being secure out of the box, and this change seems to actively work against that.

After I posted my #168 above that referenced the example of "The search function will have to be improved if this patch gets in, however, or searches for 'Ron Huber' will return six identical-looking results without the benefit of an attached username or userID. I.E., 'Ron Huber (rhuber)' or 'Ron Huber (user#342)'", I began to think about it a little more.

The way to fix this is to add the username to the themed output, but only if there's more than one of this particular displayname. Does that make sense? If a site only has one "Ron Huber" on it, you'll see the name exactly as that user typed it. If a site has more than one "Ron Huber", all instances of this displayname get an additional ($user->username) tacked onto the end of their displayname, so everyone will be able to tell them apart.

webchick's suggestion above where a login name could == "ronjhuber1" strikes me as quite wrong. If we go this route, and if display names are decoupled from login (or lower) name then the user *must* use the login name (or e-mail) to log in. Right? I don't think people will be confused by this - in my e-mail client, I set a username (return address) and a name that is displayed as well. The latter is a convenience, the former is the relevant, unique, identifier.

I'm basically in agreement with catch in #166

@pwolanin #171:

I'm basically in agreement with catch in #166

But Catch said in his #166 that "By default, login-name is populated automatically from registration and user/edit forms via a single 'user name' field.". What happens when I sign up to a site, type "Joel Farris" as my *name*, and the system converts that to a "joelfarris" silently and without my knowledge, then requires me to user "joelfarris" to get back into the site tomorrow?

I'd be typing "Joel Farris" six times, cause that's what I typed in yesterday, and I'd be requesting new passwords with Joel Farris as well. which would fail. What about the case where Angie types 'Angela Byron' into the "What's Your Name" field during registration, and then wants to login as 'webchick' tomorrow when she returns?

What I'm saying is that silently deducing the username from the displayname during registration earns a huuuuge -1 from me. We simply can't afford for core to be making decisions on behalf of users if it means those users could even possibly get confused, fringe case or not. Let's think up a better way of handling this scenario.

@Senpai - I agree with you on this point - yes: it needs to be totally clear to the user what their login name is. Thus, the login name is likely to have more restrictions on what characters can be used as opposed to the display name. I'm really not sure we should be stripping spaces, since that could potentially turn two currently unique usernames into colliding login names.

Senpai: in that case, Drupal uses the same method it used to convert Joel Farris to joelfarris when you log in, as it does to add the extra field to the database. So you can log in as joelfarris JOelfARRIS - same as now. pwolanin covered this earlier in the issue afaik.

As long as it's the same method, there's no problem. If you later change your display name (or whatever it's called), Drupal probably needs to have a copy of your original username somewhere to display back at you - otherwise some user data gets lost I think.

Or another option would be have the login-name prepopulated via javascript on user/register, either editable or not, and show the new version to the user. Thing is, if someone else has already registered catch, I might want catch56 instead of catch1 - in that instance - so probably both would need to be choosable at least on registration.

Agreed. Users need to see both fields during registration. That's why I opted to show the displayed_name field to registering users. the field is optional right now, but users will want to know that this functionality is possible, and if they see that they have a choice of picking different names, they might be able to set up their first account as 'Angela Byron' aka 'webchick' instead of having to create a second account once they figure out how the site works internally.

There's a thread, recently reactivated at: http://drupal.org/node/111317, which argues for using $user->mail for login.

There isn't any code there yet, and the original suggestion is for login toboggan like functionality.

I'm arguing for removing all authentication responsibility from $user->name and relying on $user->mail alone.

I think this would have a big impact on you folks focussing on display name. I think it would make your job lot easier.

Shai
content2zero

I think #172 is backward from what I am suggesting. By default, user enters their login name when signing up. That has various rules on it. That gets copied verbatim to ->name/display_name. That means that if you change no settings, you see no difference in behavior.

However, enable a user-editable textfield for display name and you fill that in separately. Or enable auto_username and fill in the display name automatically. Or populate it from LDAP automatically.

@Crell - do those rules include lowercasing the name? Because that'd be a change from current behaviour if so, and if not we loose the performance benefit.

I'd like to see some response to Crell's #164 from the advocates for non-unique display names.

What might be a security hole for one site is not for all sites. I think we'd all agree that Drupal should be able to (but not required to) emulate the Facebook model. By that I mean,

• Login using email and password.
• Non-unique display names. My display name is my real name.
• In many places where names appear, a photo also appears.
• The login name (email address) is never shown in place of the display name.

Right now, Drupal cannot do this because there are so many places where the logic which displays the user name cannot be overridden. For performance reasons, theme('username', ...) is not used in search results, views, etc. I believe anytime the user's name is rendered in any way, third party modules should have an opportunity to change the way it is tagged. For example, to add a photo. And I hope any fix for this issue includes such a mechanism.

@catch, Crell - obviously the login name would need to be stored as lowercase, while the (display) name would get stored as typed. In other words, step 1 of this is more-or-less just the basic performance patch of adding a column with the name already lowercased.

Quite frankly, I think core could possible stop there if the code was well-written to allow contrib modules to add a form field the could let the user enter a different (display) name, etc. SO, I'd like to see a clean and simple patch for this 1st step (including the update, etc) and from there we can argue about the other possible features.

This is the 181st comments on this thread, and consensus seems elusive.

In these issue queues many things are moving forward at the same time and some of them affect each other.

What I was trying to do in 177 is ask the question: would this issue (display names) become less complicated if authentication was tied solely to e-mail address?

I think the answer is yes. For one thing, @webchick's concerns about a performance hit when executing LOWER(name) would disappear. I think there would be a lot more flexibility around how different site admins implemented or didn't implement display names if the implementation were totally de-coupled from authentication.

I'm not looking to derail this issue. What I'm proposing in that other thread (http://drupal.org/node/111317) is certainly not guaranteed to go anywhere. But I do think it would be interesting to know, for the sake of argument, whether people concur that this issue (display names) would become easier to solve/implement in a simpler way with fewer ripples, if that proposal were adopted.

Shai
content2zero

@Shai - the simple answer is that in my option switching to ONLY e-mail for login is not a feasible solution, since many users (i.e. site admins) would be very unhappy if they updated their sites and none of their site members knew how to log in...

Obviously, allowing logins via e-mail is worth considering (and maybe we could also expand the new login name validation to allow @ and .) as an additional core feature.

I think we'd all agree that Drupal should be able to (but not required to) emulate the Facebook model.

If the Facebook model is insecure, then no, I don't want to emulate it.

I was thinking about this more last night, I think to make this a solid feature, we'd need to add two columns: lower_name (or name_lower) and login_name

We'd need lower_name so that we can have an indexed column to use when searching by display name (i.e. $user->name). Then, depending on site settings, login_name might or might not be the same as lower_name.

I agree with pwolanin's recent points. First that if core provides the improved data structure, it can be left to third party modules to provide a more advanced interface. And second forcing users to login with their email address is a bad idea, but allowing it is desireable (in my opinion, essential).

@Crell #184, I think you misunderstand me. I don't want you or anyone else to have to use the facebook model. But I want to be able to build a site that does, using Drupal.

Drupal developer...

@webchick in #152: I don't want to be forced to use a particular username on the sites that I administer. Please make it clear in future are you talking as a Drupal developer or as a Drupal webadmin?

Because in the case of you talking as the Drupal developer you've got to accept scenarios that are not what you would necessarily want to do on your own sites - so we need to have options to enable webadmins to set up the site as they see fit. And in the case of you talking as the Drupal webadmin, well, that's your choice and I hope that Drupal 7 gives you the option to do that.

Email...

@Dave Cohen in #165 and #186: "use email address as the login name" was mentioned by a number of people along the way of this issue and was captured in the wiki:
http://groups.drupal.org/node/11092

@Shai in #177 and 182: "which argues for using $user->mail for login" But it should be an option for a Drupal webadmin and not the ONLY way that Drupal works from hence forth.

I'm all for the option of slaving the login name off the validated email address field. I probably wouldn't use it in the sites that I run but I know a lot of sites that do use the email address as the login name so it would be good to have this as an option.

Security...

@webchick in #169: @Crell in #164: It is not "impossible for non-admins to tell the difference". All one simply needs to do is click on the user's link and go to their profile to see who they really are. So there's no issue of masquerading. And so this is no security hole. The user's username and numerical ID are both still and will always be unique and identifiable.

Also, Senpai has a suggestion about how search results are displayed in #170 but displaying a username/loginname should be an option as some webadmins would definitely not want these exposed for SECURITY reasons.

Non-uniqueness...

@catch in 166: "At the risk of repeating myself"... Yes you are but then we all are repeating ourselves, myself included. One of the reasons is that our questions are not being answered like mine at #156 (can you please answer it?) and so we go around in circles a bit.

"Unique display names are on by default, non-unique is either an option, or in contrib along with other weird and wonderful ways of populating that field."

I don't have a view on the technical solution you propose one way or the other. But your insinuation that non-unique display names are just one of the "weird and wonderful ways of populating that field" shows you're not really grasping the importance of the requirement here. The non-unique display name option must go in core. I have two major websites: one with 3000 and one with 30000 users. In both cases they have usernames (unique) and displaynames (non-unique) that are independent of each other and changeable by the user at any time. This is not a unique scenario on the web it's clear one of the reasons this issue was started was to satisfy this scenario.

If we want to increase Drupal's take up in the "CMS marketplace" then we've got to pander to these types of scenarios. And make it easy for webadmins to implement with the need to resort to hacking themes or contrib modules. Besides which, the unique/non-unique checkbox is ALREADY in the patch. ;-)

Decision-making...

@Senpai #170: "neither one of them has decision-making ability. OR should I say, committal-ability." That's a good point. We need to start engaging those that can get this patch in. Are there any of them tracking/commenting on this issue? Is there a list of 'em somewhere?

Usernames...

@Senpai and pwolanin at #170, #171 and #172: Agreed. usernames/loginnames must not be automatically derived from realnames/displaynames. Sure, usernames/loginnames can be suggested by some ajax magic but we shouldn't force the user to use a particular username.

Listen, the whole point here is to provide an open framework that webadmins can then come along and tailor to suit their website's needs. So, that means that we, as Drupal developers, don't restrict/dictate ways of working but give options and freedom. It's up to webadmins to restrict or reduce the options for their own websites as they see fit.

Facebook...

@Dave Cohen #180 and #186: Totally agree that Drupal should be able to emulate Facebook as an option for webadmins in the ways you suggest.

@Crell #184: "If the Facebook model is insecure, then no, I don't want to emulate it." You don't have to emulate it but don't stop me from doing so.

If we all stopped talking as webadmins and started talking as developers (or at least made it clear which role we were talking as when we talked) then all this stuff would become a lot clearer.

BTW I expect to be talking to Drupal developers on this issue/forum and not a bunch of "I want to do it only my way" webadmins.

Providing options and freedom are what we should be doing here. Granted, we need to be sensible and offer popular default scenarios too...

Looking at the actual username validation function (and testing), it *is* actually already fine to use an e-mail address as a username, so mark that off the list of things to do. If you recall, the drupal.module assigned usernames like killes@www.drop.org.

Also, found this function - which seems to be what we'd want to use in PHP so as to be certain we always have the same character set by passing the 2nd param: http://www.php.net/manual/en/function.mb-strtolower.php

The update function could use LOWER() and then we'd probably want to iterate through all the login/lower names to make sure they match mb_strtolower($display_name, "UTF-8") (or latin1, etc depending on what we choose as the standard) and then update any rows that don't match. That should be much less cpu-intensive than doing all the updates in PHP (though that's a possible option too).

I don't understand how this is unclear, but I'm talking as a Drupal developer. I don't want core catering to every single use case on the face of the planet: I want it to stay mean and lean. Core should cater to the 80% use case, and include flexible APIs so that the people who need the 20% use case can do so in contrib.

This patch could've been done and in core weeks ago if we had stuck to that simple rule. Instead, it's getting mired down in "my use case too"s which is the entire point of the contributions repository.

And going by the 80/20 rule, for 80% of sites, a "webchick" responding to a forum thread who is not user #24967 is a security hole. In order for it to NOT be a security hole, you need to also append additional data to the username, such as their picture, their full name, etc. so that it's immediately visible to regular end users that this other "webchick" person is not me.

So, if this patch provides a hook for contributed modules to utilize the display name in an interesting way, it would be trivial to whip up a "Facebook User" module in contrib, which provides this extra data next to user names whenever they're displayed, as well as other niceties such as logging in via e-mail address and so on, so that people don't need the distinction of a display name vs. user name on login to begin with.

And, as an extra added bonus, this patch could then one day be RTBC. :P

@pwolanin in #194: You say "an e-mail address as a username". For clarity are you talking about THE validated email address that each user has to use or are you just saying that any email address is fine - validated or not. I guess what I've always thought is this option would be like a pointer from the login name to the validated email address, yes?

@dahacouk - I'm am saying any e-mail address could be used. And per webchick above it's really not clear that this feature is *needed* in core, since it's possible with modules like Login Tobbogan

Can we please move everything connected to e-mail address logins over to #11317 which deals with that issue specifically?

I don't understand how this is unclear, but I'm talking as a Drupal developer. I don't want core catering to every single use case on the face of the planet: I want it to stay mean and lean. Core should cater to the 80% use case, and include flexible APIs so that the people who need the 20% use case can do so in contrib.

Amen to that! Have you seen how many people are hacking Drupal to make this work? It definitely in the 80%.

This patch could've been done and in core weeks ago if we had stuck to that simple rule. Instead, it's getting mired down in "my use case too"s which is the entire point of the contributions repository.

Actually it could have been done years ago but I agree too - and I believe Senpai's patch seems to be adhering to the spirit of the initial issue. But to be fair the first patch only came on May 9 after more than 16 months of pushing this issue.

And going by the 80/20 rule, for 80% of sites, a "webchick" responding to a forum thread who is not user #24967 is a security hole. In order for it to NOT be a security hole, you need to also append additional data to the username,

Eh? Surely, you mean "display name" not "username" here. If it was a username then it would be unique and so there'd only be one webchick - ;-) - and this situation wouldn't arise. And if it was a username being displayed, as is now the case in out-of-the-box Drupal websites, then the webadmin wouldn't care about this patch.

But in the case of you talking about a "display name" I totally agree on enabling webadmins to append additional data.

such as their picture, their full name, etc. so that it's immediately visible to regular end users that this other "webchick" person is not me.

Again, I don't see "full name" as a clarifier here because this whole "security hole" only comes into play when non-unique display names are being used. So, showing the real/display/full name twice wont help you much. But I agree with use of picture, location, whatever the webadmin likes, etc.

So, if this patch provides a hook for contributed modules to utilize the display name in an interesting way, it would be trivial to whip up a "Facebook User" module in contrib, which provides this extra data next to user names whenever they're displayed, as well as other niceties such as logging in via e-mail address and so on, so that people don't need the distinction of a display name vs. user name on login to begin with.

Oh, it was going so well but now I'm confused. You keep talking about usernames which is what we have now. As a webadmin I need the distinction between "display name vs. user name" on registration and hence when users login with their username (not their display name). As a developer I see that this is one of the main reasons that this issue started. Hence, I want to see a distinction. So, please clarify what you mean here. I believe we are almost there in terms of coming to an understanding. For instance, if there isn't a distinction between "display name vs. user name" then what are we doing with this patch? I'm sure I've just misunderstood you so please clarify.

And, as an extra added bonus, this patch could then one day be RTBC. :P

Well, I'll drink to that! ;-)

s/username/the name that shows up next to all of a user's content/g;

I'm with webchick that core stay lean and mean. That's the Prime Directive. So say we all (I hope). Resistance is futile...

Toward that end, I'd be happy with a patch that changed none of core's default behavior and none of its UI. But that does add a lower cased loginname and/or a displayname field to the user's table. Then third party modules could use hook_form_alter and/or hook_user to work their magic.

Looking at the actual username validation function (and testing), it *is* actually already fine to use an e-mail address as a username...

But not in the real world, where you want to use email for logging in, but you don't want to show your user's emails to everyone else. You can try overriding theme('username', ...) to hide the email addresses, but they show up in search results, in views, in view titles where username is an argument, and so on.

It makes sense to me to use the users name column as the displayname and add a column called login, which by default is LOWER(name).

@Dave: Yes. That's exactly what I proposed a hundred posts ago or so. :-) With the caveat of "Display name should be unique" (at the very least in the default configuration, if not in the database) and a reliable way to plug into that process and change it.

From my work on auto_username, I can tell yo that right now hook_user is not up to the task in any way shape or form. c.f.: #254422: Using old data for tokens

Lean and mean...

#201 Dave Cohen - May 21, 2008 - 17:10
I'm with webchick that core stay lean and mean. That's the Prime Directive. So say we all (I hope). Resistance is futile...

In this case I'll count myself in the "we". I agree: lean and mean core.

Toward that end, I'd be happy with a patch that changed none of core's default behavior and none of its UI. But that does add a lower cased loginname and/or a displayname field to the user's table. Then third party modules could use hook_form_alter and/or hook_user to work their magic.

Fine. That'd be a good thing to do. But then that's a different issue or only part of this issue. This issue was started by sparr because he saw a need to put in place the UI elements in core.

TBH if a picture and signature are in core then display name has got to be too.

But not in the real world, where you want to use email for logging in, but you don't want to show your user's emails to everyone else. You can try overriding theme('username', ...) to hide the email addresses, but they show up in search results, in views, in view titles where username is an argument, and so on.

Exactly, and that's the problem that webadmins are hitting all the time when they try and hack Drupal to displaying real names and not login names.

It makes sense to me to use the users name column as the displayname and add a column called login, which by default is LOWER(name).

I'm only in agreement with that so long as the non-unique display name option goes into core too - as is currently the case with Senpai's patch.

#202 Crell - May 21, 2008 - 20:35
@Dave: Yes. That's exactly what I proposed a hundred posts ago or so. :-) With the caveat of "Display name should be unique" (at the very least in the default configuration, if not in the database) and a reliable way to plug into that process and change it.

Sorry to repeat myself: I'm only in agreement with that so long as the non-unique display name option goes into core too - as is currently the case with Senpai's patch.

The way forward...

Please answer this: Is there a formal policy for what should and should not go in core?

If there isn't then perhaps it's about time that something was written up - or at least some guidelines, eh? It would help in discussions like this.

Another thing that would really help this process of patch work is to make it more formal. I was trying to do that in creating the wiki page - http://groups.drupal.org/node/11092 - but it hasn't really got used.

Using documents would stop the need for us to keep repeating ourselves and they would also give us a clear understanding of what we are trying to do. I'm sure we all develop code using requirements, specifications, dependencies, etc. So why not here?

Much of the confusion is also coming from discussing UI, database and code in the same breath. It's getting all mixed up but it should be de-coupled and layered.

As I see it there are three ways forward.

1. Back Senpai's patch and work collectively to make it work.
2. Collectively build a formal requirements specification for the UI, database and code levels to satisfy the spirit of this issue. And commit to coding those levels within a decent time frame.
3. Go round in endless repetitive circles till we are all too exhausted to complete the issue.

I'm happy with options 1 or 2 but not 3.

What do you want?

For the record, I'm a UI man. I'm not a code man. I know there are passionate people here that care about the code and will make it beautiful. That's good enough for me. My purpose is to see the UI beautiful, simple and functional. Unless, I see the code expressed as UI then I don't have a view and my requirements (as a Drupal developer) are not met. Hence, I'm always going to bang on about functionality in the UI.

Changed the patch to reflect Dmitri's recommendations in Patch Review #155. It turns out that $sitecreator = uid1 was something that used to be necessary to prevent uid1 from seeing the displayname field while creating additional users. Once I got the form elements into their proper places within core, this check was no longer needed and was simply a leftover.

Thanks DmitriG for the heads-up.

How to test this patch

The way to test this new field is to visit admin/user/settings, and take a look at the options within the Displayed Name fieldset. Once Displayed Name is enabled, other settings become available. The site admin can elect to allow/prevent the displayed names from being edited by mere mortals, set a maximum length for the name, and even enforce a unique displayed name for each user.

Once you've turned on Displayed Names and are familiar with the settings, and go edit your own profile. You'll see a new, non-required field that's automatically defaulting to your current username, regardless of whether or not you have access to edit your own username. (I chose not to automatically store everyone's username as their displayname during the D7 upgrade process for the simple reason that several people have expressed the desire to hide usernames whenever possible for corporate security reasons). Anyone who edits their profile is very likely to store a displayname for themselves, because even though the field is not required, it's #default_value *is* the username, and therefore we've given the user a choice to create one or use the current default. If a user has never visited their profile before, and therefore has no displayname, the patch presumes to use the admin-defined token text that's been set within admin/user/settings in place of that particular user's displayname.

When a user creates a node or a comment, their displayname will show if they've saved one. If they've never edited their profile before, and they are viewing a node or comment that they own (created), a call-to-action link is present to allow them to change the site wide admin-selected text of their displayname to something that they like.

Critique....

First some things I hope most agree on...

• theme_username($object, $displayname = FALSE, $truncate = TRUE, $length = 20) takes too many parameters. We just got through changing l() and url() for the same reason. Let's make it theme_username($object, $options = array()).
• $options should have keys like 'displayname' (TRUE or FALSE), 'truncate' (FALSE or positive integer), 'link' (TRUE or FALSE), ...
• default value for $options['truncate'] should be FALSE, or come from theme settings. (The folks concerned about "spoofing" will need a way to disable this.)
• default value for $options['displayname'] should be TRUE, or come from theme settings.
• theme_username() should accept a string as the $object. If a string, $options['link'] is ignored and the output is never a link. This way, themes can still override the display of a username in places where it is not a link, for example the title of a page.

And personal opinion that only some may agree with, but anyway...

• I'd rather $user->name remain the display name. Add $user->login instead of $user->displayed_name.
• By default, $user->name remains "what they typed" while $user->login is that string lower cased.
• The changes to forms and UI should be in a contrib module.

I'd be in favor of this patch if it addressed the latter list. And way in favor if it addressed the former.

Dave Cohen said:
First some things I hope most agree on...
1. theme_username($object, $displayname = FALSE, $truncate = TRUE, $length = 20) takes too many parameters. We just got through changing l() and url() for the same reason. Let's make it theme_username($object, $options = array()).

RE #1, I agree that l() and url() should be as short as possible, because they are programming functions. The theme_username() function is for themers, and as such, it should be as easy to understand as possible. At first glance. Without having to really understand a lot of PHP constructs. I initially wrote this theme function with an options array, but then I remembered my first experiences with trying to design and theme things in Drupal and how hard it was to grok. That's why I decided that copying a theme function out of core and pasting it into a template.php file in order to override it should not require complex programming knowledge. Thus, the arguments are left as easy-to-understand as possible. If I needed any more fodder for this barn dance, I'd paste in a link to someone else who represents the vast majority of users who're just trying to get things done inside of Drupal. While we don't have to offer themers the ability to truncate or not to truncate (which was never a possibility until I wrote this patch), or the ability to adjust the length of their truncated user names (again, not possible until this patch was created), I feel that offering this capability to themers from within core as a paste-able, over-ridable theme function was paramount to increasing the capabilities of themers around the globe. I remember when I started theming, and that's why I chose to do it this way. The suggestion you've made in point #1 is great, yet it doesn't take into account all the people who might have to try and make this theme function work in real life. Since there's really way to make the function any leaner and meaner without stealing people's ability to understand what it's trying to do, I say we leave it like it is with four easily-grokked parameters.

Dave Cohen said:
2. $options should have keys like 'displayname' (TRUE or FALSE), 'truncate' (FALSE or positive integer), 'link' (TRUE or FALSE), ...

RE #2, I think I addressed #2 in my above statement about #1, since all you're doing is suggesting a formalization of the naming convention for the options() array, which I purposefully left out of the patch.

Dave Cohen said:
3. default value for $options['truncate'] should be FALSE, or come from theme settings. (The folks concerned about "spoofing" will need a way to disable this.)

RE #3, the way theme_username handled things before I patched it was to automatically truncate the name to a preset length in order to avoid breaking tables in the admin pages. I'm offering themers the ability to either truncate or not, depending on if they've built a special theme for their admin pages, or maybe they have a liquid layout that adapt to extra-long names. Can't we keep it as TRUE because that's what core used to do, and then allow it to be overridden if so desired?

Dave Cohen said:
4. default value for $options['displayname'] should be TRUE, or come from theme settings.

RE #4, if $displayname defaults to true, all the admin pages which show usernames will become displaynames. I don't think that's conducive to site administration when non-unique displaynames are in play. However, I could be convinced to adapt this philosophy should someone have constructive feedback about my thoughts in http://drupal.org/node/102679#comment-835521 and also in http://drupal.org/node/102679#comment-849528. I just don't see the point in forcing all site admins on all Drupal sites to see dispaynames rather than usernames when attempting to block, edit, or even delete a user account. what if there were two identical displaynames, and the site admin assumes incorrectly when deleting a user account?

Dave Cohen said:
5. theme_username() should accept a string as the $object. If a string, $options['link'] is ignored and the output is never a link. This way, themes can still override the display of a username in places where it is not a link, for example the title of a page.

RE #5, I totally don't get what you're aiming for here. Is there something that core used to do that I've left behind somehow? Please expound. AFAIK, the only three things that get passed to this function as an $object are a $user, a $node, or a $comment.

To all the people who advocate keeping the existing $user->name, and making a new field for identifying the user during login, please comment on what these two fields should be called. We can't use $user->login to store the user's username, because a login consists of a username and a password. We login to a site using our username and our password. We don't login to a site using our login and our password. "login" is a verb, and implies an action of supplying two pieces of credentialed information that must match before access is granted.

Since nobody seems to like what I've done so far, and keeps +1ing the concept of making $user->name into the displayed_name, please dialog about what these two fields should be called in the core code so as not to induce confusion down the line.

Standby... and Go.

I agree that l() and url() should be as short as possible, because they are programming functions. The theme_username() function is for themers, and as such, it should be as easy to understand as possible.

I might agree with you, if there were some consensus as to what the options to theme('username') should be. Which, I'm pretty sure, there isn't. Moshe recently suggested to the devel list that theme('username') become more like what facebook offers: complex options like 'useyou' where the username becomes 'you' when referring to you, but a full name when refering to someone else. I suggested a link option, to suppress making the username a link. And when you say 'no it's more important to keep things simple for theme developers', you're also saying 'no the option you desire will never be part of the API, unless you can push through a patch to core to have it appended to the end of an ever-growing list of parameters'.
I don't care that every theme support the link option or useyou option. I just want to be able to create a theme that does, if I so desire.

the way theme_username handled things before I patched it was to automatically truncate the name to a preset length

Ah, I did not realize. Interesting to know that the spoofing vulnerability is built into core already.

if $displayname defaults to true, all the admin pages which show usernames will become displaynames

There are a limited number of these admin pages provided by core and all of them can be easily changed to unset the displayname option. There are umpteen jillion contrib modules that call theme(username) and unless you patch them all to set the displayname option, you've effectively rendered the displayname useless. That is, if I use email as the login name, people's email would be showing up all over the place unless I go and tweak every call to theme('username').

I totally don't get what you're aiming for here

There are numerous places where user's names are displayed, but there is no $user, $node, or $comment handy. Examples include search results and page titles. I'm suggesting that theme('username') accept a string, so that a theme can still customize the display even in those cases. Basically, I want to be able to customize the way names appear in search results. Right now $user->name is simply written to the screen and instead I want theme('username') or theme(some_other_hook) to be called in those cases.

Basically, I think no displayname feature is complete if search results still display the login name.

To all the people who advocate keeping the existing $user->name, and making a new field for identifying the user during login, please comment on what these two fields should be called.

I want to make $user->name the display name because there are many places where it is written to output unmodified. As I've said, search results, and also views arguments and who knows where else. So, if we use that column to store the name as it should appear, there's less code to change.

I think $user->login would be an ideal name for the login name, but unfortunately its already used to store the last login time. So I'll suggest "loginname", or "ident"

You point out that 'login' is a verb, but many people also consider it a noun meaning exactly what we're talking about here, including the top results when asking google: http://www.google.com/search?q=define%3A+login&ie=UTF-8&oe=UTF-8

I agree - $user->name must stay as the displayed name. I think the 2 new columns should be (preferably) $user->name_lower and $user->name_login or less preferably $user->lower_name and $user->login_name

unsubscribe

@Crell, Dave Cohen, Senpai, pwolanin: If $user->name stays as the displayed name then can it ever be non-unique? Can the logic/filter behind the input of $user->name be updated to accept non-unique values if the webadmin has configured the site to accept non-unique values by clicking the appropriate checkbox in the admin section.

@Senpai: You can have UI logic already in the patch. Can non-unique values for display names survive in the patch when moved to using $user->name?

@dahacouk: Duplicate display names is a security hole. Always. Period. If Facebook allows it, then Facebook is insecure. Period.

Allowing the insecure option of duplicate names is rare enough that I am more than happy to kick that off to theme_username as now. It should take actual effort to make a site insecure, not just flipping a radio button. Let's stay focused on the actual issue (he says in comment #216, which means this issue is probably doomed).

@Crell: The whole point of this patch request was to enable Drupal webadmins to configure their own sites to cope with real names. Real names ARE non-unique. Always. Period. End of story. Get used to it.

If you don't enable webadmins to make up their own mind then you are being a dictatorial developer. And that flies in the face of what Dries said in Boston: "get out of the way".

I understand your desire to protect us. And I'm warmed by it. But the truth is that webadmins are hacking Drupal to allow non-unique display names so that they can cope with real names - the real world. Isn't it best that we do this for them in the best possible and most consistent way?

Drupal must be able to handle real world scenarios. The real world isn't pretty. It's dirty. But it's the real world and we need to interact with it, deal with it, invoice it and connect with it. If I have 2 clients with the same real name then I want them to be listed as such. Sure they'll have a different ID each.

Address Books in all OS's allow people to have the same real name. Why not Drupal? Why cripple Drupal to only work for unique names? I don't understand the logic here.

Besides which I really don't see how this is a security issue. Identity theft? Please explain in detail and also answer why Drupal should not be able to map to the real world.

See webchick's comments in #195.

From a practical standpoint, non-unique usernames is an edge case, or should be. Kick it to theme_username, which remains an option for fringe cases.

If $user->name stays as the displayed name then can it ever be non-unique?

Both the logic of user.module and the schema of the users table has to change, neither is difficult to do.

I am more than happy to kick that off to theme_username as now

I have tried hard to do this by overriding theme_username and that solution is no good. Not only are there too many places that write out $obj->name directly (without using theme_username), but also it adds a lot of extra queries to some page displays (for example a thread with comments by 50 different people could lead to 50 additional queries to learn display names, as things stand now). Bad performance is a problem. Always. Period. If Drupal provides no alternative, then Drupal is a problem. Period.

I believe this approach is on the right track to solve this problem. More specifically, my comment #46 of that thread. I would put together a patch to that effect if I get some indication that it might be applied to Drupal 7 (and in my ideal world, Drupal 6).

@Dave Cohen: Go for it. I'm not getting any more reviews on my patch, and I'm not about to refactor 100% of it based upon the non-consensus in this thread so far.

Just in case we don't resolve this issue by the time Drupalcon Szeged 2008 come around, I've submitted a BoF where we can knock this issue on the head in the code sprint!...

http://szeged2008.drupalcon.org/sessions/add-a-display-name-field-core-a...

Please let me know if you have any comments on the BoF so I can update the description if needs be.

@webchick, Crell or anyone-who's-made-input-here-and-is-going-to-Szeged: If you want to be added as a co-presenter then let me know.

All that said it would be great to get some movement beforehand on the current patch.

Cheers Daniel

Wow, awesome idea! I wish I was going, just so I could hear Crell try to explain how two different users who are both known in the real world and the online world as Larry Garfield could possibly hack each other's accounts or something like that.

(Crell, I'm just teasin'. Don't be mad.)

Here's my take on this, for the BoF. Non-unique nicknames are a reality, and they are in no way a security risk. Possibly, and I mean really on the fringe of probability scale, non-unique nicknames are an annoyance. An annoyance at best, and easily dealt with by admins who have access to both the real name & the username.

Let's get this patch into core so I, you, and everyone else who has to overcome this Drupal shortcoming on a weekly basis can stop hacking around it in our own little way and all of us can get back to debating the best image handling methods. Ok?

Hello. My name is Joel. I enjoy collecting plastic lawn flamingos and dancing with them to the Spice Girls when no one's looking. Furthermore, all of the Drupal contributors, particularly Dries and chx, can kiss my big red patootie. Also? Your mom.

---

This is webchick, trying to prove a point here. :P I put an upside down exclamation point in place of the "i" in Senpai which in certain fonts, such as Verdana, looks pretty darn identical. Now imagine the fun I can have when I can literally just type "Senpai" in my Display name field and go to town, hmmm?

Yeah I just had to hack up the core blog.module file (plus override theme_username) so that our academic site would display real names instead of usernames all over the place. There are online communities out there in which real names (or display names) are much much preferable to displaying only usernames.

Please add this feature, if not backport it since most of us are still using drupal 5.

This is such a pain, especially if you might be using profile fields or else the bio module or node_profile or content_profile, etc. Just make user profiles nodes, and standardize a 'display name' or 'full name' or 'real name' (name it anything) field.

dugh. If you'd like this feature in Drupal 7, please test the patch that's here for review and report back. http://drupal.org/patch

@webchick in #223: I see the point you're trying to make, and it's valid, sure, but it's not a security issue. It's a bullying, imbecilic, childish, schoolyard prankster problem, and there are plenty of other contrib modules already set up to handle this sort of content contributor problem.

The way I see it, what you've just demonstrated is no better or worse than someone posting d3ath threats against the pres!de_nt of a country. The user must be dealt with in the same manner, and it's up to the site admins to crush their account into shards and keelhaul their ass for masquerading as another user. After all, with this proposed patch (concept, that is), we'd have two users with the same nickname trying to pretend they were each other. Only one of them is going to show up on the /admin/user/user page as Senpai (senpai). The other one is going to show up as Senpai (webchick).

Thus, there really isn't a problem with the concept of allowing an admin to allow non-unique usernames. Drupal.org isn't going to do it, and I'm sure I wouldn't turn this feature on within my own site, but let's face it. There are a lot of public, education, community service, and/or political sites that really have to have this feature and they go hacking around ten ways from Sunday to get it.

Let's give it to them in a manner that we control, and that's safe for them when upgrade time hits.

@webchick in #223: That's very clever and I was fooled for the first paragraph, I must admit. But...

1. You have used an identity masquerade "exploit" on a Drupal site where the login/username (and display name) is unique. Hence, this doesn't test problems on sites where the login is unique and the display name is non-unique.

2. The fact that this exploit can be carried out on a site where the login/username (and display name) is unique means that moving to a scenario where the login is unique and the display name is non-unique doesn't alter the risk of this particular case happening. In fact it may even be better as we will know that display names can be non-unique and hence be aware of the issue.

3. There is also user expectation that needs to be taken into account. If I am running or using a site where the login/username (and display name) is unique then I wouldn't expect to see the kind of exploit you have used and so as admin and user I wouldn't plan for it - as is the case with groups.drupal.org.

But in the case of a site where I expect the display name to be peoples' real name and hence non-unique then admins and users will expect duplicate real names to turn up now and again and wont rely on just looking at the name to absolutely identify a given author - they will click through to establish the identity.

4. On the websites that I run I've had no problems with even simple identity masquerading or any spam for that matter. I require the email address to be validated and that alone seems to get rid of jokers.

5. More than any of this webchick, once again, I fully respect and support your desire to run websites that you control with unique display names. I do this because I believe you know what you are doing and I respect that. All I ask is that you grant me the same in return. If you admin groups.drupal.org and www.drupal.org and decide that all display names should be unique then I respect that.

But I run www.kendra.org.uk (with 2500+ users) and www.freewheelers.co.uk (with 27000+ users) and I would like you to trust that I know what I am doing and fully respect my desire to run my websites as I see fit with non-unique display names. Can you do that for me?

There are lots of people that would like to be able to do this and so we need to trust that they know what they are doing too. Can we do this for them too? And seeing that there are so many it'd be nice if this was in core for them.

Cheers Daniel

But in the case of a site where I expect the display name to be peoples' real name and hence non-unique then admins and users will expect duplicate real names to turn up now and again and wont rely on just looking at the name to absolutely identify a given author - they will click through to establish the identity.

I don't believe this is a realistic expectation at all. If I'm on Facebook, viewing a conversation between "Paul Smith" and "Susan Smith," and a "Susan Smith" responds with the same name and the same user picture, I am going to assume that that person is the same Susan Smith. I'm not going to click on the username of every single reply of every single thread on the entire site to view profile details in order to verify the User ID of the people in the conversation. Let's be serious here.

Also, note that I stopped short of duplicating all of Senpai's profile details in Senpa¡'s profile (Senpa¡'s name is "(not) Joel Farris"). I could easily have done that, and not said something so ridiculous, and no one but Senpai himself (if he happened across this thread) would know that his identity had just been stolen. And now imagine the fun if someone used "Dr¡es" to do the same thing. ;)

4. On the websites that I run I've had no problems with even simple identity masquerading or any spam for that matter. I require the email address to be validated and that alone seems to get rid of jokers.

Do any of your websites have forums or have any traffic outside of a specific niche? This type of trolling has been a problem on every single community site I've ever been a part of. It's *definitely* a problem on any sizable website. *.drupal.org, MTV UK, and the Sony BMG artist sites, to name some prominent examples, are all sites I've worked on where this has been an issue that required dealing with.

But I run www.kendra.org.uk (with 2500+ users) and www.freewheelers.co.uk (with 27000+ users) and I would like you to trust that I know what I am doing and fully respect my desire to run my websites as I see fit with non-unique display names. Can you do that for me?

I fully support this desire, but not in core. As I already stated, the solution to this problem is for core to do what's right for 90% of sites, while providing APIs so that someone can create a module that makes user display names non-unique. It would be foolish for core to hard-code the behaviour that makes sense for 90% of sites so that was your only option. But it would be equally foolish to ship core with options that make this sort of "identity theft" hole so easily exploitable in a CMS that is known for its thorough attention to security.

A modest proposal…

So one solution to make display_name more secure by default is to 1.) make it unique, 2.) set it to "username [userid]" by default, and 3.) have theme_username() should spit out something like "JohnAlbin [32095]". I've seen other forum software use this technique.

It would also make sense to have a toggle in core to show/hide the userid. Does core need a "display name" field on the user forms? I don't think it does; leave that to contrib.

Then contrib modules or theme developers can alter the display of display_name to whatever they want. REMEMBER, we're also trying to make theme_username() more useful, too.

So here's how I imagine the workflow:

1. Core does not have a "display name" field on the user forms.
2. user_save looks for a display_name field. If it doesn't see one, it uses "username". Contrib modules will use FAPI on the user forms to allow their custom "display name" fields. If you want to go nuts here and have separate fields for first and last name, store the parts in your own table, just make sure to pass display_name on to user_save.
3. Before saving to the database, user_save appends " [userid]" to display_name, ensuring uniqueness. This also means that auto-complete will still give unique results even when contrib wants non-unique display names. :-)
4. theme_username will check core's hide/show userid variable and strip off the userid when appropriate.

Since all of the grunt work is done at the user form level, theme_username doesn't need to do any heavy SQL work.

Lean and mean, no?

Now there could be issues if multiple modules are trying to mangle the display name, but either module developers need to work on operability or site admins should use just 1 module. Let core stay out of the fray.

I await the next 200 comments on why this won't work. :-p

If we concatenate uid to display_name, then how does the toggle to display it or not work?

Sounds reasonable though. I'll say again - it'd be nice to fix the performance issues from using LOWER() here too.

If we concatenate uid to display_name, then how does the toggle to display it or not work?

String manipulation using a combo of strrpos (on ' [') and substr.

I'll say again - it'd be nice to fix the performance issues from using LOWER() here too.

If we store the capitalized version of username in display_name and a lowercase version in username that would fix the LOWER() issue. If a contrib modified the display_name, then we would lose the capitalized version of username, but since we wouldn't be displaying the username anymore, would it matter? [Implementation note: in order to display the capitalized username in the user forms, we would need to compare lowercase display_name with username before displaying display_name as username in the forms.]

@JohnAlbin: both seem reasonable to me. I don't think it's a showstopper to lose the variable case username in some rare cases of various contrib module combinations.

@webchick in #228:

I don't believe this is a realistic expectation at all. If I'm on Facebook, viewing a conversation between "Paul Smith" and "Susan Smith," and a "Susan Smith" responds with the same name and the same user picture, I am going to assume that that person is the same Susan Smith. I'm not going to click on the username of every single reply of every single thread on the entire site to view profile details in order to verify the User ID of the people in the conversation. Let's be serious here.

True enough. So, you're saying Facebook is wrong? And that we shouldn't be able to easily (without contrib modules or hacking) use Drupal 7 to build a Facebook like site?

Also, note that I stopped short of duplicating all of Senpai's profile details in Senpa¡'s profile (Senpa¡'s name is "(not) Joel Farris"). I could easily have done that, and not said something so ridiculous, and no one but Senpai himself (if he happened across this thread) would know that his identity had just been stolen. And now imagine the fun if someone used "Dr¡es" to do the same thing. ;)

Yes, I see, but you did all this on the current groups.drupal.org. You did this on a site that has a unique display name. So, I really don't see how this backs up your argument at all.

Do any of your websites have forums or have any traffic outside of a specific niche? This type of trolling has been a problem on every single community site I've ever been a part of. It's *definitely* a problem on any sizable website. *.drupal.org, MTV UK, and the Sony BMG artist sites, to name some prominent examples, are all sites I've worked on where this has been an issue that required dealing with.

I have email discussion lists and I will be moving to forums too. But trolling is not a problem for my sites. So, I am happy to have non-unique display names. It's my call.

I fully support this desire, but not in core. As I already stated, the solution to this problem is for core to do what's right for 90% of sites, while providing APIs so that someone can create a module that makes user display names non-unique.

Is that an official position? If so, where is it documented? I've asked this before: what is the official criteria for what goes in core?

And you're saying "what's right" here. That sounds like you know best. I mean better than the people actually running the sites. Shouldn't it be "...is for core to do what 90% of sites want to do, while..."? And in this case I reckon it's more than 10% of admins that want to have non-unique display names in core.

And is 90% the correct tipping point?

It would be foolish for core to hard-code the behaviour that makes sense for 90% of sites so that was your only option.

Exactly! But this is what you are intent on doing. And I don't feel that the 90% figure is correct in this case. But it's just a feeling.

But it would be equally foolish to ship core with options that make this sort of "identity theft" hole so easily exploitable in a CMS that is known for its thorough attention to security.

Firstly, the hole is already there in the current Drupal! You showed it to us!

Secondly, where do you get the statistic that 90% of sites don't want non-unique display names given the choice and given that it was easy to turn on? Has a poll ever been taken? Has there been a study? Or is it just a feeling?

Thirdly, what I really don't understand about your argument is that this kind of "identity theft" exists really easily on every current out-of-the-box Drupal website (that has a unique name for login/user/display) where you (or I or any of us) have not already registered. So, what are we gonna do about that, eh? "Identity theft" is a legal issue not a security issue as Senpai says.

The point is that there are loads of options an admin can set on their current Drupal powered website that'll mean they get loads of junk posts or open them up to security issues. As Senpai says:

There are a lot of public, education, community service, and/or political sites that really have to have this feature and they go hacking around ten ways from Sunday to get it.

Let's give it to them in a manner that we control, and that's safe for them when upgrade time hits.

Forcing unique display names on us is not a surefire way of stopping people from registering with false identities and so I don't see the point of not allowing non-unique display names in core.

Cheers Daniel

I'm speaking based on my experience of what I've observed, having put thousands of hours into the past 3 Drupal releases. I doubt any formal criteria for what gets into core is documented anywhere, because to some extent it's going to vary from release to release based on who the chosen maintainer is (and Drupal 7 doesn't have one yet). It also varies from patch to patch.

The general trend, however, is towards core doing the default behaviour that "the majority" :P of the sites will expect out of the box, and providing APIs for easy extension. Lots of sites want ratings on all of their content. Lots of sites want a terms of service agreement on their user registration page. Core doesn't provide these things natively (since there are many possible ways you'd want to add ratings to content, and display the terms of service), but instead provides an API so you can install Fivestar module or Terms of Use module.

I was able to circumvent the unique display name requirement because I've been an admin on several community sites filled with teenagers, and have been exposed to many wonderfully creative ways that they have of causing mischief. ;) If it becomes a field on the user profile that anyone can just fill out, then this suddenly becomes a much more serious problem.

The bottom line is that there's no way to have this feature "securely" without also appending additional information (at least user picture and user ID) to every post, or without having some mechanism in the profile system that prevents blatant copy/paste of fields (friends list). That's how Facebook et al get away with this.

Each site is going to want their usernames showing different information, and have different profile data attached to their users. Core can't even count on user pictures being enabled, let alone having some sort of buddylist system installed. Therefore, core can't provide this feature securely on its own, so it should not be provided in core.

As I've said before, I believe the best approach to this problem is this issue.

-1 to appending [NNNN] or anything else to display names.
-1 to requiring display names to be unique in order for autocomplete to work.

-1 to threads with more than 200 comments.

;)

-1 to requiring display names to be unique in order for autocomplete to work.

Drupal currently uses unique usernames in autocomplete. If Drupal has a display name field in core, autocomplete should be using that; otherwise its a usability nightmare for admins.

-1 to appending [NNNN] or anything else to display names.

And as I said the [NNN] can be toggled on and off. So what does it matter that it is appended on the back end?

As I've said before, I believe the best approach to this problem is #188734: LOWER(name) queries perform badly; add fullname and restrict name as lowercase..

Good luck! :-)

199 to go.

Drupal currently uses unique usernames in autocomplete.

I'm in favor of autocomplete. I just don't want display names to have to be unique for it to work. The autocomplete code can do tricks like appending a uid after the name to disambiguate names - you don't have to make the uid part of the display name to do that. But please if I have javascript disabled don't force me to type the [NNN] part.

And as I said the [NNN] can be toggled on and off. So what does it matter that it is appended on the back end?

You suggested the [NNN] is always part of the display name, but you can optionally have it stripped out by theme('username'). There are places where usernames appear but theme('username') is not called. One example is when a uid is a views argument and the argument is written to a page title via '%1' substitution. Another is the user tab of the search results page.

Also if the display name has the uid appended, a query for a particular name would be slower ("SELECT ... WHERE display_name like 'Dave Cohen [%]'" is less efficient than "SELECT ... WHERE display_name = 'Dave Cohen'").

-1 to threads with more than 200 comments.

By this I meant that I find it annoying that I have to hit the next page link and scroll down to read new comments. The "new" link on the recent posts page does not work when an issue has too many comments.

But please if I have javascript disabled don't force me to type the [NNN] part.

If a site has 20 users with "John" as the display name, and you type "John" in the auto-complete field with js disabled… how is Drupal going to know which one you want? This is why you must type a unique value in those fields. Fortunately, the auto-complete js means you don't have to type the [userid] part in, you just select the one you want.

There are places where usernames appear but theme('username') is not called.

Yes, but that's because the current theme_username is awful. We're going to fix it so you can theme the display name with/without a link to profile and with/without trimming. Then it would be considered a bug for a module to user $user->name directly.

if the display name has the uid appended, a query for a particular name would be slower ("SELECT ... WHERE display_name like 'Dave Cohen [ %]'" is less efficient than "SELECT ... WHERE display_name = 'Dave Cohen'").

Drupal would never call "SELECT ... WHERE display_name like 'Dave Cohen [ %]'". x-p That's a horrible query; MySQL couldn't use any of the indexes. That's why autocomplete (for example) uses "SELECT ... WHERE display_name like 'Dave Cohen%'" which is perfectly efficient.

198 bottles of beer on the wall…

Should the session at Drupalcon be a BoF or one of the other types of sessions?

http://szeged2008.drupalcon.org/sessions/add-a-display-name-field-core-a...

The other likely options are:

- Drupal core, contributions and trends
- Code development

What do people think?

A BoF doesn't get put in the programme so I'm thinking one of the other options will better market attract people to the session.

Cheers Daniel

If a site has 20 users with "John" as the display name, and you type "John" in the auto-complete field with js disabled… how is Drupal going to know which one you want?

How is anyone going to know which one they want. If I already know someone's uid, I don't need to search for them in the first place.

I don't see why uid couldn't be taken from the {user} table and appended to usernames as an option in theme_username - it'd be useful for some situations, but no need to alter user data on entry.

Non-unique usernames should stay in contrib, and that module can provide it's own autocomplete, IMO.

@webchick in #234:

OK. Reluctant though I am to only have unique display names in core, what you say all makes sense. So, in that case I/we need to push for a fully featured display name API that can makes it really easy to switch on non-unique display names in a way that is flexible yet structured.

My concern here is that the further non-unique display names are from the core the more modules will be written to add in the feature - perhaps leading to less common (more diverse) methods/structure for how one implements non-unique display names (in other words a mess).

So, the more functionality that can be put in the API (but just not yet switched on) the better in terms of standard practice so that there'll be commonly understood methods for implementing this.

I haven't got the technical language here but do you get my drift?

Is the BoF the best way to get detail into these ideas and implement?

Cheers Daniel

Well, those amazing folks in Szeged have added voting to the BoFs so if you are interested in attending the great Add a Display Name field to core BoF ( ;-) then add your vote and we can get an idea of numbers and get the best fit room size.

Cheers Daniel

Would it be possible to get a version of this patch that would work with Drupal 6.x? That would be extremely useful!

Personally, I just want to be able to do sensible things like have a title for the blogs of my bloggers other than "dbabbage's blog" in my Drupal 6 site—this whole thing is too freaking complex. I can see the icy purity of webchick's view. However, even ignoring the issue of people with the same name, real people are usually identified by at least a first and last name, separated by a space, and with capital letters—hardly ideal material for unique usernames.

The point is not what you should include in core. The point is that computer usernames are not a good model for how people want to communicate and be identified, and Drupal should not be so obstructive to site designers in it's search for Core purity. I don't care whether this is in Core or in some sort of officially-sanctioned optional module, but it shouldn't just be left to the wilds of Contrib, because the lack of a module to do this clearly indicates the underlying structure of Drupal does not permit what needs to be done here.

Well said, dbabbage!

Well said, dbabbage and Dave Cohen!

@bobododo: If you're interested in helping this issue, testing and updating the latest patch contributed to this issue is always helpful. But if you're just looking to help with the whole of Drupal in general, see the Contribute page or the IRC Channels.

Also see the patch how-to page.

--Andrew

see #207

+1 to having this available in 6.x. I pull in id numbers to create user names when logging in via CAS and having display names would make references to the user easier to recognize.

@JohnAlbin:

#207 has dissapeared. Please re-post the jist of it from memory if you can?

Subscribing

How can comments (like #206 and #207) go missing? Any ideas?

Either a site administrator deleted them, or they were made by a user who no longer exists. I rather suspect the latter, especially considering all the recent work that's gone into the testbed bot. If the Testing Bot had made replies as a certain username, and then got changed to a different username, those comments would just disappear.

It's no great loss. I presume they were nothing more than 'failed' comments from the initial Testing Bot.

I have nagging doubts padre...

Did my insistence on having display names be non-unique hinder/complicate this patch being accepted?

I'm getting to understand that change more easily happens in small steps. I can also see the wisdom in doing things that way too.

Cheers Daniel

Without having the time to go through this mega-issue, let me add 2 cents worth. If anyone doesn't think that this is a valuable feature, check the usage stats for the RealName module. That module does what is discussed in the original post. It works with both the core Profile module and the Content Profile contrib. Believe me, I would love to see this in core so I can kill that monster. There are, however, many ancillary issues that are going to come up, not the least of which is a serious breadcrumb issue that I see with the user module, but is probably a bug in menu (and is still there is D7).

+1 to NancyDru's suggestion.

I really love her module and use it on a number of sites. I would like to see this functionality in core, and am willing to help troubleshoot the resulting issues that come up as I've already done quite a bit of delving around in the Realname module and User module.

Also, I read this thread once before, but I think my brain exploded after that, so I don't really remember where we were at as far as a patch from this thing.

I'm guessing that webchick's assessment (#234) is probably the death of this issue. I will probably be forced to maintain RealName to my death bed, which may not be much longer. ;)

Can one of the Drupal-gods mark this "won't fix" and put it to rest?

Weak.

Meanwhile, feel free to check out RealName.

It's sad this won't be fixed, and surprised that someone would use Facebook as an argument AGAINST this feature, since people use real names, not usernames on that site, and virtually every popular social site out there lets you customize the display name (youtube, flickr, etc.).

But another alternative that we use that doesn't require extra profile fields or modules is to just have people use their real name FOR their username.

That's what I surprised to find out after agonizing about this for a while - drupal accepts usernames with spaces in them. Of course if you have 2 people with the same name, then just tell them to use their middle name or whatever.

Of course, you'd need a module if you want to ENFORCE the use of real names (or just an attentive administrator). And a module (I forget the name) if you want to prevent people from changing their username. And there is the Logintoboggan module if you want to let people login with their email address OR their username.

Can one of the Drupal-gods mark this "won't fix" and put it to rest?

Why put this to rest, when Drupal needs it? It's a problem, it's fixable, and there's interest from the community. (We are 265+ comments into this thread.)

No one is suggesting adding a security hole in Drupal. However, if we want to choose the "security hole", Drupal should allow us to do so.

I invite interested parties to discuss this in person: http://dc2009.drupalcon.org/node/4424

I can't afford to make the Drupalcon, unfortunately; and this is probably the closest it will be to me for a long time.

I, too, would like to see this in core but I think webchick's comment is pretty much going to reflect the mood of the core developers. I don't necessarily agree with her; I'm just trying to be realistic here.

As I said, if you want to see just how much interest there is, check the usage stats on the RealName module. And that's just people who are brave enough to try this with a contrib and have Update turned on (which does not include any of my live sites). I suspect that if this was in core, you would see a 70-80% adoption rate, despite Angie's reservations.

webchick did NOT say we should not have a display name in core. She said core shouldn't support non-unique real names as display names in core. That's an entirely different thing.

The bottom line is that there's no way to have this feature "securely" without also appending additional information (at least user picture and user ID) to every post.

Translation: Drupal core's default display name must be secure and, therefore, unique.

The general trend, however, is towards core doing the default behaviour that "the majority" :P of the sites will expect out of the box, and providing APIs for easy extension.

Translation: Drupal core should have an API to allow contrib to modify the default display name. Which means core should allow a contrib to modify the default display name to be non-unique.

I don't know how many times myself or others have said this exact same thing. I feel like we could have a drinking game about it. “Oh! Comment #101. Drink!”

Drupal core should have an API to allow contrib to modify the default display name. Which means core should allow a contrib to modify the default display name to be non-unique.

I'll certainly vote for that, it would make RealName much simpler. But there are so many places that use the username without even using theme('username'... that this will take a lot of core testing. And then there are menu problems as well that impact this... And then we get to the other contribs...

BTW, any one of you can set this back to active.

But there are so many places that use the username without even using theme('username'... that this will take a lot of core testing. As I echoed in #56, fixing all the usages in core to use theme_username() would be a good first step to making core more accurate, but also making contrib work better (ala RealName). No one has yet attempted that.

Agreed. #192056: User's raw login name should not be output directly should be fixed first.

After conversations with webchick and numerous others at DrupalCon, I'm redirecting interested parties to another issue, where we can start fresh.

I think we have consensus that we will not change drupal core to prompt for a display name. That is, no UI changes. However we do want to allow third-party modules to easily override the default bahavior. That is, third party modules can assign a display name distinct from the name used for authentication.

Track progress toward that goal: http://drupal.org/node/394282

I totally agree and need this functionality

subscribing

Display Name Code Sprint Saturday September 5th...

Dave Cohen and I just had a really good face to face discussion with Angie (webchick). In summary, we are going to use the Saturday code sprint to make sure that Drupal 7 will facilitate us building contributed modules to implement display names.

This may mean altering some parts of core in a very small way. If you are passionate about cleaning up "theme_username" throughout core and making it easier for contributed modules to implement display names in a clean and consistent way, then join us at DrupalCon Paris or over the wires.

Saturday September 5th 2009 10:00 to 17:00 CEST
Location: DrupalCon Paris and online elsewhere

If you use IRC then #kendra is ready and waiting for you during those times.

I'll make sure developers are kept well feed and watered. So, if you are at DrupalCon and passionate about making it easy to implement display names then get in touch.

This is pretty much our last chance for making Drupal 7 display name friendly! Let's make it happen!

Cheers Daniel

mobile: +44 7853 627 355
username: dahacouk on skype, jabber, irc...
Kendra Initiative - http://www.kendra.org.uk

OK. So, the strategy over the next few weeks (during code sludge) is to get theme_username() used consistently in core. From there contributed modules will be able to implement display names with more ease.

So, if you have time over next few weeks please help Dave Cohen work on the following issue:

#192056: User's raw login name should not be output directly

Many thanks,

Daniel

It's good to see that, after a year and a half, the same "first step" I mentioned in #55 is now being listened to.

Definitely agree with you. The display name should be included in core module.

This is a well-needed feature form many reasons including security. I always wondered why it is not a Drupal core default like in Wordpress !
We should not need a third party mod to have it.

This issue is closed, please look into the other issues and/or file a new one (because when you post here, a lot of people getting messaged). If you feel strongly about getting a Display name in core, I suggest opening a new feature request for Drupal 8, requesting a Display name in core.