Hello Hannes,
I've tested it, but I don't know if I understood it correctly:
You have to select something in the Advanced tab under Layout and enter a value with mutated vowel. I can't change the values there, so I created another file for Layout with üüü and then selected that. Then I got the error message. Then I changed the corresponding code in the mod_custom.xml file and selected üüü again and the error message appeared again, but the other values could be saved.
If I have understood correctly, then the test was successful.

Thanks @webnet-assmann. Yes, that would be a successfull test. The goal was to show that the regex validation rule properly functions, regardless if we use the specific rule for moduleLayout or if we copy the regex from there into the XML.

Tested successfully

Tested successfully

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/42657.

@webnet-assmann Could you mark your test result in the issue tracker so it’s properly counted? Just go to https://issues.joomla.org/tracker/joomla-cms/42657 , use the blue „Test this“ button at the top left corner, then select your t st result and submit. Thanks in advance.

This really needs sopme documentation please

I have tested this item ✅ successfully on 70a3a53

Tested successfully

What would be the right place to add the documentation before the PR is merged?

but no way to hand in a regular expression via the form definition.

Is that really correct? You can use html5 pattern already and from what I can see it does the same thing and is something we already use. What does this offer that is different?

For example:

• Email Filtering: Exclude specific domains (e.g., block freemail accounts). For example exclude gmail and web.de
• ZIP Code Validation: Ensure format consistency for different countries. For example 5 Numbers in Germany
• IBAN Validation: Validate international bank account numbers.
• Telephone Numbers: Accommodate country-specific formats and codes. For example +49 170 1234456 against (0170) 1234456
• Social Security Numbers: Validate format based on country-specific standards.
• Vehicle License Plates: Match specific national or regional patterns.
• Currency Formatting: Ensure correct currency symbol and format.
• Time Formats: Validate time in various international formats in a text field For example: 10.00–18.00 Uhr
• Postal Address Formatting: Check for country-specific postal address formats.

@coolcat-creations All of that is already possible using pattern (https://www.html5pattern.com/) or am I missing some big difference that requires this extra code

@brianteeman html5 attribute "pattern" is client side, what is in PR is server side.
It is probably possible to use the same pattern for both client and server (and so simplify the field set up), but I did not tested such thing, cannot say for sure.

@Fedik is that enough to justify this. Seems overkill to me to add this as its almost duplicate functionality

Seems overkill to me to add this as its almost duplicate functionality

Well, yes and no.
You know, you cannot rely on client side validation, never.

agree when it is security related such as with a password but in these examples client side is much faster and provides a better user experience

@brianteeman I'm happy to discuss improvements on the client side in the future, but we need server side validation and this is such a server side validation. If you want to get rid of duplicate functionality, we could rather talk about removing the validation rules we have right now which only contain such a regex. However, there are good reasons for providing even such basic rules like Boleean or ModuleLayout.

agree when it is security related such as with a password but in these examples client side is much faster and provides a better user experience

We basically need both. Server side is always going to be required regardless (if nothing else we have an API still to maintain which can't do HTML5 validation). Many of the security issues we had in 3.9/3.10 were people intercepting requests from forms to the server and then making further modifications because we weren't doing proper server side validation (only client side). For regex things it's hard to say what the business implications might be - but I'm sure there's going to be some business cases things like phone numbers might be required.

TLDR: I think this is fine - combining the server and client side regex together into a single field if provided definitely a nice to have though.

I have tested this item ✅ successfully on 70a3a53

RTC

I added documentation for all validation rules to the manual. Hope that is enough like this.

Thx