[6.0] Fields: Add validations to text custom field #42911
Conversation
|
Close #13403? |
|
While this PR goes into that direction, I don't think that that is solving #13403. So no, not closing that one. |
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. 😉 |
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? |
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) |
… 5.1-fields-regex # Conflicts: # administrator/language/en-GB/plg_fields_text.ini # plugins/fields/text/params/text.xml
|
I removed the controversial validation rules again. |
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 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/42911. |
|
@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
The test will not longer count as successfull. |
|
I have not tested this item. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/42911. |
|
This pull request has been automatically rebased to 6.0-dev. |
Summary of Changes
This PR adds serverside validation to the text custom field. It doesn't add it to any other field since the text field is the only one where this makes sense. You get the validation rules which are part of the libraries folder together with conditional fields available to configure them where usefull. In addition, a input is added to customize the error message when the validation failed.
Testing Instructions
Create a custom field of type text and play around with the validation option which this adds. Test inputs in the frontend.
Thanks
A big thanks goes to @coolcat-creations (Website) who sponsored this PR.
Link to documentations
Documentation is going to be provided soon.
Please select:
Documentation link for docs.joomla.org: https://docs.joomla.org/J3.x:Adding_custom_fields/Text_Field
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed