Server/Client side validation of textfields behaves inconsistent

[NorbertH]

Here is the test case (all happens in BE):

•  Create a text field.
• Add the HTML5 pattern for using only lower letters :
  [a-z]+
• Add it to a template and page you like .
• Open that page for editing

 

Writing "aafdfdf" to the field HTML5 will let you save the field .
Writing "asdsdsA%&%" lets HTML5 stop you from sending the form .

 

• Now deactivate HTML5 validation. In firefox use this Plugin:
  https://addons.mozilla.org/de/firefox/addon/defyformvalidation/

 

Writing "aafdfdf" to the field PHP will let you save the field .
Writing "asdsdsA%&%" lets  PHP still save the form!!!

 

I checked the module code but serverside validation seems to be in place. 

 

Comparing the two regex variants it seems like the HTML5 pattern allways behaves like it starts at the beginning of the line and ends at the end of the line.  In PHP preg_match() a pattern that behaves like the HTML5 counterpart would look like this: 
^[a-z]+$

 

Whats your experience whith this ?

Wouldn't make it sense to add those "^...$" as hardcoded value in the inputfield module?
There are lots of limitations in HTML5 patterns, wouldn't it be  even better to add a second field for serverside regexes.?

 

Especially the extremely limited utf-8 support leaves the pattern almost useless in international enviroments (eg. \w will only work for a-zA-Z).

 

Wouldn' it be great to have selectable  sanitation/ validation functions , like we allready have whith textformaters?

 

 

 

[Robin S]

1 hour ago, NorbertH said:

Writing "asdsdsA%&%" lets  PHP still save the form!!!

I don't think this behaviour is related to the pattern that is used. When a field is set to "required" or with some validation rule then PW gives feedback to the user when the field is not submitted in the correct state but it saves the form regardless. Client-side validation prevents form submission but this is a browser feature not a PW feature. The PW behaviour is deliberate and @ryan has explained the rationale behind it somewhere - I can't find it at the moment but maybe someone else will chime in with a link.

Perhaps Ryan would be open to having an option to restore the previous value in case of failed validation, seeing as that option exists at the template level for required fields. You could make a request at GitHub.

Also see Soma's hook solution:

 

[NorbertH]

1. There is a validation in place in the input field that throws a message when the pattern is not matching :

(from inputfield_text.module)

if($length > 0) {
			
			if($this->pattern) {
				$regex = '#' . str_replace('#', '\#', $this->pattern) . '#'; // add delimeters
				if(!preg_match($regex, $value)) $this->error($this->_('Does not match required pattern'));
			} 
			
			if($minlength > 0 && $length < $minlength) {

2. The problem is that HTML5 pattern behaves different from preg_match() , it always behaves like the regex would start at the beginning of the line and stop with the end .
if you use the pattern "^[a-z]$" in your pattern field you get correct results. HTML5 ignores "^" and "$" but always behaves like that and preg_match() is happy with those line start and line end signs.

3. So possibly it would be a good Idea adding them hardcoded:

$regex = '#^' . str_replace('#', '\#', $this->pattern) . '$#'; // add delimeters