I'm not quite sure if this is a bug in Date or a problem with my methodology.

Replicated on a fresh install with:

  • Drupal 5.7
  • PHP 5.2.5
  • Date 2 Dev (May 13)
  • Date CCK field (not datestamp)
  • Text entry
  • US/Pacific
  • Not multiple
  • Not required (if set to required, the drupal execute fails because the entry won't validate

The foreach below takes a range of dates from the createDateRangeArray which it uses to populate the date field. When the foreach is run, the first node created has a blank value for the date field. Each node thereafter is populated correctly with the correct date. So, for example, if my range was 2008-05-01 to 2008-05-31, a node would be created for each day with the first node missing the date (2008-05-01). Setting the field as required trips an error on the first node created because the value is missing. I've confirmed that the $value variable holds the correct data during each iteration of the foreach, including the first one.

		foreach (createDateRangeArray($start, $end) as $value) {
		  global $user;
		  $node = array('type' => 'commute_log');
		
		  $values = array();
		  // Structure of form_values
		  $values['field_commute_day'][0]['value'] = "$value";
		  $values['title'] = $user->name . " " . $value;
		  $values['name'] = $user->name;
		  
		  // Create node
		  drupal_execute('commute_log_node_form', $values, $node);
		}

Comments

p_alexander’s picture

p_alexander commented
Category: support » bug
Priority: Normal » Critical

Changing to bug report, pretty sure it's consistently reproducible.

karens’s picture

karens commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

What the heck is createDateRangeArray? That's not a date module function. It sounds like that function is not creating the right values. Since I don't know what that function is doing or what it is creating, there is no possible way I can respond to this.

And it's not critical if you use some custom function to populate the nodes and it doesn't work.

p_alexander’s picture

p_alexander commented

Sorry, I'm a little new at this. Didn't mean to do report priority incorrectly. What could I give you that would help show that this is due to the date module vs my mistake? I think the function is returning proper values, as that's what I've seen through debugging. In the code below I've removed the function from the equation and am using a simple array in it's place. Same problem occurs.

$date_array = array('2008-05-01', '2008-05-02', '2008-05-03', '2008-05-04', '2008-05-05', '2008-05-06', '2008-05-07', '2008-05-08', '2008-05-09', '2008-05-10');
		
		foreach ($date_array as $value) {
		  global $user;
		  $node = array('type' => 'test_date');
		
		  $values = array();
		  // Structure of form_values
		  $values['field_date'][0]['value'] = $value;
		  $values['title'] = $user->name . " " . $value;
		  $values['name'] = $user->name;
		  
		  // Create node
		  drupal_execute('test_date_node_form', $values, $node);
		}

Again, sorry. Not trying to be troublesome, just helpful!

karens’s picture

karens commented

The date module expects a full ISO date in the format YYYY-MM-DDTHH:MM:SS and you're not giving it one.

p_alexander’s picture

p_alexander commented

I thought when using drupal_execute it essentially programmatically submitted the form, using whatever validation or field formatting you have set up. This also doesn't explain why the first date in the array fails but the others go fine. However, I updated the array to use ISO dates and it still fails to insert the first date from the array. All other dates appear fine.

karens’s picture

karens commented

drupal_execute is a tricky animal. I can't think of any reason why it would save the first and not later values, and I certainly can't think of anything in the Date module that would cause this. Try another CCK field instead, a simple one like a number, and see if that behaves correctly. If not, it could be something about the interaction of CCK and drupal_execute. If that field works correctly, then we've at least narrowed it down to the Date field.

Or just use node_save() instead, which I prefer anyway because it is easier to debug and more predictable. You can see examples of that in the Date Copy module which uses that method to create nodes with dates, and that method works fine because I use it all the time.

karens’s picture

karens commented
Status: Postponed (maintainer needs more info) » Fixed

I dug into this more just to be sure it wasn't a bug in the Date module, and here are just a few of the problems I ran into trying to do this using drupal_execute(), none of which represent bugs in the Date module, just the complexities of using FAPI:

1) The date values in the array must exactly match the granularity of the date field you are trying to import them into, in this case it must be year, month, and day. Any other values will cause validation errors.

2) The form values must exactly and precisely match the way the form is set up for the widget this field uses. In the case of a select widget that would be an array like array('value' => array('year' => YYYY, 'month' => MM, 'day' => DD)), again exactly matching the granularity of the date field. In the case of a date popup widget it would be an array like array('value' => 'date' => 'YYYY-MM-DD', 'time' => 'HH:MM:SS')) with the date format exactly matching the input format of the field, and only using the time array if time granularity is chosen. In the case of a date_text widget the expected format is array('value' => array('date' => YYYY-MM-DD)), using the exact format specified for the input. If you have a field that has a timezone, you must know exactly where the timezone element belongs in these arrays -- it varies depending on the widget.

3) Once you get past the hurdle of making sure your input exactly and precisely matches the way the form element is structured, you run into another hurdle, and this one I could not get past. FAPI caches forms and uses them over again, so after you get the first value saved, it pulls up the same form and tries to use it again instead of starting with a fresh form and the validation gets missed on all the subsequent values. The missing validation step is where the input values get re-worked into a complete date in the format needed by node_save() -- node_save() is one of the final steps that happens in drupal_execute() -- so by the time it gets to node_save() the value is badly butchered and not saved.

So to sum it up, doing what you want to do with drupal_execute is going to be difficult or impossible, while using node_save() works just fine because you skip all that and just insert your values directly into the node.

karens’s picture

karens commented

There is a core bug issue for the validation problem at http://drupal.org/node/260934.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

superlou’s picture

superlou commented

I think I'm running into the same problem as you have in (2).

How did you determine the format for the form array? The sample array I skimmed was:

[field_date] => Array (
[0] => Array (
[value] => 2010-02-11 06:20:00
[value2] => 2010-02-11 06:20:00
[timezone] => America/New_York
[offset] => -18000
[offset2] => -18000
)
)

I'm using the javascript pop-up widget, and when I try to fake the above array directly, the submission is ok, but no date makes it to the node.

I've tried using the following as you suggested (I think), but still no dates.

$form_state['values']['field_date'][0]['date'] = '2009-01-01';
$form_state['values']['field_date'][0]['time'] = '10:32';

Is this what you intended?