Close #13403?

While this PR goes into that direction, I don't think that that is solving #13403. So no, not closing that one.

In addition, a input is added to customize the error message when the validation failed.

This appears to be when ANY validation fails and not when a specific field's validation fails?

In addition, a input is added to customize the error message when the validation failed.

This appears to be when ANY validation fails and not when a specific field's validation fails?

No, the message is displayed only if this specific field fails to validate.

My comment was because I saw the following settings

So I assumed that you could set the message in the plugin itself. But you can not.

When you have a required field then a failed validation results in an error as shown below

I would expect that when you have a failed vaildation rule you would have a similar error but you dont

I deleted the last weird behaviour post as there was an error in my recording

Yes, you can argue that a required field and a field which failed validation should both throw a similar style error. However that is not in the scope of this PR. The behavior you are describing is the general behavior of Joomla and would have to be changed in another PR.

Regarding the overriding of plugin settings: Right now this PR is a draft for a reason. ?

The behavior you are describing is the general behavior of Joomla and would have to be changed in another PR.

well that amongst all the other issues makes it a big fail for me and definitely not something for core with this approach

That however has nothing to do with this PR and is a standard behavior of Joomla so far. Be my guest to change that, but right now this is how field validation works in our core library.

Please follow the style guide for the language strings https://manual.joomla.org/docs/next/user-interface-text/capitalisation

Did I miss anything else regarding capitalisation?

That however has nothing to do with this PR and is a standard behavior of Joomla so far. Be my guest to change that, but right now this is how field validation works in our core library.

You are quite correct. I hadn't noticed this before as it is never used (as far as I can see) in core at the moment. The non-highlighting of the invalid fields is however an accessibility fail.

That however has nothing to do with this PR and is a standard behavior of Joomla so far. Be my guest to change that, but right now this is how field validation works in our core library.

You are quite correct. I hadn't noticed this before as it is never used (as far as I can see) in core at the moment. The non-highlighting of the invalid fields is however an accessibility fail.

Actually, that's what my report back then was about: #13403 :-)

And this PR just makes that situation worse and not better

no, its about to solve it

Hey @Hackwar I see what you try to solve here and thanks for the contribution.

Nevertheless, we should not encourage people to use text fields for everything, for URL + Tel we have the URL field, for email we should create an email custom field etc. Text should not be the jack of all trades device.

Plus all the issues Brian reported.

Conceptwise this PR needs a lot of improvement to be considered as mergeable in my opinion.

(PS: Clientside validaton would be a really nice to have, too as HTML offers this anyways)

All issues Brian has reported have either been fixed or are unrelated to this PR. Of course we can discuss if a validation error should throw a notice or an error and I'm all for an error here, but that is not the scope of this PR.

Regarding the selection of validation rules, I can definitely remove some of those again. Yes, the text field is not meant to cover everything. So I would remove email, tel and url again?

Client-side validation is also a nice-to-have, but again outside of the scope of this PR. It is something that would require a change to the Form package and not an additional field in the custom field system.

If we're going to add something then it should be done holistically and not introduce/expose issues that are left to be solved elsewhere (if ever). We have a terrible habit of merging code that is knowingly incomplete. If we are serious about accessibility then we should never merge code that is knowingly introducing accessibility issues. Accessibility is always in scope.

PS I am all in favour of form validation but it must be done right

I removed the controversial validation rules again.

Conceptwise this PR needs a lot of improvement to be considered as mergeable in my opinion.

but no changes to the conceptual approach?

#42959 changes the validation everywhere from throwing a warning to throwing an error on the server side.

I don't know how we could highlight the fields after the serverside validation.

I would say that the server validation should be always combined with the client-side?! so the field highlight is done by client-side anyway. Without client side validation, this does not make sense.

The problem is, that right now we get error messages about failed validations, but not the names of the actual fields after the server side validation. We would have to extend the errors by that field name and then somehow render that in the frontend.

Why do you need to validate on the server to comunicate to the user, when you can first validate client-side and then after submission valide server-side?

I mean, we have the "pattern" attribute für html input elements which we could use as client-side validation and the field is then marked red.

What it needs then are some improvement on the server-side validation, which should be aligned with the html5 pattern.

then we have both with little effort.

finaly someone gets it!!

This pull request has been automatically rebased to 5.2-dev.

I have tested this item ✅ successfully on e58469c

@crimle you have marked that you have successfully tested this. How? What where the regex you used? What were the comparisons you used

@crimle you have marked that you have successfully tested this. How? What where the regex you used? What were the comparisons you used

I successfully tested the existence of the added dropdown «Validate» and the option «Maximum lenght». Both are ok.

I did NOT test the «Regular Expression» option since I am not familiar with regular expressions. I retested this morning and had an eye on the options «Not Equal to field» and «Equal to field». They seem to have no effect. Ashes on my head, - I was not conscientious enough yesterday. Sorry!

This pull request has been automatically rebased to 5.3-dev.

@crimle can you open https://issues.joomla.org/tracker/joomla-cms/42911 and

• click button "Test this"
• mark "Not tested"

The test will not longer count as successfull.

I have not tested this item.