"US Phone" and "US Zip Code" regex-validation presets are malformed — causes unhandled exception on save

Summary

The built-in "US Phone" preset for a field's Regex Validation property is malformed — it is missing escape backslashes and is not valid regex syntax in either JavaScript or Java. As a result, phone-number validation using this preset does not work as intended, and saving a contentlet through the legacy Edit Content screen throws an unhandled server-side exception instead of a normal validation error.

Where the bug is

core-web/apps/dotcms-ui/src/app/portlets/shared/dot-content-types-edit/components/fields/content-type-fields-properties-form/field-properties/regex-check-property/regex-check-property.component.ts:68

value: '^(?[1-9]d{2}[)-]s?d{3}-d{4}$'

Every \d, \s, \(, \) is missing its backslash. The correct pattern is:

^\(?[1-9]\d{2}[\)-]\s?\d{3}-\d{4}$

The "US Zip Code" preset in the same file (line 62) has the identical defect:

value: '(^d{5}$)|(^d{5}-d{4}$)'

Steps to reproduce

1. Create (or edit) a Text field on a Content Type.
2. Set Regex Validation to the "US Phone" preset.
3. Edit a contentlet using that field via the legacy (non-UVE) Edit Content screen.
4. Enter a value, e.g. 123-4567, and Save.

Actual behavior

• No client-side validation fires at all. In edit_field.jsp:184, dojo's dijit.form.ValidationTextBox (which wires up a client-side regExp) is only applied to Number/Float/Hostname field types — a plain Text field with a custom Regex Validation preset renders as a plain dijit.form.TextBox with no client-side check.
• Enforcement happens only server-side, on Save, in ESContentletAPIImpl.validateContentlet (dotCMS/src/main/java/com/dotcms/content/elasticsearch/business/ESContentletAPIImpl.java:8250-8271), via Pattern.matches(regext, s) with no surrounding try/catch.
• Because the "US Phone" string itself is invalid regex syntax, Pattern.matches throws an unchecked java.util.regex.PatternSyntaxException:

  java.util.regex.PatternSyntaxException: Unknown inline modifier near index 3
  ^(?[1-9]d{2}[)-]s?d{3}-d{4}$
     ^
  

  (Verified directly by running the exact string through java.util.regex.Pattern.matches in a standalone JDK 11 test.) This exception is unchecked and uncaught, so it escapes validateContentlet (which only declares throws DotContentletValidationException) as an unhandled runtime exception — instead of the normal, friendly "field does not match pattern" validation message (DotContentletValidationException.Builder#addPatternField) that a correctly-formed regex would produce.
• The same malformed string also fails to compile as a JavaScript RegExp (new RegExp('^(?[1-9]d{2}[)-]s?d{3}-d{4}$') throws SyntaxError: Invalid regular expression: ... Invalid group), so any newer editor surface that constructs the pattern client-side (e.g. Angular reactive-form validators) also fails to apply real validation for this preset.

Expected behavior

Entering a value that doesn't match a valid US phone number format should show a normal, graceful field-validation error — not an unhandled exception.

Confirmed workaround / fix

Manually editing the field's regexCheck value to the correctly-escaped pattern:

^\(?[1-9]\d{2}[\)-]\s?\d{3}-\d{4}$

resolves the issue — the field validates phone numbers correctly with no exception.

Suggested fix

1. Correct the "US Phone" and "US Zip Code" preset regex strings in regex-check-property.component.ts to include the proper escape backslashes.
2. Wrap Pattern.matches(regext, s) in ESContentletAPIImpl.validateContentlet with a catch for PatternSyntaxException, so that any malformed regex (built-in preset or custom) produces a graceful field validation error instead of an unhandled exception on save.

Environment

• dotCMS version: 26.08.19-04
• Confirmed against current dotCMS/core main branch source (as of 2026-08-21).

Relevant links.

https://dotcms.freshdesk.com/a/tickets/38972

Start in core-web/apps/dotcms-ui/src/app/portlets/shared/dot-content-types-edit/components/fields/content-type-fields-properties-form/field-properties/regex-check-property/regex-check-property.component.ts, then inspect edit_field.jsp and ESContentletAPIImpl.validateContentlet. Verify the preset strings in JavaScript and Java, and reproduce the save path with the legacy Edit Content screen. Done means both presets compile and invalid patterns produce a normal field-validation error rather than an unhandled exception.