Nested components do not display saved draft values

So is there a bigger issue when we need to look into the [0] element of the value array()? Or am I reading too much into this?

Yeah we have a problem with our submission structure (and have had it for some time), that the values aren't fully "processed" in a way that would make $form_state['values'] match $submission->data. In our code we try to treat them the same, but they have slightly different structures still. I'd be worried that this patch might have further reaching consequences than expected, such as breaking the conditional checking between pages.

The difference right now looks pretty much like this:

In a $submission object with a textfield, the value is stored as:

$submission->data[$cid][0] = 'value';

However in $form_state['values'] it is stored as:

$form_state['values'][$cid] = 'value';

When we call _webform_client_form_add_component(), $input_values may be *either* $submission->data or $form_state['values'], based on this segment of code:

    // Set the input values based on whether we're editing an existing
    // submission or not.
    $input_values = isset($submission->data) ? $submission->data : array();
    if (isset($form_state['values']['submitted'])) {
      foreach ($form_state['values']['submitted'] as $cid => $data) {
        $input_values[$cid] = $data;
      }
    }

This really isn't super pretty, but it's largely necessary because $form_state['values'] can contain "raw" (unvalidated) information, such as when you use the "Save Draft" or "Back" buttons. Forms are only validated when moving forward to the next page or finishing a submission.

So regarding the actual patch: I've confirmed that this fixes problems with several types of components: times and dates at least. But it also breaks any component that can have multiple values, such as checkboxes. Things also act very weird when you have a checkboxes component that includes a key of "0", then #default_value ends up being set to a string, rather than an array, causing a PHP warning after saving then loading a draft.

As I mentioned above, trying to turn an array into a string presents problems with multi-value fields like checkboxes. So rather than trying to "un-arrayify" the values, let's try the opposite approach an enforce an "always an array" approach. When we rewrote the value handling for the conditional support, it included a hack to get the values to set properly (presumably because things weren't always an array, the form-building wasn't setting default values correctly in the first place). This patch makes it so that the values are *always* arrays by cleaning up the $form_state['values'] (the $submission->data is left alone, since it's already in that format). This makes it so that the form is built correctly to begin with, and we can remove the overriding of #default_value that seems to be causing the problem.

Hm, well this patch works so well (corrects both saving of drafts and multiple page forward/back support) that I think we should include it in the next release to get more testing on it. Feels good to remove a hack that shouldn't have been needed to begin with. Committed this to 7.x-4.x.