Add a standardized full name field to the users table

subscribing

subscribe

This patch adds no extra features, just the possibility to add extra information to users, and for that we have Fields.

Xano, you can add Fields to Users? really? I thought the fields-in-core patch only allowed fields to be added to content types.

If you are referring to User Profile Fields, we've had that discussion already. See #102679: Add a Display Name field to core in addition to Username for why User Profile Fields don't work for theme_username situations. In particular Crell’s comments should be sufficient if you don't want to read the whole 250+ thread.

@Dave Cohen, btw “Failed to install HEAD” means that after applying the patch, the Drupal installer fails to work properly. I've already created an issue to make that error message more intuitive. #371309: "Failed to install HEAD" message makes the bot seem like a failure

Xano, you can add Fields to Users? really? I thought the fields-in-core patch only allowed fields to be added to content types.

Fields can be added to users already, so there is no need to continue this issue.

+1 for this change.

@Xano: One of the specific areas where I've run into problems with theme_username not fully overriding is in the administrative interface at user/user/list. The realname module tries to override places where theme_username doesn't seem to apply. It has special overrides for hook_comment, hook_mail_alter, and specific forms (user_profile_form, contact_mail_user, and contact_mail_page). However, it still doesn't change all of the username displays. It would be great to have a consistent, fully-implemented way of always overriding the username display throughout a Drupal site.

I've re-rolled the patch, although I'm not sure how much good it will do.

Subscribing for later comment, once I have a chance to review the attached patch(s)

+1 from the developer of the RealName module.

@JuliaKM: If there are places you can document, please open an issue in that module's issue queue and let's see if they can be fixed. Until this gets into core, that could be a good clearing house for places this needs to be fixed.

I don't see it, so thought I should ask. Does this index the display name for search?

1) users.username would be a better name for this column and also for the $user object property. $user->name and $user>username would be obvious, because the term "username" is used in many other systems.

2) However, with Field API in core, I really think a display name should be a field, because its purpose is rather _content_, while the user table stores essential user data required for authentication and other stuff.

@Dave Cohen: as noted by others, this display name needs to be a field, which is possible now in D7. That doesn't mean that the change doesn't belong in core (it does, because it requires some change to theme_username() and such), but that your patch needs to leverage the Fields API, not manually add a new column.

I have always been confused by the need for this issue and how it gets so much traction. On MothersClick.com we tackle this problem by allowing users to say WHO can view their full name. We tackle it our theme (it is D5).

With Drupal 6, if you made the theme_username a tpl.php, you could then use preprocess functions to change the name. Thereby allowing any module to change the display.

Doesn't that get you there? Can't you in your module do a registery_alter() change the theme_username() to a .tpl and then do your magik in a processor? I am thoroughly convinced that this isn't a core problem. But if it is, why isn't this patch about changing the theme_username to a .tpl.php so modules can do whatever they want?

For example, why this approach will not work for MothersClick.com. Because of the use of a display name, I will not be able to dictate which name to display on a per user basis. Say for instance, as a friend of Suzy I can see her full name. But as an Anon user, I should be able to see her screen name. How will this patch address that issue?

My approach, would allow any module to do its thing and apply any logic it needs to in a preprocess function.

Don't fight the system, use it.

Nobody wants to "fight" the system, the attempts here are just to make it more user-friendly, like most others are already in regards to distinguishing the login name from the display name.

@Dave Cohen: I am not referring to the database index, although it would be a good idea to have one. I am talking about searching. Currently, user_search has

$result = pager_query("SELECT name, uid FROM {users} WHERE LOWER(name) LIKE LOWER('%%%s%%')", 15, 0, NULL, $keys);

I'm thinking it needs to be

