Provide the ability to specify the flags for RegExp in content fragment models for custom validation regex.
This can be a mulit-select combobox offering the following flags:
global
insensitive
multiline
single line (dotall)
unicode
sticky
(screenshot attached, add combobox under custom regex with these options, that would simplify the regex and enable new possibilities)
Use-case:
We have 2500+ clients that we serve using multi-tenancy. We are using content fragments and headless to deliver that content. We have contractual obligations with a major client that requires us to provide a completely white-labelled experience, from logos to copy. This means that there can be no mention of my company name anywhere in the content. Violations carry a $5M fine.
Current/Experienced Behavior:
Today, it is not possible to specify these flags, so handling things such as case sensitivity is unmanageable, and matching patterns across multiple lines is impossible.
(screenshot attach of a hacky, unmanageable regex that only works on single lines)
Improved/Expected Behavior:
Adding this additional field, and reading it in the new RegExp constructor on the front end will provide the validation necessary to prevent content authors from accidentally creating a violation. (screenshot attached - add second argument toRegExp with flags)
Environment Details (AEM version/service pack, any other specifics if applicable):
@Kinbaum , thank you for the very detailed request. Makes sense. Hasn't come up before but understood. To confirm, general request is to support regex flags, right? Meaning if we wanted to avoid UI complexity (multi-select combo boxes), supporting adding flags in the current regex field in content fragment model editor, with defined and documented syntax, like abc/ig for adding flags i and g, that might suffice, right?
This has been reported to the engineering under the internal reference SITES-26021. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to Jira's status.
We are aiming for a delivery by January 1, 2025, and it is crucial for our year-end goals.
Could you please provide an update on the current status? We would greatly appreciate it if this request could be prioritized to meet our timeline. Thanks!