Tokens don't work in Webform Date or Time components

I've confirmed that this is the case, tokens do not work for default values of date fields. At the same time, it doesn't look like they're intended to work currently, since the help text underneath default values for date fields doesn't include the list of tokens that are acceptable for use like other fields. I think it would make sense to support tokens, but currently date components do not.

I have run across this problem also recently as I am trying to follow your advice from pnwds and upgrade my current installation from 2.10 to 3.2

It previously worked in 2 it is now it is broken.

warning: DateTime::__construct() [datetime.--construct]: Failed to parse time string (%get[start-date] ) at position 0 (%): Unexpected character in /webform/components/date.inc on line 530.

grimfandango

I have been doing some digging and in 6.x-3.x the old behaviour (populating date with %get) breaks in revision 1.29.2.5 of date.inc

1.29.2.5 looks like it is doing revisions around timezone handling.

warning: DateTime::__construct() [datetime.--construct]: Failed to parse time string (%get[start-date] ) at position 0 (%): Unexpected character in /webform/components/date.inc on line 154.

While I am not a programmer, I will continue to dig into this as I need this functionality for my current project and will report anything I find here.

I have the same issue, did you solve it?

Thanks !!

I haven't had time to get back to it as I am in the middle of building out another part of the site. What I did for now to get it to at least simulate what I want was revert the date.inc back to a revision that works for me for now (probably breaking other stuff) until I can get to it.

Token support for the date field is probably the way to go.

The attached patch adds token support to the time component.

For what it's worth, this bug actually segfaults some versions of PHP. Specifically, the $datetime->format('c') call after constructing a DateTime with a bad value. Not that that's webform's fault, but it's worth noting.

jcarnett: unfortunately this patch doesn't work for me :( it is version 3.6 now and token support for the date field is still on the way.

The patch I attached was just for the time component. Here's a quick one for the date component.

Just like adding support for tokens in the time component, you need to make sure whatever the token evaluates to is a valid date, otherwise you run the risk of giving someone a way to segfault your PHP process. In other words, tokens from user input are probably not the wisest decision unless someone wants to roll new patches with some additional validation.

Both patches apply cleanly to 6.x-3.6.

subscribing

Thanks for the patches @jcarnett! As it turns out, the date and time components were each refactored to just support #default_value directly, so these patches became rather trivial. See this issue: #1150576: The "time" component should use a #process function for expanding itself.

I've committed the attached patch. Thanks again.

Updating title for posterity.