date fields filled by date_popup get wiped on full/part form regeneration

I'm experiencing the exact same issue with this version.

I've got the same issue. Subscribing.

After doing some investigation it looks like the bug is in both date_popup_process_date() and date_popup_process_time() in the date_popup.module. Reverting these 2 functions to their stable 6.x-2.7 version fixes this issue but likely reintroduces this bug: http://drupal.org/node/1014162

Same problem, but there is a workaround.

Symptom: Editing existing values works fine. When clicking "Add another item", the correct number of fields is returned, but they are all empty. All my testing was done on a date CCK field that included time but did not include a "To date". I utilized date_popup and the jquery time selection such that the user was not overriding any format instruction.

Troubleshooting: date_convert_from_custom cannot compute the date field because my date format was configured as "m/d/Y - g:ia", but the date_popup was returning a date in the format: "05/19/2011 09:49AM", which is obviously quite different.

Workaround: I changed the input date format to a format that worked "2011-05-19 09:49".

Unresolved Symptom: Because the format expects a time too, just inputting the date and then clicking "Add another item" will cause that date field to be emptied too. Similarly, an improperly formatted date would also be removed.

So there are quite a few ways that date data can disappear from the form. Everything works properly for me once the fields exist in the form. I think that the solution might be able to be handled just in date_popup_process() where it calculates $input based on $edit.

I've finally found the problem! It turns out that right where #6 refers to the date_convert_from_custom() call the code seems to be legacy code. There is a helper function somewhere below: date_popup_input_value(). This is used when submitting the form to actually save the values.

So, why not use it in date_popup_process()?

Here's my patch.

Sorry about the file paths. Here's the patch rerolled with proper names.

It's working, thank you!

You're welcome!

I think so far this patch has only been tested on date + time. Would anyone be able to test it on fields showing only date or only time (if even possible) so we can officially mark this issue as RTBC?

Again, sorry about spamming this issue.

The patch in #8 is working for me too. Thanks!

I also confirm that the patch in #8 works and is being deployed on our production environment.

I am setting this issue to RTBC.

If anyone disagrees, feel free to switch it back to "needs review" or "needs work". Please let me know why so I can fix the issue.

I can confirm the issue & I can confirm that the patch in #8 solves the issue for Date 6.x-2.x-dev.

HOWEVER, I can also confirm this issue is present in the D7 version of Date (Date 7.x-2.x-dev).
The 6.x-2.x patch does not apply to 7.x-2.x, and it appears the code is fairly different, so I could not easily figure out how to port the patch to 7.x-2.x.

Thus, I am changing version to "7.x-2.x-dev" & changing status to "needs work."
I want to first get this fixed in 7.x-2.x to prevent any regressions. Once fixed there, #8 is RTBC for 6.x-2.x.

Thanks

I think this is related to whatever is causing #1209026: When time fails validation, date is cleared. It seems to only be an issue with the popup calendar, not a select widget.

Using the above patch on the latest dev version of my setup DOES NOT work with the time part of the datetime field. It retains the correct date but will reset any of my time values to 12AM. Using - 6.x

Sorry, I think I am having another issue all together.

I am unable to see any clearing in the D7 code when you add another item. I can set a value and it is retained when I add more to the list. If someone is still seeing this in D7 I need steps to reproduce.

Since I can't see it in D7 and we have a patch for D6, I'm moving it back there for now.

The patch in #8 doesn't entirely resolve this problem.

When adding a from/to date with time granularity, but leaving the date section of the 'to' date/time empty because the date should be the same as with the 'from' date, the entire 'to' section get's cleared rather than copying in the 'from' date or simply leaving the 'time' section filled.

Perhaps the easiest way to deal with this would be to add some logic to fill in an empty TO date section by default with the FROM date if not already filled and a time has been entered (as it would be on node_save).

Altering the title of this a little as I found it difficult to find, and scenarios like form regeneration on validation errors also present the same problem.

I stumbled today about this issue, because I came across a very similar error in storm.
In storm we add the date popup in a element process function.
If I set the #value for the date popup, the date fields got wiped out. Now I changed this into #default_value and this works. If #value is set, the $edit variable in date_popup_process is always empty. So maybe the date_popup #value for the "To" field is set any where?

