Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Before updating to v1.37 (from 1.36) date_popup fields were correctly validated. In v1.37, no date is considered valid.
Consider a date_popup field that is created via the FAPI like this:
$form['date_donated'] = array(
'#type' => 'date_popup',
'#date_format' => 'm-d-Y',
'#default_value' => date('m-d-Y H:i:s', REQUEST_TIME),
'#required' => true,
),
No date is considered to be valid. I am using v7.x-2.6 of the Date module, of which the date_popup is a part.
Comments
Comment #1
attiks CreditAttribution: attiks commentedI'll ask Jelle to have a look tomorrow
Comment #2
Jelle_SFixed in the latest dev version. The reason of the bug was that we did a parseInt() of each value (day month year) and then checked the format of the parsed value. So if the format was 01/02/2001, it would look like this after the parseInt()'s : 1/2/2013 which wasn't considered valid according to the format (missing leading zero's).
Can you confirm the fix? (wait 12 hours for d.o to sync with git or get the latest dev directly from git)
-> feel free re-open if it isn't fixed on your side
Comment #3
mpgeek CreditAttribution: mpgeek commentedI'm using Scheduler with a date popup, and I cannot get past the validation. I have month names instead of numbers and disabling this module gets me past validation. Digging deeper at the moment.
Comment #4
attiks CreditAttribution: attiks commented#3 Did you try the latest dev version?
Comment #5
mpgeek CreditAttribution: mpgeek commentedYep. I'm on 1.37+8. It turns out that using month names ("F in format string) in the date popup are not quite fixed with the latest. I have a working patch that fixes it for my use case, but I am not sure that it doesn't break any other use cases.
Comment #6
mpgeek CreditAttribution: mpgeek commentedOops, forgot the patch. Here you go. I'm guessing it could use a little massaging to be more general, but it addresses the monthpos == false problem with "F" in the format string.
Comment #7
attiks CreditAttribution: attiks commentedWe need a way to support multi lingual sites, so we need to know the right strings from the PHP side, so they can be used on the javascript side. This line will pass the input directly to Date and isn't probably going to work in all languages.
Comment #8
mpgeek CreditAttribution: mpgeek commentedIs this as simple as using Drupal.t in JS? Or is there more to it?
Comment #9
attiks CreditAttribution: attiks commented#1886424: Date validation fails when text is used instead of numbers added Drupal.settings.clientside_validation_settings[] added a mapping from month names and abbreviations to month number, but I didn't had the time to test it
Comment #10
mpgeek CreditAttribution: mpgeek commentedI followed the design pattern in #1886424: Date validation fails when text is used instead of numbers, so if it works there, it should work here. I didn't have time to test multilingual either, but I assumed mapping a month names from different languages would "just work" and produce the correct number. IF that is not the case, then we have a new can of worms.
Comment #11
mpgeek CreditAttribution: mpgeek commentedHere is an updated version that works with both full and abbreviated month names in the format string. I also had a problem with February dates that was a brain breaker. It turns out that setting the day, then month, then year (as opposed to the opposite order) fixes February-based validation errors. This seems to be due to the offset numerical days in February, I have a hunch this is related (or the re-ordering might even solve) #1902840: Date validation fails when days overflow..
I have not tested multilingual month names in this version.
Comment #12
MiroslavBanov CreditAttribution: MiroslavBanov commented@mpgeek
Setting the Day, then Month, then Year will fix the issue that happened when the current Day is 30 or 31 - any Month, and you try to validate a February date. But now the Month is February, so try to validate a date with any Month, where the Day is 30 or 31, using your version with the changed orders. Please look again at http://drupal.org/node/1902840, I updated it for greater clarity.
Comment #13
vbouchetHi all,
As expecting the new dateFormat validation function from -dev works properly. Because I don't want to use a dev version on my website and can't find a patch containing only the new validation function (sorry if I missed that) I create a quick patch to replace 1.37 function by -dev one.
Comment #14
webdrips CreditAttribution: webdrips commentedThe patch in #11 didn't fully apply to the latest dev version. Let me see about re-rolling.
Does this patch fix the issue with the scheduler module "The value in Date is not a valid date."?
Comment #15
Jelle_S@webdrips Did you get a chance the reroll yet?
Comment #16
webdrips CreditAttribution: webdrips commentedSorry totally forgot...this reroll of #11 seems to work with the latest dev.
Comment #17
Jelle_SThe patch doesn't seem to apply, can you make sure you have the latest version from git? And can you generate the patch form within the clientside_validation module's folder? Also could you remove the trailing spaces. Besides that, patch looks good.
Comment #18
webdrips CreditAttribution: webdrips commentedOkay but now not sure of the first couple changes; let me know and I'll remove them if needed.
Comment #19
Jelle_SThese changes would revert previous commits so they should be removed from the patch.
Comment #20
webdrips CreditAttribution: webdrips commentedHopefully third time's a charm...sorry I should have just re-rolled the patch when I said I would.
Comment #21
Zahak CreditAttribution: Zahak commentedHi there,
I had trouble with validation of dates, and was very happy to discover that it seems to work with the dev version (tested on my test environment). However I feel that it is a bit shaky to use the dev version live. Is there any plans for when next version is going to be released?
Comment #22
zulfierken CreditAttribution: zulfierken commentedI have the same problem as well. When I use February month in field with date popup it says the value in date is not a valid date. Other months work well. Should I use dev, wait for release or hack it?
Comment #23
Jelle_SPatch from #20 committed. Sorry it took so long.
I'm doing my best to clean up the issue queue. This fix will be in the next release.