Add trim filter to first, middle and lastname.

[wardcapp]

A similar pull request was set up before (#11051), but has now been re-created (after accidentally deleting the branch that was to be merged, from my end).

Description

The additional trim form field data filter was created and added as
input filter to the firstname, lastname and middlename fields
of the customer_address and customer entities.

Fixed Issues (if relevant)

1. Customer First and Last names not being trimmed of leading and trailing spaces on save. #10415: Customer First and Last names not being trimmed of leading and trailing spaces on save.

Manual testing scenarios

1. Create a new customer from the Customers > All Customers > Create New Customer window
2. Create First name: "John " Last name: " Doe ", add a fake email address.
3. Click save
4. Search and edit the contact "John Doe "
5. Take note that the spaces are no longer in the users first, middle and last names. Same goes for the customer names set on the customer addresses.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

[wardcapp]

I noticed the PHP code sniffer failure and will address it one of the next coming days.

[wardcapp]

The required changes were committed, static tests should pass too this time.

[mzeis]

Hi, thank you very much for your contribution! I will process this PR and was wondering whether it might be a good idea to also filter other whitespace characters?

[mzeis]

Did you find a reason to not remove other whitespaces as done by trim() by default?

[wardcapp]

I could be wrong of course, but I indeed filtered ordinary spaces only on purpose, to make sure the trim-function remains strict (matching the expected behaviour stated within the original ticket) and to avoiding unwanted removal of other characters (for example, when text area inputs should accept and store newlines, but redundant whitespaces dropped).

Other than that, no real reason to deviate from the trim() default behaviour indeed :) Let me know if you'd prefer the default behaviour after all, I'll gladly correct the PR.

[mzeis]

Thanks for your explanation! Let's keep it like that for now. If demand shows we should trim for other whitespaces, this still can be done in the future.

[mzeis]

@wardcapp FYI: the Commerce Edition test suite has some failing tests that need to be adjusted to the change passes. I will tell you when this has been done.

[wardcapp]

Thanks for the correction and keeping me posted on this @mzeis! The latest changes you committed will probably have to be applied to the 2.3.x port of this PR (which is #13012) too (which I'm of course willing to take care of)?

[mzeis]

Yes @wardcapp, we will need them in #13012 too. It would be cool if you can add it!

[mzeis]

Hi @wardcapp, thanks again for your contribution! This has been merged into 2.2-develop.