$look_for = drupal_strtolower($keys);
$result = pager_query("SELECT name, uid, login_name FROM {users} WHERE LOWER(name) LIKE ('%%%s%%')" or LOWER(login_name) LIKE ('%%%s%%')", 15, 0, NULL, $look_for, $look_for);

BTW, why not just call the new field "display_name," which is what everyone is calling it?

@Scott Reynolds: Have you looked at how RealName does this? I do redirect theme_username.

I agree with Scott. A "display name" can simply be a field for the user object, not necessarily provided by core. What belongs in core though is User Display API, which allows you to setup many different "styles" a user can be displayed, using arbitrary decorators, such as user picture (processed via configurable ImageCache preset), a user profile field value, Gravatar images, amount of buddies and other statistics, geo location, postal address, or whatever you could think of. That approach serves any use-case, not just the one where you may want to have a "display name" for each user (which is not really true for all Drupal sites).

User Display API is pretty simple and straightforward. I could use some help porting it to D6, and based on that, turning it into a patch for D7. Perfectly doable in the remaining time-frame.

The User Display API module for D5 seems great - just like what the RealName module for D6 does, plus more - if I understand it correctly. A port of that API to D6 is probably just what many people are looking for.

@sun: This conflicts with the patch in #192056: User's raw login name should not be output directly but could easily be reworked to fit with that. I have extended that patch with:

/**
 * Format a username.  (copied from theme.inc)
 *
 * @param $object
 *   The user object to format, usually returned from user_load().
 * @param $options
 *   An associative array of theme options.
 *     'plain' => whether or not to make the name a link (default: FALSE)
 *     'picture' => whether or not to include the user's picture (default: FALSE)
 *        will not be done if 'plain' = TRUE.
 *     'homepage' => link may be to the user's homepage (default: TRUE)
 *     'levels' => include user level marking (default: TRUE)
 *     'max_length' => maximum name length to show (default: from settings page)
 *     'not_ver' => whether to show "not verified" (default: from settings page)
 *
 * @return
 *   A string containing an HTML link to the user's page if the passed object
 *   suggests that this is a site user. Otherwise, only the username is returned.
 */

@NancyDru: Thanks for the pointer. However, IMHO, all of these approaches are too limited and do not provide real value and flexibility for site builders as well as contrib modules. Stuff like display_name, homepage, whether to output the username as link, maximum username length (truncate limit), and any other stuff are arbitrary decorators. Some want them, some others not.

The approach of letting modules define (hard-coded) "classes" is what makes up the flexibility: The module just tells _where_ a user is output and does not force any specific user display style. As a site builder, you can then setup various different display styles (using arbitrary decorators for each one), and assign them to one or more classes (which, again, are hard-coded in modules). You can configure the exact order of decorators, and each decorator may come with additional configuration options.

Example:

- User listing: Username (linked, not truncated), user picture (using ImageCache preset "large")

- Node listing: Username (not linked, truncated), "Member since dd/mm/yyyy"

- Node view (like an author block): User picture (preset "small"), Real name, Username, count of Article nodes written, etc.

@roball
Sry should have been clearer. I feel that Drupal (the system) provides an API already to do this. I know this cause I do it on my projects. And I know that it has become decidedly easier in Drupal 6 with a lil registry altering.

@NancyDru
Yes I have seen RealName, and I found it overly complex. Again I really feel like in under 200 lines of module code I can achieve this (I have in D5 and will in D6). Registry_alter() and preprocess that bad boy and Im done. Doesn't matter where the data resides and what module does the preprocess function. They all get a shot at it. The API exists already

@sun
I haven't seen this module. But once again proves my feeling like this isn't a core issue. Modules are able to do this.

I see this as a need in the Drupal community, not as a core feature.

@Scott: I basically agree. However, to let User Display API do its magic (yes, possibly still as contrib module), it requires that each other module that outputs a user passes a second ($class string) argument to theme('username') or theme('user_picture'). Using this additional classification, User Display API can render a user differently for each class by overriding theme_username() and theme_user_picture(). Mainly, that's the only addition I want to see in core - without it, each and every theme function that outputs a user would have to be overridden. Drupal core itself renders usernames and user pictures like it did before, possibly using those two styles as default styles. The additional classification can be considered as meta data. All core and contrib modules would provide this classification to allow site builders to have control over the rendering of users - anywhere.

Field API would expose all fields on the user object as decorators - and there you have it, your "Display name", optionally displayed where *you* want it, and not where Drupal core thinks it would be nice to have.

@Dave Cohen

For example, I could let users log in using their email address by using that in the users.name field (as well as users.mail). Its important that I never show that email address to other users, and for asthetics never show it to the current user either. At the same time, I want to support all of drupal's themes and features.

hmm no need to put that in the users.name field. Just form_alter the login blocks and user_login form and add in ur own validate (Pro Drupal Development page 130 EDIT: Thats version 2, for Drupal 6). A kitten just died....

How do I prevent the email address from appearing in the navigation block? How do I control what appears in its place?

How do I prevent the email from appearing in the user search results? How do I make user-friendly names appear there?

How do I prevent the email address from appearing in the title of the user page? How do I control that?

when its put through theme('username', $account->name); all modules preprocess_username functions are called and you change the variables.

I take it that solves what you mean. If not, u need to talk with whomever hack your search.module to put the email address in results and save more kittens...

How do I present a user-friendly name when I send that user an email?

This can get tricky if the module sending the email doesn't put the name throught theme('username'). See #192056: User's raw login name should not be output directly

I can sit down after work and create a mock module that accomplishes displaying a users firstname + lastname. Will work in any theme. Again, I am using this on a D5 site and have it working internally on a D6 site. It is most def, doable and easy...

@sun
In regards to User Display API, can the module "discover" which type of "display-class" from within the a preprocess function? I would have to look at that module more indepth. In my module, I check the $GLOBAL['user'] against the $account passed into the theme() function to see if the $GLOBAL['user'] can see the $account's full name. Its a permission check (user_profile_access($account, 'name') returns TRUE/FALSE if the $GLOBAL['user'] has access to the $account's full name)

