Example: Both are counted as unique
Hello World Hello WorldI know we can probably avoid this with a regex pattern and apply that pattern to “Must match a specific pattern” option, but I would have thought the unique check would trim before comparing. Why would you want a leading/trailing space to be considered unique?
@jearle interesting question here, hmm. I see your point. We probably did not mean to intentionally make surrounding whitespace significant, but now that it’s there, we probably don’t have the liberty to revamp that behavior and add “magic” to an existing field. We probably couldn’t force-trim it, either on validation check or as an actual record update, across the existing single-line strings. It would be a breaking change across all the affected records.
Even if we made it an opt-in project-level setting, it would be a pretty big change requiring a lot of before/after testing — pretty high risk for a feature nobody else has asked for, at least in recent memory 
However (as a feature request), maybe we could add a UI-side option to those fields, like “Trim whitespace before and after the text” that just trims the field editor on blur? It’d be a UI-only fix in case editors accidentally added whitespace, but it wouldn’t fix any API-based workflows. Would that help at all? Or if you needed it sooner, I could write you a plugin that does the same thing.
On the other hand, if this is a systemic problem in your entire dataset… if you need to normalize the existing records already there… that is a much bigger job It would potentially affect the validity and thus publication status and relationships of all the affected records… let me know the scale of the affected model here and I can ask our devs if there’s anything we can do to help?
(or, instead of doing it only in the UI, we could also trim() on the API side — but still only for new record updates)
I think doing it on the API side makes the most sense. Assuming that means it’s an option in the model schema like you mentioned before and that by doing this on the API side, it would take care of new record updates that occur both in the UI and via the CMA?
I do have some normalization I’m having to work through, but I’m working on that myself. Was just hoping for a solution besides having to apply a regex on all of the fields that matter.
Understood, thank you! I classified this as a feature request and I’ll let you know if we’re able to implement it.
Sorry @jearle,
The developers evaluated this situation/request and decided not to implement it for the time being It wasn’t the answer I hoped for — your request made sense to me — but I wanted to at least give you an update rather than leave you hanging.
If the UI-only plugin trim would help, let me know and I can write you one.
Sorry about that!
I’ll leave the feature request open, though, in case it picks up more steam in the future and gets reconsidered.