Use single field for user names

[michaelrog]

Given the wide diversity of name schemes across various cultures, Craft's use of firstName and lastName is a bit too opinionated.

I think I'd prefer — and others have mentioned this, too — that Craft use a single name field.

Then, combine this with methods (and event hooks) for accessing a preferredName (the full registered name, with any project-defined alterations) and friendlyName (how this project addresses a user in first-person UI). (Absent any custom-defined interventions,friendlyName would default to null, and preferredName would default to the full registered name.)

This way, it's up to each dev how to best handle names according to the context, customs, and needs of their project.

(I frequently use the name-parsing functions in the Wordsmith plugin to handle this on my projects. For example, if I want to sort by last-names, I could create a read-only/Preparse field to auto-populate with {{ user.name | surname }}, which then allows me to .order('alphaName asc') in my user query.)

As a convenience, it may be preferable to allow user registration controllers to accept either a single name field, or an array of names. That way, a dev could separate those fields in front-end forms if it makes sense for their audience, and even grab the separate values for their own purposes via events, before Craft ultimately concatenates them into the single name field saved on the user.

(System email templates that rely on the assumption of a first/last name should probably get updated to use a full name, or a salutation without a name.)

[brandonkelly]

I don’t want to lose the ability to sort users by their last name, so completely dropping the first/last name separation isn’t really an option.

Instead I think we should be adding more columns: title, middleName, nickname, suffix, and surname (surname == lastName, except without the suffix, to resolve #9398).

Then we can update the Edit User page UI to show a single “Full Name” input, which uses parse-full-name to parse and store the individual components in respective hidden inputs for the controller. The UI should also have the ability to show an expanded view with visible inputs for each of the components. (And default to the expanded view if we can predetermine that the library isn’t able to parse a combined full name accurately.)

That would give us the best of both worlds: a simple Full Name field, automatic component parsing, storage, and sorting.

[michaelrog]

Many columns, many assumptions... Feels like schema bloat to me.

Admittedly, I can see a common use-case for sorting, and sorting by surname is probably (by far) the most common scenario. I still think Craft doesn't need to make too many assumptions...

I guess if you want more columns, name, friendlyName, sortName make more sense to me. Then, you can:

• try to auto-derive friendlyName and sortName on first edit (similar to UI for title slugs)
• expose events to let devs do something different if they want
• hide the UI for these columns behind a toggle switch and/or config default
• end up with a much simpler (more maintainable) UI than if you tried to account for every name part in every use case ever.

(Admittedly, I wonder whether sortName or surname makes the most sense in practice... In my projects, I'm usually using a sort name as an internal value, not for UI, so I don't care to call it a "surname" — and in fact sometimes it isn't. But I don't assume that my use cases are normative...)

[brandonkelly]

Alright this is resolved for Craft 4 (#10624). Decided against adding all the extra fields, but keeping First/Last Name around viewing/sorting on user indexes.