Check out MothersClick.com. We allow logging in with email addresses or your screen name using the same textfield. We have settings control over whos sees your full name. This isn't a core problem. (We at ParentsClick don't kill kittens)

With all that said, theme_username() can be called with something thats not a user object, and my logic fails in that case. You will need to add queries and do so smartly. But thats a separate discussion really. Its not about adding another field to the user table.

#192056: User's raw login name should not be output directly is not a substitute for this patch. But that issue does need to be fixed first. Otherwise, we'll end up with another 250+ comment discussion.

I refuse to review any patches for this issue until the other one is fixed. Please, please, please! For the love of god, let's not repeat #102679: Add a Display Name field to core in addition to Username

@Xano: Dude, I answered that question already. User profile fields are not sufficient. Please read the comments I pointed at.

I'm sorry to “postpone” this right now. But I really, really, really want the ability to extend display name in D7 and don't want the issue to be discussed to death. I'd like to especially apologize to JuliaKM! Thanks for the patch, but can we work on #192056: User's raw login name should not be output directly first? :-) We'll move this back to "patch needs work" after that one is done.

[edit: bah! I posted a wrong url on one of the links above. Fixed now.]

Field API allows to attach fields to any object, not only nodes. Basically, Profile module is dead already.

@JohnAlbin: Sorry, but that does not make the proposal any better. A "non-unique display name" for users is nothing else than any arbitrary field. If we would continue this approach, you could only have this one and only "display name", while there are countless of other possible fields one might want to display instead or additionally.

What this proposal will end in: We would have a module called "auto_usertitle" (forked from auto_nodetitle) that dynamically composes and writes the "display name" of user based on various other fields. The concept is wrong, because it writes and duplicates data of other fields for the sole purpose of rendering - because the title (display name) is obligatory. That's plain wrong.

@sun: Yes, if something like this was put in place, RealName would, indeed, place its computed name into that field. Think of it more as caching solely to avoid burning cycles and queries.

@Dave Cohen: I have worked hard to prevent all those extra queries in RealName and I think I have gotten rid of almost all of them. I could get rid of even more with a "caching" (as above) solution, which I am considering now.

@JohnAlbin: I agree, that issue needs to be resolved first because the various alternatives here depend on that.

Making yourself familiar with the new thing called Field API we have in core now might eliminate most of this discussion.

Field API implements various caching levels. A dynamically composed, additional object value will automagically be cached (when added to the object at the right time).

And how many extra queries (whether to field tables or caches) must be done when all I want is one extra field when I'm looking at the user table anyway. De-normalization is not always bad.

http://scottreynolds.us/node/9

