The Display Name field is often misunderstood, and in my opinion... Not very well thought out. It has great potential for many different things, but overall I find that I answer more questions about it then I actually use it. The most common question about it is, "How can I remove it?" I will address it here.
First of all, there was a new feature introduced around DotNetNuke (DNN) version 4.4.1. It allowed you to specify the Display Name property using a token. This token would then configure the DNN portal to use this token to automatically generate and assign the DisplayName property of the DNN UserInfo object.
The down-side to this setting is that it performs this task by updating the profile of ALL of each of the users in your database. So, there is no way to restore the previous setting. All previously specified Display Name values are lost permanently.
The up-side to automatically assigning the Display Name using this method is that it removes the Display Name field from the Profile and Registration modules. This is great for end-users, because it is one less thing to do and one less thing to think about. (I'll give you a cookie if you can tell me what I mean by that!)
How to Remove the Display Name Field (DNN v4.04.01 - 4.05.05)
The preceding steps will remove the Display Name field from your Registration and Profile modules/pages. However, this will likely raise one or two questions...
What will the Display Name be for new users now?
The default membership provider has hard-coded that the Display Name will be a combination of the first and last name of the user. For instance, if the user entered their first name as "John" and their last name as "Dough", then this new user will have his Display Name automatically generated to reflect "John Dough".
What if I want a different value other than the tokens?
Unfortunately, neither the DNN Code or the DNN Membership provider allows you to change the tokens or the default Display Name. Also, the DNN core does not recognize any tokens other than [FIRSTNAME], [LASTNAME], [USERNAME], and [USERID]. Entering any other token name will do nothing. Effectively, this token value will be ignored, but the Display Name fields will still be gone.
Take it a Step Further...
In some instances, you might want to be a little more flexible or creative with this.
For instance, in one of my DNN portals, I needed to switch the Username with the e-mail address. This could only be accomplished by customizing the Membership Provider.
In doing this, the Display Name was now being overwritten with whatever the end-user originally entered as their Username. This in effect was creating an e-mail-based security mechanism, but allowed the end-user to maintain some anonymity by putting the username in the Display Name field.
Now, this was somewhat complete, but we do not want the end-users to have the same Display Names and we certainly do not want them to change the Display Name. So, by performing the steps above, I removed the ability to change the Display Name - with a twist!
Since I am changing the Display Name to a unique value and using it like a Username, I did not want the DNN Core to change the Display Name. I wanted to retain the value since I am managing it programmatically, but remove the ability for the end-user to manage it. So, I first needed to make a small modification to the core UserSettings module code-behind (~/admin/Users/UserSettings.aspx.vb). I found the offending code at approximately line 168 and commented out the following code block.
If key = "Security_DisplayNameFormat" Then 'Update the DisplayName of all Users in the portal Dim objUserController As New UserController objUserController.PortalId = UserPortalID objUserController.DisplayFormat = setting Dim objThread As New Thread(AddressOf objUserController.UpdateDisplayNames) objThread.Start()End If
Now, the Display Name is read-only. It is kept unique by allowing the Membership Provider to make sure (remember it was the Username at first), and the end-user does not need to remember their Username and e-mail address to maintain their login. They only need to remember their e-mail address. The Display Name now becomes an alias of sorts like how Live ID uses aliased usernames.