I'm using Webform 6.x-3.18
The site's short date format (some research suggests webform uses that) is mm/dd/yyyy.
WF's type "Date" creates a widgets for Month, Day and Year and assembles them internally. When a completed WF is displayed, the date is show like: 01/02/1994 (my site's short date format, presumably).
SF's type "Date" creates a field (for SF site's representation of this field) with a data picked popup that creates text in this format: 12/6/2012
SF's W2F html form code looks like this:
<span class="dateInput dateOnlyInput"><input id="xxxxxxxb2T" name="xxxxxb2T" size="12" type="text" /></span>
Your module's debug log message shows them
xxxxxxxxb2T=1994-01-02&xxxxxxxxxxb2r=2017-01-04
I suspect this is because / is an unsafe character and someplace along the way it's being encoded as -. Perhaps it could be made into %2F ?
Then again, there's the yyyy-mm-dd issue also.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | sfweb2lead_webform.module.patch | 907 bytes | todd zebert |
Comments
Comment #1
todd zebert commentedI finally got around to look into this more closely.
Doing a DPM on Webforms submission->data always shows dates like below (in the ISO 8601 (YYYY-MM-DD) format), despite the Short Date Format at admin/settings/date-time*
(String, 10 characters ) 1998-01-01
Which results in query data like:
...xxxxxxxxxxxxb2T=1998-01-01&xxxxxxxxxxxxb2r=2026-01-02&...
* Changing the SDF does change the appearance of the form when filling it out, but not when you get the data.
It may be worth noting I don't have the Data module installed.
node->webform['components'][num]['date']
My patch checks node->webform['components'][key]['type'] == 'date' and then converts the data string into a format SalesForce expects, like below*. Even if the source date format does change, my use of date() and strtotime() should handle them.
xxxxxxxxxxxxb2r (String, 9 characters ) 2/21/2018
&xxxxxxxxxxxxb2T=1%2F20%2F2000&xxxxxxxxxxxxb2r=2%2F21%2F2018&
*CURL converts the /'s to %2F itself.
And I confirmed that SalesForce does accept the date whereas it didn't in the past.
Comment #3
chriscalip commentedHi Todd,
This was actually remedied in the d7 version of it by introduction an api hook hook_sfweb2lead_webform_posted_data_alter, the thinking behind it is special types of components like date from webform might to be ported a specific format required in salesforce like date or date time, or date but with different format.
I know i did not fix your particular edge case but you can implement that hook to fix that particular edge.
Thanks.
Chris Calip
Comment #4
chriscalip commented