Achieved in 70 lines of code. Themes the username to be firstname lastname. and does so while preserving the existing theme('username') callback. I.E your theme might have a my_theme_username() function and it should work with it.

when I'm looking at the user table does not imply user_load. And static caching (which RN does) reduces what overhead there is.

What about simply adding a custom username field (as in a Fields.module field) that utilises theme_username() for display?

can someone tell me exactly why 'name' itself has to be unique? My guess would be for login purposes only.

Perhaps this is a novel idea? Seems like it would be cool to be able to select what fields in core would be unique and then allow for a unique field to be the login field.

I can foresee some admins choosing 'name' (username) and allow emails to be non-unique, some choosing 'mail' allowing 'name' to be non unique, while others might create 'account_number' field, thus allowing the other two to be non-unique if they choose. Is there any talk of having 'mail' and 'name' be fields (Field API?). Multiple emails and usernames per account then also become a possibility.

I'm helping with the migrate module, where the core focus is migrating from other CMSs, including proprietary ones where any of these situations is a possibility. Thoughts?

The only solution i see i without a paradigm shift is to append something to the end of 'name' like _1, _2, which i think was what you are doing in fb, right dave? Another way would be to assign everyone some random 'name' and put your name in a new field, say 'username' then find every possible way to avoid using 'name', including login, but that's ugly too. You'd either have to have a bunch of contrib modules, or re-tackle all those issues in your own module.

With a fieldAPI approach to 'name' and 'mail' I would say that these fields could be created with the default installation profile in D7, but then could be modified by admins or contrib modules to be exactly what they need them to be. Granted I know this would be a big paradigm shift perhaps. Modules wouldn't be guaranteed that these fields exist or are unique, upgrade path could be daunting, so this would require much more elaboration, but it seems like drupal would be much more flexible and isn't that how it's supposed to be?

My suggestions extend to title and body fields for nodes, but that is outside the scope of this issue. I say if we're going to have fields in core, why not go all the way? I'd like to explore this further outside this issue, if anyone knows if this has been discussed already , let me know where?

a thought: things like 3rd party auth would also be greatly improved as well.

subscribing

subscrube

Anybody want to join me in submitting a BoF at Paris DC on this subject?

This is an important security enhancement. By implementing this, we can stop disclosing usernames, which is one of the "keys to the kingdom."

@davecohen in #48: I got so frustrated with trying to get this really simple and desirable issue into core I gave up. I got nothing but "You can't do that cause core doesn't do that." Well, I was trying to change core's default behavior for the better, and I wasn't a lone wolf on it either. I wasn't even the one who started the issue. I picked up the torch after I saw the fourth issue about this subject gaining steam, and I ran with it as far as I could.

Consider this concept dead. The owners of Drupal core have said that they'll never implement a real name/nickname solution, even though the rest of the universe thinks it's a grand idea and has something similar to it in their 0.5 software versions.

Daniel, I hate to tell you this buddy, but another BoF on this topic is gonna do nothing more than create a warm breeze of human breath. That patch in the previous issue that got shot down enhanced core's security by hiding login names from the public, gave admins the option to enable the feature if they wanted it without forcing it upon them, gave them a secondary option to disable the uniqueness of nicknames should they desire, and worked alongside the current mess of user.module $username crap rather than fighting it since rewriting it was not an option for that patch. Harris, give it up, kk? :)

Sounds like the RealName module has a bright future...

Consider this concept dead. The owners of Drupal core have said that they'll never implement a real name/nickname solution, even though the rest of the universe thinks it's a grand idea and has something similar to it in their 0.5 software versions.

Where did they say this?

I have been evaluating Drupal for the last couple of weeks on behalf on the University department where I work as a systems admin and I cannot believe that this CMS does not have the in-built functionality to add a full name in addition to the username.

This is the only CMS that I have come across so far that is this inflexible. It seems from reading a lot of this forum thread that the apparent intransigence of some of the drupal development team is quite shocking. For that reason I think I will not waste further time on this particular CMS and continue to look elsewhere.

I suspect many others have done the same as me.