Also I don't know if the patch from #8 is the right approch.
Before the patch the value from the $edit array is used to generate the date.
After the patch the value from the $element['value'] is used.
Normaly this should be the same, but maybe the $edit array is used there, because of a good reason?

I can confirm this issue with the latest releases of core, date, calendar, view & ctools for D7.

If I have a multi-value date field using the popup widget, after entering the first date and clicking on 'add another item', the first date value is cleared.

Please keep this as a D6 issue. The symptom may be the same in D6 ad D7, the code is totally different. There is a D6 patch here and that patch is the only thing that should be discussed in this issue. There is already a D7 issue and I think I found the cause of the D7 problem, and it does not apply to the D6 version.

Hrm whether or not using $element is the wrong approach, I can't see any reason that the TO field with partial information (i.e. time) wouldn't get completed by date_combo_validate() with FROM date information (which it does if the node is saved). Unless date_popup is circumventing this function?

Or might be related to #523218: Default value for To date: Blank should stay blank?

When constructing $input, we can't assume that just appending the time will give us a value that will match the format in $element['#date_format'], in my case it needed a dash, e.g. $input = $edit['date'] . (!empty($edit['time']) ? ' - '. $edit['time'] : '');... After this, it operates the same as with the patch on here, except to-dates still get wiped.

During form submission, the from-date data in in $edit, while the to-date is in $element.

I did the following, but I think I'm probably missing something as to what is the best way of fixing this.

Edit: adjusted to allow for using date_popup_input_value() helper to parse the date/time array, so even if there's a hyphen in the date, it won't choke.

Edit2: adjusted to work with recurrent dates and dates within multigroups

  if (!empty($edit) && is_array($edit) && !empty($edit['date'])) {
    $input_to_convert = array();
    $input_to_convert['#date_format'] = $element['#date_format'];
    $input_to_convert['#date_timezone'] = $element['#date_timezone'];
    $input_to_convert['#value'] = $edit;
    $datetime = date_popup_input_value($input_to_convert);
    $date = date_make_date($datetime, $element['#date_timezone'], DATE_DATETIME, $granularity);
  }
  elseif (!empty($element['#default_value'])) {
    $field_name = $element['#field']['field_name'];
    $delta = $element['#delta'];
    $group = $element['#field']['display_settings']['parent'];
    if (!empty($group)) {
      $posted = $element['#post'][$group][$delta][$field_name];
      $to_name = $group.'['.$delta.']'.'['.$field_name.']'.'[value2]';
    }
    else {
      if (!isset($element['#post'][$field_name][$delta]) && isset($element['#post'][$field_name]['rrule'])) {
        $posted = $element['#post'][$field_name];
        $to_name = $field_name.'[value2]';
      }
      else {
        $posted = $element['#post'][$field_name][$delta];
        $to_name = $field_name.'['.$delta.']'.'[value2]';
      }
    }
    if ($element['#name'] == $to_name) {
      $merged_date = array();
      foreach ($posted['value2'] as $part => $value) {
        $merged_date[$part] = empty($value) && !is_numeric($value) ? $posted['value'][$part] : $value;
      }
    $element['#value'] = $merged_date;
    $datetime = date_popup_input_value($element);
    $date = date_make_date($datetime, $element['#date_timezone'], DATE_DATETIME, $granularity);
    }
    else {
      $date = date_make_date($element['#value'], $element['#date_timezone'], DATE_DATETIME, $granularity);
    }
  }

It's just a reworking of what happens in date_combo_validate()...

Patch attached

Reverted #default_value to #value, don't know why I changed that in last patch

didn't work for existing nodes.

Added a check for $element['#post'] and put the fallback back in the right place

+1

Patched on comment 29 worked a treat for me, thanks!

I think this issue was fixed in date 6.x-2.9 and is related to Issue #1049992: Failed validation causes values to disappear when using popup widget

Given that that is the patch in #8, I don't think it's fixed in that case. See #19

It seems that this bug is solved in 6.x-2.9.

See has #33, for the most part, but not totally, I found, in the case of #19

I have the similar problem when I edit a customized page, all the date field values set to blank.
I am using 6.x-2.4.
But it works fine when I login using admin account, other users having the problem.

How can I solve this problem, please let me know.

Thanks

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.