In case somebody bumps here accidentaly: If you want to solve the problem of displaying Drupal (unique) usernames instead of your users (non-unique) full names you should use RealName module (D6 and D7 versions available).
Additional info:
Drupal 7 core also now provides a central function that should be used to output a user's name: format_username() thanks to issue [#192056] which was accepted into Drupal 7.
Add Display Name field(s) to core in addition to Username is a D7 feature request. This document assists advocators to bring clarity and structure to the proposal and formulate design requirements to pass to core developers. So, add to this page.
Please see How To Comment below. Comments are additive...
Overview:
There are many reasons for having Display Name functionality in core: security, ease of setup, consistancy for theme and module developers.
Name Fields:
These definitions are intended to describe these fields/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:
- Also Known As: Real Name
- Function: Attribution, Authorship
- Usage: Is intended to appear in web text and not in web links or URLs.
- Uniqueness: Default setting is not unique (as real names are not unique). Webmaster has option to set this field to unique.
- Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.
- Clone: Webmaster has option to set this field to be a clone of the Username field - in which case the Display Name field would equal the Username field.
- Changeability: Webmaster has option to set whether the user can change this field or not after creation.
- Defaults: Initially, Display Name field would be set to equal the Username field so as to mimic D6 behaviour.
-
Username:
- Also Known As: Login Name
- Function: Authentication
- Usage: Is for login purposes only and never to appear on public parts of a drupal website. Only to appear in settings page for each user. Never used to refer to users in web text or web links.
- Uniqueness: Always unique. No webmaster options on uniqueness.
- Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.
- Clone: Webmaster has option to set this field to be a clone of the Email Address field - in which case the Username field would equal the Email Address field. The Username cannot slave off Display Name or URL Name fields.
- Changeability: Webmaster has option to set whether the user can change this field or not after creation.
- Defaults: Initially, Username field would be set to be user generated so as to mimic D6 behaviour.
Backwards Compatibility:
- The webmaster could set: Display Name and URL Name to be a clone of Username. This should be the default which will give us the current D6 behaviour as it stands (ie just one user name field), removing upgrade confusion, and meaning that unless a webmaster activates either option, they can't change it and wonder what went wrong, and why it doesn't work like D6 used to.
Discussion:
- For discussion/questions/disagreements use the issue thread.
Use Cases:
-
In all cases the webmaster should set name policy as they wish.
-
Optional Display Name. A user could be known as 'George Marshall' on the site if this was set, or 'gm423' if it was not.
-
There is a compelling need for separate URL Name and Username. As there could be some situations where having them different could be advantageous. One scenario is where a webmaster decided to make the Username the user's email address - then the URL Name would not work as an email address. [macgirvin - Yes, but we would already have the necessary fields (username, email, and displayname). See my note on implementation below].
Implementation:
- A possibly useful implementation could be with the named entities as pointers to arbitrary DB fields. URL Name in the case above (separate URL Name and Username) could be a pointer to the DB Username field, while the Username could be a pointer to the DB email field; allowing login by email. Some flexibility in what to point to could go a long way and open additional implementation posssibilities. If both URL Name and Username pointed to the DB username field, it would solve at least one implementation case. One could also easily implement a login by UID by pointing Username at the DB uid field or alternatively use Display Name from an already existing module.
How To Comment:
- For questions/disagreements use the issue thread - so not this document.
- Comments are additive. Add in your own ideas - so no deleting other peoples' ideas.
- This document is written in the third person - so no "I" or "My".
- Bring clarity and structure - alter terminology if it brings better understanding.
- No need to sign comments - this document reads like an article.
- Reference supporting material from the issue thread and elsewhere. Also, refer back to this document from the issue thread .
To Be Refactored:
-
catch what does this do that pathauto doesn't? We have user/uid for URLs which isn't going anywhere, and it would be easy to set up pathauto rules to alias this to an arbitrary value based on some other field from contrib.
- (destined) The difference I see between what pathauto does now and a seperate URL Name is that Pathauto has to get it's data from somewhere yes it can (can it?) be set to a contrib field, however one of the points made in the discussion in the issue queue was that many feel this kind of field should be in core and not relying on a contrib module to provide the field. I still imagine that using URL Name would come from pathauto, however this leads to the question of if we have a URL Name field in core, then why do we need to use a 3rd party module to do use it as intended. Maybe UID could be depreciated in favour of URL Name, as by nature URL Alias should be unique, or maybe the path system is made aware of URL Name and transparently handles requests for user/url_name as it does user/uid currently?
Everything below this line is archived for future use and not considered part of the issue
-
URL Name: - there seems to be quite a lot of opposition to this URL Name so if you are for or against it make sure you speak up on the issue thread and we'll get a consensus.
- Also Known As: Link Name, Screen Name, Nickname, URL Alias
- Function: URL
- Usage: Is intended to appear in link text and URLs and not in web text.
- Uniqueness: Always unique. No webmaster options on uniqueness.
- Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.
- Clone: Webmaster has option to set this field to be a clone of the Username field - in which case the URL Name field would equal the Username field.
- Changeability: Webmaster has option to set whether the user can change this field or not after creation. Thinking in terms of permalink setups, where a webmaster might always want the content accessable via the same URL, even if the user changes their Display Name.
- Defaults: Initially, URL Name field would be set to equal the Username field so as to mimic D6 behaviour.
Trying to figure out why some links work and some don't. Seems that duplicate links don't get parsed correctly.
- [[http://drupal.org/node/102679|the issue thread]]
- [[http://drupal.org/node/102679|the issue thread]]
- [[http://drupal.org/node/102679|the issue thread]]
- [[http://drupal.org/node/102679|the issue thread]]
- [[http://drupal.org/node/102679|the issue thread]]
- [[http://drupal.org/node/102679|the issue thread]]