Sorry to hear your decision. I would suggest that you look at the RealName module. One of the truly great beauties of Drupal is its modular structure, which allows all kinds of extensions to core functionality. Virtually everything is possible.

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

username: dahacouk on skype, jabber, irc...
Kendra Initiative - http://www.kendra.org.uk

Paris is UTC+2, and California (where the rest of the world codes from :) is UTC -7, so this makes it 1am to 8am on Saturday for me in San Diego, CA [same day].

I'll try to make it for the first hour, but then I'm goin to bedz! ;)

Sorry about the timing but not sure what else we can do. I'm sure there'll be lots to do after the code sprint though. But at least the issue is on Angie's radar and she agrees that something needs to be done to improve the situation and provide nice hooks for contributed modules to implement display names.

Cheers Daniel

Daniel, if there's any way you can look at it, I think it might help to look at the RealName module, which already implements some changes to theme_username that were generally acceptable based on the issue queues.

Hi Nancy,

Unfortunately, my own PHP abilities are pretty rudimentary so, personally, I'm sticking to keeping this issue bubbling. And trying to keep developers communicating across related issues. I just want to see display names easy to implement. It's almost a pure business/marketing issue for me. I've seen people turned off Drupal just because it wasn't a one click option.

So, Dave Cohen's 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 and good luck,

Daniel

@Senpai #55: Missed your comment on giving this issue up. Hah! Never! ;-) Problem with me is that I find it hard to let go once I've got my teeth into something. 10 years of Kendra Initiative shows that.

Dave and I had a good chat with Angie at Paris DrupalCon and, although we still had the "core doesn't do that" response, at least we got consistent use of theme_username() back on the radar. Or perhaps that would have happened anyway with the RDF lovelies needing this issue solved for their patch.

Anyways, here's my take on why display names hasn't gone through yet into core. You, Nancy, Dave, Larry and the rest seem to have all been working alone. There's no consistency in your approach. You all work individually - one after the other - each on a new patch. There's no concerted effort. It's easy to run rings around you guys because your approach is fragmented.

We need a strategy. We need to work together. We need to be unified. We need to be singing off the same sheet. Get it? Set up a group to rally the troops! Have conference calls. There are some big names with influence that want display names in core and together you could push it through. But apart you wont.

Perhaps you could get this into D7 if you all worked hard and together. But it's a tall order - time is out. Most of you are concentrating on other areas and lack time. Perhaps the best thing is to make the RealName module sing and dance and then next time around (D8) push for it to be whacked into core. If you take that route then perhaps the best thing to do for D7 is get as many tweaks into core that make it easier for RealName to work well...

Cheers Daniel

If core uses theme_username consistently, it easier to tell other contrib maintainers to do it right. Then RealName will be 90% done. Now if there was an easier way to fix autocompletes...

Yes, Nancy, how could we tweak autocomplete so that RealName could plug in to it to tell it to auto complete something other than the username? Is that what we want?

And how do we deal with autocomplete's display when it finds display names that are the same? How do we disambiguate?

Cheers Daniel

Disambiguation is really the admin's worry, IMHO. As for making it easier, perhaps reading some of the issues that have been reported would help.

I agree, "disambiguation is really the admin's worry". But is there a way we can make it less worrisome for an admin? For example, the admin will have to choose how they disambiguate. They have a choice of fields: could be anything from their home town to their picture. Is there an easy way to make it easy for admin to just choose which piece of content to display in addition to the Real Name when duplicates are found?

Perhaps I'm straying off topic. I guess RealName will implement this and so it's not crucial to sort this out now for codesludge. For now we just need to get theme_username used consistently, I guess...

Cheers Daniel

Given that the last patch for this is 6 months old, I'm marking this a duplicate of #192056: User's raw login name should not be output directly. Of course, the proposal in this issue is to add a field to the user object, and the proposal in that issue is to not change the user object, but to route all non-user-administration display via format_username(), which in turn invokes hook_username_alter(), so that modules can decide what should really be displayed as the name. If someone feels strongly about the user field approach, feel free to unmark this as a duplicate. Otherwise, please review latest patch on #192056: User's raw login name should not be output directly to see whether we captured all the places where format_username() (i.e., the display name) is what's desired vs. where $X->name (i.e., the login name) is what's desired.

