Entered values are lost until re-entered on edit

same here!

This is a really old report. I can't reproduce any problem using the latest dev version of the code. If there is still a problem in the latest dev version, I need steps to reproduce.

Similar problem here using date 6.x-2.8. When editing a node the date field is properly populated, and saves properly, BUT if there is a validation error on another field then the date field comes back empty.

I plan to upgrade to date 6.x-2.9 and will let you know if the problem is still there.

Changing back to active.

I'm suddenly seeing this with date-6.x-2.9. The value attribute for the input element is definitely empty... but if I go back and view the node the date is there. Clicking in the text field does give me a pop-up, although there's (obviously) no default date.

I don't see anything logged.

I've recently updated to PHP 5.4 so that could have something to do with it... apart from the fact that this bug predates PHP 5.4 by a long way. ;-) I have had to turn off E_STRICT warnings (they got switched on by default in PHP 5.4) to stop a deluge of such errors from CiviCRM...

OK, here's a clue. This seems to happen for all date fields that use "Text Field with Date Pop-up calendar". For a content type that uses a "Select List", the date is there when I edit. When I look at similarly configured Date fields in a Drupal 7 site the value attribute contains the date as expected.

I added:

watchdog('date popup', var_export($element, TRUE));

just before the $sub_element is built in date_popup_process_date() and I do see a value in the logs:

... '#value' => '2012-05-09 00:00:00', ...

Hmmm, noting that $element['#value'] is a string, there's this code:

'#default_value' => (!empty($element['#value']['date']) || !empty($edit['date'])) && is_object($date) ? date_format_date($date, 'custom', $date_format) : '',

If I change it to

'#default_value' => (!empty($element['#value']) || !empty($edit['date'])) && is_object($date) ? date_format_date($date, 'custom', $date_format) : '',

then the date appears in the input element. Note that I'm not using times, just dates...

Hmmm... According to http://au2.php.net/manual/en/migration54.incompatible.php, PHP 5.4 treats non-numeric string offsets differently to previous versions of PHP. Perhaps, for my instance of this problem, this is a PHP 5.4 thing?

The hack above may well be misguided... but it seems to work around whatever the problem really is... Hopefully it will help point to what the problem really is... :-)

The problem went away for me when I updated to Date 6.x-2.9 with Drupal 6.26 and PHP 5.2.17.

I could not reproduce this with the latest code & PHP 5.3.

I had this also with PHP 5.4 using date-6.x-2.9.
In the date_popup.module, doing a dpm($elements) within the function date_popup_process_date shows that the $element['#value'] holds the actual date value. There is not an $element['#value']['date'] reference. So the check for !empty($element['#value']['date']) should now fail with an E_WARNING in PHP 5.4. Previous PHP versions would have returned true on this check even if though the string being checked was not defined (see http://php.net/manual/en/function.empty.php example #2).
Removing the ['date'] piece on line 330, as comment#4 did, corrects the issue because it then is checking the actual referenced date value.

If using the date-time popup you would also need to remove the "['time']" from $element['#value']['time'] in the function date_popup_process_time on line 372

Can this fix be pushed into the module ? It gave such a hard time solving!

The solution in #4 works for me too. Using PHP 5.4.8 and Date 2.9

This is still a problem in Date 6.x-2.9 (using php 5.4). Solution in #4 (and #7) works.

Just confirmed this remains an issue in Date 6.x-2.9 (using php 5.4). Thankfully solution in #4 (and #7) still works.

Uploading a patch file for changes listed in #4 and #7. Tested with PHP 5.3.19

Uploading an updated version of the patch relative to the root of the date module, referencing date_popup/date_popup.module.

It works for me with both the latest recommended release and latest dev release (but you should be testing this vs the latest dev release).

For what it's worth, I just applied this patch again and it works again. Still has to be reviewed by someone else for a proper RTBC tho.

I also can confirm that the problem still exists with php5.4 and date 6.x-2.9 but is resolved with the patch in #13

Resubmitting to the test bot, the patch fails to apply locally to 6.x-2.x now (possibly because I've committed others in the mean time).

I had the same problem (blank fields) with when editing nodes with date fields of type "Text Field with Date Pop-up calendar". Drupal 6.28, Date 6.x-2.9, PHP 5.4.4.

The patch from #13 fixed it.

Looking at the repository, this is already fixed. Turns out that #1808416: Date showing on node view - not showing on node edit - PHP 5.4 issue was a duplicate and I committed that on September 27 in http://drupalcode.org/project/date.git/commit/5c8e8555fbc2c912859adba509... (and mistyped the issue # in the comment message :-P)