why fullname instead of first and lastname

How can I alter modx to allow users to enter a first name and last name separately.
Seems a bit strange to just have a fullname - is there a reason for this?

I’m also curious about this, and just linked to this thread on Twitter to try to garner some interest, or maybe learn of some alternatives people have tried.

Using the Login snippet in Revo, I’ve been unable to use custom fields only and not use the fullname field; the snippet doesn’t seem to work without it. I could split the fullname using output filters, but that seems like bad practice.

FYI: I also submitted this as a feature request for future versions.

+1 ^^^ This !

Rats! I just spent a half-hour writing a reply and the forum logged me out and lost it.

Here's the short version:

Legacy code. The modUser object has a username field, period. The modUserProfile object has a fullname field and no other name fields, so there's no standard place to put the information. The decision (mistake?) to leave them out was made a long, long time ago and I'm not sure anyone can explain the thinking behind it.

Some workarounds:

1. Write a plugin that saves lastName,Firstname to the fullname field when a user is saved and a plugin to add those fields to the Create/Edit user form. Pull them out with an output modifier that parses the fullname field. You might have to modify the Tpl chunks for extras that use the fullname for something.

2. Create them as Extended Fields in the User Profile. This makes for slow and cumbersome searching for users and sorting them.

3. Co-opt one or two unused fields in the User Profile (e.g. fax, website, etc.). This makes searching and sorting fast and easy. If you use one field, you can separate the first and last names with a delimiter, e.g. Ray#Bob and parse them when you retrieve the names. Using two fields is better for searching and sorting. I'm not positive, but I think they'd be available with "userinfo" placeholders in this case:



4. Subclass the modUserObject and add those two fields. This might be the best solution, but it's the most difficult to set up. Searching and sorting is fast and easy, and any extra that uses toArray() to set its placeholders (many do), will set the placeholders for you. Some user-related extras might not work since they don't allow you set the alias of the user object.

Wherever you put them, you can use a plugin attached to OnWebPagePrerender to retrieve the two names and set the placeholders for you. That way, they'll be available anywhere in the front end, but page loads will be a few milliseconds slower.


There is no completely satisfactory solution that I know of.

Actually that's legacy from the original Etomite days, so you'd need to ask Alex Butter about that. Etomite didn't have any "web user" provision at all, so the MODx extensions for Etomite used the same user structure for web users as the core did for manager users. And that's why Evo has two distinct types of users.

Bob and Susan are correct about the legacy fields. We likely won't be doing anything about that in 2.3 but we certainly may visit this in 3.0. Could you detail how you'd personally like to use the First and Last name so we could better help you find a solution for your use case?

That being said there are all sorts of strategies and pitfalls surrounding this. One positive is that when asking people their full name it's one less input field and people, no matter what their culture will know what to put in that field. You can see from the discussion here: http://ux.stackexchange.com/questions/37544/can-i-reformat-personal-names-obtained-from-a-single-form-field that there are problems. No matter what happens in a future version of MODX, we're going to have to compromise as MODX is used internationally and there are cultural usages that first last doesn't address.

I, personally lean to programmatic methods to guess which is which for front end forms. We use this method for subscribers of the MODX Insider who opt in when registering at modx.com using Register with a post-hook. I am sure we miss for a good number of them but it works most of the time to capture First/Last to map into MailChimp. You could do something similar but reverse by using custom user fields for first and last on your form and then use a post hook to merge them for the fullname field if that's a route you'd want to take.

It's definitely a worthy discussion as we're looking for huge usability and user experience improvements for 3.0.