effulgentsia wrote:
> If someone feels strongly about the user field approach, feel free to unmark this as a duplicate.

In my opinion, JohnAlbin and others are right about this issue not being a duplicate of #192056: User's raw login name should not be output directly. That issue is a fix to clean up username output -hopefully for D7, maybe as a bug fix-, which for example can be a first step to facilitate optional features like this other issue -hopefully for D8, too late for D7-.

There are several resources on these topics, like Add Display Name field(s) to core in addition to Username, a wiki page that links to #102679: Add a Display Name field to core in addition to Username, which is another issue marked (2009-03-07) as a duplicate of this issue, also marked (2009-10-07) -and now unmarked- as a duplicate of #192056: User's raw login name should not be output directly, which has been proposed to be renamed as "Clean up username output".

I think there is a real problem with the current title for this issue, "Allow non-unique display name", and I'm going to explain why.

Let's remember some excerpts of what Angie Byron (webchick), the Drupal 7 co-maintainer, wrote on the #102679 issue:

----------

"Drupal has a reputation for being secure out of the box, and this change seems to actively work against that."

---

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

---

"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"

----------

So, an issue with the current title, "Allow non-unique display name", is not going to get through, even for Drupal 8. The title is too limiting, and what this issue is about is something different, according to its opening description:

"Our approach here is to add a field to the drupal users table".

As stated many times, this field could be optionally displayed or not. depending on settings, so it should be better named for example "Full Name" rather than "Display Name". This field could be, also optionally, required or not. And the field should be standardized, so that modules can use it in a consistent way.

I'm renaming this issue, following its description, to "Add a standardized full name field to the users table". If there is a more accurate title, please correct it.

And about what to do with that field, it seems we should find ways to make the displayed name unique, even when real names are not unique. Possible ways to display it on articles, comments, etc., are:

• Full Name - Only if it's made unique, something difficult for users with the same real name.
• Full Name (II) - The IMDb style.
• Full Name (login name) - Suggested by webchick.

etc...

I think we should postpone this issue to Drupal 8. On the other hand, #192056: User's raw login name should not be output directly could be committed to Drupal 7, hopefully.

I reckon you should look at the Real Name module - http://drupal.org/project/realname - for inspiration.

RealName says it "allows the administrator to choose fields from the user profile that will be used to add a "real name" element (method) to a user object".

I feel this is the better and more flexible way to go down this road. So, that one isn't stuck with using the "Full Name" field but can create the display name out of any available fields as the administrator sees fit.

So, it's more of a pointer (or set of pointers - like: full_name = first_name + last_name) than a hard coded field itself.

Hope that's useful.

Cheers Daniel

@dahacouk: that is correct; RealName can use any profile (or content_profile) fields to construct the name - and uses a token-like pattern to put them together. So on one site I am "The Beautiful Webmistress" (okay, a bit of a stretch), and on another I am "Ms. Nancy E. Wichmann, PMP" - both using RealName to pick the fields. The side benefit is that you are then free to design the profile the way you see fit, rather than being forced to have a "Display my name as" field.

I reckon in this issue we should just be integrating RealName into core. Would give us the flexibility we need. And why reinvent the wheel if all the works been already done. Period - as you say in America.

But, hey, this issue is miles away from landing. D8 indeed!

The Drupal powers-that-be have made it clear that something like RealName will never be in core. I can't say that I disagree with their reasoning. However, my 4,200 users may. However, consistent use of proper theme functions would make the module operate much easier and more universally. I would not be surprised if some day RealName joins the "must have" list with CCK and Views. Job security!

Actually, I agree with your not disagreeing with their reasoning. And, sure, we just need #192056: User's raw login name should not be output directly to land to make things much easier for RealName. Is there anything we can do to nudge it along? Or do I just have to sit here nail biting - figure of speech - I don't bite my nails.

I'm still not sure about the title of #192056: User's raw login name should not be output directly and wonder if it's better to say "User's login name should be output via theme_username()" or whatever funnel we are using...?

Out of interest I created my first WordPress account today and discovered the profile area and all the options it gives you for username, real name, nickname and display name. Amazing! Is that out of the box or a plugin?

