Last Name field w/ User Integration - multiple words and letter casing

[vonscriptor]

Two problems here:

1. If a last name value like: "Sanchez Maselli" is saved "Sanchez" is removed.
2. A last name value like : "Van Holtz" is saved as "van Holtz" losing its title case.

Is there a name parser that Freeform uses that is trying to normalize the names?

Steps to reproduce

1. Create a form with a text field that uses a User integration to a user's last name field.
2. Enter in a value like "Sanchez Maselli". "Sanchez" will be lost.
3. Enter in a value like "Van Holtz". The uppercase "V" in "Van Holtz" will be lowercased.

Expected behavior
The full last name should be saved.
The letter casing should be kept.

Craft & Plugin Info (please complete the following information):

• Craft Version: Pro 4.8.6
• Freeform Version: 5.1.8
• Freeform Edition: Pro
• Fresh Install or Upgrade: Fresh

Additional context
I created a similar issue thinking this was a Craft issue, but it's not after additional testing and feedback from Brandon.
Reference: craftcms/cms#14723

[kjmartens]

Hi @vonscriptor,

Freeform doesn't add any extra validation or transform steps to that data. I believe this is Craft doing it, as their documentation references that they have a name parser.

In my testing, initially I couldn't duplicate the issue, but I am using the default where the control panel just shows the Full Name (which is what it seems Craft is moving to). However, once I enabled showFirstAndLastNameFields config item, I could see that things like Van Holtz were switching to van Holtz, and that Sanchez Maselli was switching to Maselli.

You should check with the Craft Team on this one if it's expected behavior or if there are options to control it. I do see a setting like extraLastNamePrefixes, which might help in the van situation. 🙂

• https://craftcms.com/docs/4.x/config/general.html#showfirstandlastnamefields
• https://craftcms.com/docs/4.x/config/general.html#extralastnameprefixes

[vonscriptor]

I already reached out to Craft about this (see the additional context issue link above). When using Craft's front-end registration form example and using first and last name fields with showFirstAndLastNameFields it works properly as Brandon states. The Formie plugin also handles this correctly. So it would seem something is happening during Freeform saving the value.

Using extraLastNamePrefixes solves the Sanchez Maselli problem, but it will force the case to whatever is set where if you add "Van" then you're unable to also support "van" (both casings are needed in surnames).

[kjmartens]

Sorry for the delay @vonscriptor. I can't imagine why Freeform would make any attempt to convert Van to van, but I will check with a developer to confirm. 🙂

[gustavs-gutmanis]

Hi @vonscriptor,

I went through everything with XDebug to see what causes the name change, and it happens on the \craft\elements\User::afterSave() method, which gets called by Craft's Elements service's save() method.

In it, it calls a prepareNamesForSave() trait method, which runs the submitted name through a parser, and comes up with van Holtz from the Van Holtz that was input by me.

I don't see Formie handling anything special when dealing with names, maybe the problem lies in the way Freeform prepares the names. We have had issues with names before, so in the end, a solution was to generate a User's fullName from a supplied firstName and lastName if any of them were mapped instead of fullName.

This is achieved with this part.

if ($isFirstnameMapped || $isLastnameMapped) {
   $user->fullName = trim(trim($user->firstName).' '.trim($user->lastName));
}

When I supply Gustavs as firstName and Van Holtz as lastName, the resulting fullName becomes Gustavs Van Holtz. Which is correct, it should be that.
Then, when the Element is being saved, Craft kicks in with the name parser, and normalizes Van to van

Here is the normalizer,

Here are the values it generates

The resulting firstName and lastName values are these:

I'm not entirely sure how we could solve this on our end...

[vonscriptor]

Good news, @kjmartens and @gustavs-gutmanis—with this information Brandon was able to find the issue and will be pushing up a fix in the next release. Thank you for the deep dive into this!

Reference: craftcms/cms#14723

[kjmartens]

Thanks for letting us know @vonscriptor 🙂