Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

form validates the wrong date format #5238

Closed
magicsepp opened this Issue · 14 comments

3 participants

@magicsepp

Hi Leo,

setting the site structure - global settings on the demo to german format by using d.m.Y etc. produce anyway a "Please enter the date as "YYYY-MM-DD"! warning on a mandatory date check text field.
For reproductioon go to site strucure and set the global settings to
Date format: d.m.Y Time format: H:i and finaly Date & Time to D.m.Y H:i
Add a mandatory textfiled with date check to the form generator "Term paper submission"
now you can enter a name and an email adress anf f.e. 01.01.2013 to the new date filed and press submit....
The expected behaviour should be a check for d.m.Y as entered in the ste structure.

Thanks a lot

@leofeyer
Owner

Site structure = front end, back end settings = back end.

@leofeyer leofeyer closed this
@magicsepp

So the question is why doesn't the front end settings not work in the front end??

@xchs

I tracked this down as follows:

  • The date/time format given in the error message you get ( Please enter the date as "YYYY-MM-DD"! ) relies on the system default settings or – in case you changed the global date and time settings in the back end system settings – on those values you've set there (and which are written to system/config/localconfig.php and override the default presettings)
  • The regex input validation for date and time formats is done in the Widget and Date classes:

To cut a long story short, the form input validation relies on the back end system settings. Therefore, you would have to set the preferred date/time format there.

Anyway, I agree that for multilingual websites this could lead to some confusion.

@leofeyer leofeyer reopened this
@leofeyer
Owner

Fixed in a7cdf43.

@leofeyer leofeyer closed this
@leofeyer
Owner

Nope, that was wrong. You cannot use the front end date format, because the front end supports textual date formats which the back end cannot handle. Will have to revert this change.

@leofeyer leofeyer reopened this
@leofeyer
Owner

Reverted in 2576ef9.

@leofeyer leofeyer closed this
@xchs

Since you reverted the changes: does this mean that the mentioned issue in this topic still exists? That is, we get on an English page of our multilingual web site the error message "Please enter the date as "DD.MM.YYYY"!" if the global date/time system settings in the back end is set to $GLOBALS['TL_CONFIG']['dateFormat'] = 'd.m.Y';, right?

@leofeyer
Owner

True, but is this so much of a problem?

Another possible workaround was to check whether the front end date format is numeric and only fall back to the back end date format if it is not. But we can also ask the user to enter a date in a different format than it is output, can't we?

@magicsepp

Asking for a diffrent format is not user friendly

@leofeyer
Owner

Asking for a diffrent format is not user friendly

I do not agree at all. If a date is shown as "February 24th, 2012", it is a lot more user friendly to allow users to enter the date as "2/24/12" than to force them to enter the textual version.

@magicsepp

Leo, for such a case you are right. For such a format the template can be used to show a more readable date.
However for a german formated date d.m.Y an input with f.e. "YYYY-MM-DD" is confusing, isn't it?

@leofeyer
Owner

That is why I pointed out a possible workaround above.

@leofeyer leofeyer reopened this
@leofeyer
Owner

Fixed as discussed in 000659b.

@leofeyer leofeyer closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.