http://drupal.org/files/wordpress-profile.png

Cheers Daniel

That WordPress stuff is out of the box.

I wonder why committers at WordPress think so widely different from their counterparts here at Drupal?

A proposal...

Real name, nickname and display name don't have to be in core for us to get what we want - consistent methodologies, functionality and code-reuse adopted by module/theme developers across the board. Isn't that what we want?

And, to be honest, this stuff will never be put into core until there is a mass adoption of a single solution to this issue. Modules get absorbed into core after they have been deemed must-have by the community. That's the way most things seem to work here. Any attempts at logic ("this makes so much sense!") are secondary to community backing ("look at the numbers!").

So, we've been going about this the wrong way round. For years!

So, I propose that we all align behind a single contrib module and work on it to make it better - there's always room for improvement. It seems that RealName is the only contender here. Yeah?

Perhaps borrow the #D7CX idea and get module creators to play nice with RealName and put #RNCX pledges on their modules. So, we can get a whole eco-system of modules/themes working consistently with real names, nicknames and display names.

So, guys and girls, let's get real! This stuff is not going to happen in core. Let's stop trying. We need to make it happen outside. We need to align and work together. Shock horror!

By the way, this doesn't have to be RealName but it's got to be something. Anything else out there?

A plan indeed... What do you reckon?

By the way, I'm not a developer, so I've got no clout in this - apart from shouting loudly...

Cheers Daniel

I would certainly welcome help on RealName. Sun might argue with RealName as the only contender, but I would say that his and RN are the main ones, if not the only ones.

So, the modules are currently RealName and User Display API.

Note that User Display API follows an entirely different concept and idea of displaying users. It's rather not about their names, but instead, about their entire representation - more or less rather meant to replace a user name/picture in views, tables, lists, or author information. Rather not to replace a username in the page heading, site title, or "Submitted by %username on %date" line.

I think that these are fundamentally different use-cases/implementations.

Agreed that "these are fundamentally different use-cases/implementations".

Even better that we now have two modules to showcase cross-module interoperability, alignment and compatibility; to prove the point that we are building a whole eco-system here.

So, what we are doing is running a campaign (and/or group) to harmonise methodologies between modules and themes and provide "standard" ways for users to implement commonly required "features" related to User Display and Attributes (login name, real name, nick name, url name and display name).

Is this campaign for "User Display" or is it "User Search, Display and Attributes"? What I'm getting at is when we search for a user, we want to be able to find them by their real name or whatever metric too. What about login and registration? Ah! Instant recall of Senpai's valiant efforts dashed. But, hey, all that code is still there and usable for contrib if need.

But back to the name of this campaign/group/effort. And a mission statement. And I guess a group on g.d.o - I can't find a group that seems to be working in the area we are talking about. What else?

Is this all making sense as the way to proceed? Because, for once, for me, it really is in so many ways. But it requires a few competent developers to say "eye". So who's in?

We could have something coherent ready for when D7 lands and that would great.

Sure, it would help us all if #192056: User's raw login name should not be output directly lands so I guess that could be our first collective mission. I'm obviously green to the etiquette of committing so if nudging webchick or Dries is not the done thing then I guess we just sit tight. But, if it is, then we should nudge...

Cheers Daniel

Well, Daniel, we're in luck. #192056 was committed (HOOOOORRRRAAAAAYYYYYY).

I fully support Sun's way of implementing this feature; I believe it is healthy to have the separate methods. Now, if we could just extend the day by another 6 hours or so, maybe I could start working on RealName for 7.x... It's going to be fun.

Right! Now! Where does this leave us going forward? Working on a patch for D8 core doesn't seem a good use of our time at this stage.

Now that #192056: User's raw login name should not be output directly has landed it should make a lot of things easier. However, as I said in #394282: Add a standardized full name field to the users table I reckon we need a lot of methodology alignment between modules.

The aim is to make it easy for website creators to implement useful features that don't come configured as standard within the vanilla install of Drupal. Right?!

