Protect / help avoid validation logic problems

100% agreed with this, regex validators should be... validated, both indicating the format expected and preventing saving the wrong format. Or just removing the need to append the slashes.

I guess I had the same issue here...

Migrated several regex rules from D7 to D10 and wondered why they all erroring with preg_match(): No ending delimiter '^. But https://stackoverflow.com/questions/4634993/php-regular-expressions-no-e... provided the solution. The D10 module requires leading and trailing slashes!

Example - Telephone number validation:

D7:
^(?:(\+\d{1,2})\s(?:\(\d{1,}\))\s(?:\d+[-.\s]?+)\d{1,})$

D10
/^(?:(\+\d{1,2})\s(?:\(\d{1,}\))\s(?:\d+[-.\s]?+)\d{1,})$/

Is this an intentional change or a defect in the module?

If someone can make a MR for this bug it will really helpful...
I'm trying to make a 3.0.0 stable version soon.

I opened an MR for this: https://git.drupalcode.org/project/field_validation/-/merge_requests/25. Marking this needs review.

Invalid regex patterns (missing delimiters, malformed syntax) no longer leak a raw PHP warning. They're now caught and shown as a clean validation error instead.

How to test

1. Create a field validation rule using the Regex plugin.
2. Enter a pattern missing delimiters, e.g. (.*),(.*).
3. Try to save the rule, or run it against a field value.
4. You should see a clean validation error instead of a PHP warning.

MR !25 is merged. Tested end to end, looking good.

Thanks everyone for the work
DamienMcKenna for the original report,
ahmad-khalil-imagex for the thorough review, and everyone else who chimed in.