Everything is broken again

Most of the issues I have found are due to the new nested value functions. (form.inc 5724) The element value will sometimes be a sting time, while the form is expecting an array of date and time. ($element[#parents]).

I am a little too new to fields to know where to start debugging, but will add notes if I get further.

...

Looking a little further. Date_popup_input_value is one of the places where I hit this issue first. At the point where this function is called, I have my date as a string - but this is looking for an array.

...

It looks like the initial code to process form values (in the widget form) can no longer access the item values. (I am going round and round now, so may be confused. I was working with a partially rolled-back install, so may have been barking up the wrong tree.)

I did a little digging here on #2 here and it appears that the issue is like @greenman pointed out -- there are changes in the FormAPI input processing that are choking on Date form elements, in particular ones that are broken out into sub-fields at the process level.

For example, on a node form Form API is setting the field value to a string:

$form_state['values']['field_foo']['und'][0] = '2010-01-04T00:00:00';

While after processing the field is being expanded out to a set of select boxes

$form['field_foo']['month']
$form['field_foo']['day']
$form['field_foo']['year']

etc.

It looks like the solution here is to set a #value_callback in _date_field_widget_form(), but this will require some more work as the same widget logic used to expand date fields out into separate form API elements will need to be used here to take the field value and expand it out into an array matching the widgets.

Expect a first stab patch soon.

Here's an initial patch that adds value callbacks to each of the date element types. There are some changes here that need closer review -- I'm in foreign territory here and the lack of tests is definitely hurting my ability to know just how much functionality/corner cases may be affected by these changes. I'll look into getting time to write tests if possible.

FYI the related core issue to this change is here: #913528: Create new boolean field "Cannot create references to/from string offsets nor overloaded objects".

FYI I think we may want to consult a D7 form API expert in regards to this issue. You'll see in the patch that any time a date form API element is used it needs to also be accompanied by an explicitly declared value callback:

  $element['#type'] = 'date_select';
  $element['#value_callback'] = 'date_select_element_value_callback';

Unfortunately the value callback cannot be declared by the element process callback based on the way values are being checked and set in the FormAPI. This seems wrong to me though as it means that to use any form element that expands a string value into a nested array for its processing/UI you'll also need to know what its corresponding value callback is to handle the value expansion.

I'm not a FormAPI expert though so I may be completely missing something obvious that could let us get around this.

I talked to Adrian and he pointed out that the #value_callback can be defaulted for the element types in question in hook_element_info(). I've rerolled the patch to do this which takes care of my concern in #6. Also added value callback for date_timezone element which I missed first time around.

I'm having the same issue as in item 1) of the original post: can't create a field of type "datetime" bit a field of type "timestamp" can easily be created.

Note: this has been tested against the D7 beta 1

Subscribe

@KarenS, is there an issue filed with core for this?

Subscribing. I'll try to make some time to help with the FAPI part of this. Clearly, if core makes it impossible to have a date field, we need to ensure those are critical issues in the core queue. Also, cross-linking to #763376-145: Not validated form values appear in $form_state.

Not really helpful, but see my #913528-54: Create new boolean field "Cannot create references to/from string offsets nor overloaded objects" :-(

I can't look at the code of date.module now, but as I understand the problem is in splitting/merging field item values before saving. If my understanding of Fields workflow is correct, there is hook_field_attach_submit() which can be used for this purposes. It allows to fetch needed values from $form_state and pass them to corresponding $entity.

This $entity will be later passed to the hook_field_insert() (or _update() ) where additional modifications to the field values an be made before saving.

UPD: Oops, this is more about FAPI element, rather then Fields API field. Sorry, misunderstood.

Subscribe

I never in everything I read found anything that documented that a value_callback is now required or why. And the work to create the correct array in the date field now is not happening at the time the value_callback is called, but much later, during validation. So fixing this correctly will require a total rewrite of the way that date fields are processed :(

I agree that the value_callback isn't very helpful for elements expanding as it is now as it is invoked before the expansion process. However, one can workaround that rather easily. I've done so for the duration element I've written for Rules.

Perhaps the approach taken could help you too, so I shortly describe it here:
* The duration element has a process callback expanding into 2 child elements.
* The value callback is used to assign an array() as value. It must be an array if you have child elements.
* Use an after_build callback (which is called after processing) to set the real value of the element.

Relevant callbacks:

/**
 * Helper function to determine the value for a rules duration form
 * element.
 */
function rules_ui_element_duration_value($element, $input = FALSE) {
  // This runs before child elements are processed, so we cannot calculate the
  // value here. But we have to make sure the value is an array, so the form
  // API is able to process the children to set their values in the array. Thus
  // once the form API has finished processing the element, the value is an
  // array containing the child element values. Then finally the after build
  // callback converts it back to the numeric value and sets that.
  return array();
}

/**
 * FAPI after build callback for the duration parameter type form.
 * Fixes up the form value by applying the multiplier.
 */
function rules_ui_element_duration_after_build($element, &$form_state) {
  $element['#value'] = $element['value']['#value'] * $element['multiplier']['#value'];
  form_set_value($element, $element['#value'], $form_state);
  return $element;
}
</code>

subscribe. it's a shame that date field types didn't get much consideration (or God forbid, be included!) when D7 fields API was locked down. seems like with as many event-related sites as there are using drupal that date field considerations would have been an extremely important consideration.

ad #22: yep, that seems to work very well :)

Subscribe

subscribe

Thanks for your hard work Karen. It is very much appreciated.

Thanks for your hard work Karen. It is very much appreciated.

Ditto.

I think I have most of the recent brokenness fixed again, except for the fact that you can't create a datetime field, which won't be fixed until core is fixed.

#927828: Some schema code incorrectly rely on the generic type instead of the engine-specific type is critical, so therefore, presumably will be fixed. Is there anything else in core that will make it impossible to have a fully functioning Date module? If so, we need to make sure those issues are critical, so please link to them from here, so we can all lobby as needed.