I guess it would be best to start with documenting scenarios a la Dave Cohen's #394282: Add a standardized full name field to the users table and many others. And not doing it in a forum but in a book/wiki page - so they are easily viewable living documents. What do we want to be able to build? Then document how we could implement those desired features given current contrib modules. Then see where the gaps are and build glue in necessary.

I can't help thinking that other modules such as hunmonk's play an important part of the user eco-system:
http://drupal.org/project/alt_login
http://drupal.org/project/logintoboggan

I don't reckon I'll bash on about this "huddle" approach for too much longer if I don't get at least one thumbs-up. But the alternative is everyone disperses; builds their own part of a jigsaw; where no one knows the full picture; brings their piece back to the table and there's gaps. Hope that's not unnecessarily negative.

But with D7 looming doesn't it make sense to have a bit of a game-plan?

Ah! A roadmap of sorts. That's what I'm talking about. Just a roadmap for user related functionality. Yes?

Cheers Daniel

Thumbs-up from me!

Tomorrow never comes.

As #102679: Add a Display Name field to core in addition to Username

Reverting metadata change. This is a new feature that probably has to go into D8 first.

subscribing

Subscribing

"eco-system of modules" ?

Is this the first instance of this turn of phrase on drupal.org ?

It's a horrible analogy and reflects a complete disregard for ecosystems found in nature.

Call it a frigging "tapestry of modules", or how about a "collage" or "mosaic". A mess of good and bad. A library.

"Ecosystem of modules" just makes the writer sound ignorant of the basic principles ecology. No light matter in dirty 2010.

edit after this comment posted by Michelle: http://www.emmajane.net/artefacts#comment-2617

More spread of the word ecosystem in reference to the collection of Drupal modules, here: http://www.emmajane.net/artefacts

'frog of modules'
'haystack of modules'

'knitted sheep's nostril hair of modules'

It's a race to the bottom.

Issue queues aren't the place to impose radical left wing speech codes. Please take that discussion somewhere else.

Radical left wing speech codes? What?

Ecosystem has meaning. It's as robust as 'democracy', though far more scientific . I call to question its sloppy misuse and here, its first misuse. I reference, after myself being referenced back here, its continued sloppy spread.

I clicked reply to #80 and had it been threaded correctly, in response to that single post and in direct reference to the actual first citation of the use of the phrase on drupal.org, rather than as a post seemingly out of nowhere as if part of the entire issue queue, it would have been better.

I never intended for it to be entered, here, as a general issue response. I clicked reply to #80 but it didn't thread the response.

Oh well.

subscribing

After I almost lose my mind reading whole #102679: Add a Display Name field to core in addition to Username issue, I really can't believe that simple solution as implementing API @ Drupal core to allow contrib to modify the default username to be non-unique have so BIG potential of strong rejection.. :(

Even JohnAlbin suggested in one moment something similar:

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.

That would be really useful for (among other) building social sites..but, as far as I can see, if you want to display users (non-unique) full names instead of Drupal (unique) usernames you should use RealName module (D6 and D7 versions available).

As there is no active development in this issue for almost two years, I will put it to rest. For good. :/

RealName is not core. This is, apparently, the approved solution. But until Dries says "won't fix," I would prefer to keep this open.

Updated according to Real Life™ Solution / Workaround

I against this. Two main reasons.

1) We have fields on user bundles already for this. Both Name field and RealName modules should be providing enough info for core to handle obscuring the users login name. Although there are issues still to resolve here in relation to this but these are unrelated to this thread.

DO theme_username() or format_username() open issues.

2) A text field is woefully useless when it comes to parsing a users name.

For example, "John Peter Doe" could mean either that John is the users first or last names depending on the users locale¹. So if I wanted to use the Name field module to provide functionality such as "Dear FIRSTNAME" or "Welcome TITLE SURNAME", I would end up with 3 name fields in the user bundle which would be a terrible UX.

With no interest from the core team, and two modules providing this functionality in contrib, I'm marking this as closed. Please focus energy on any outstanding issues related to theme_username() or format_username() rather than reopening.

Thanks.

¹
Well technically, John is the users first name, but in most western languages the first name actually means the users given name rather than the surname or family name. :)

Updated according to http://drupal.org/node/394282#comment-5179374