Optionwidgets don't work for 'default value' setting

Don't combine different issues, please :) Fixing the title to describe the issue we need to address.

I've been spending some time on this -- actually the default value choice is generally broken. The new FAPI/widget handling is really tricky and I've now got it working right on the node form, but our little trick of inserting it into the field settings form is not working right yet.

I've got to set this aside for a while, but I'll come back to it and work on it some more.

About 'default values' not taking for any widget :
It looks like this construct in content_admin.inc on line 725 was not needed anymore (and was probably buggy anyway since both conditional branches were strictly equivalent)

    // When multiple values are handled by the content module, we'll have a zero
    // delta, but when multiple values are handled by the widget module, we
    // must use the returned value as-is.
    if (content_handle('widget', 'multiple values', $field) == CONTENT_HANDLE_CORE) {
      $widget_items = array($field['field_name'] => array(0 => $default_value));
    }
    else {
      $widget_items = array($field['field_name'] => array($default_value));
    }

Looks like both case need the $items to be built with array($field['field_name'] => $default_value);
I committed the fix, and cleaned that area a little bit.

Now, with this fixed, default values work OK *except* for optionwidgets :-), for which values set in the field settings page still do not take. Hairy stuff follow...

I tracked this down to these lines in optionwidgets_*_process() :

  if (!$form_state['submitted']) {
    $element['#value'] = optionwidgets_data2form($element, $element['#default_value'], $field);
  }

For reasons detailed below, $form_state['submitted'] is TRUE when a *node form* is submitted, but FALSE when the *field settings* form is submitted, and thus in this case the #default_value overrides the incoming #value.

$form_state['submitted'] is set to TRUE when form_builder() parses the submitted button (in _form_builder_handle_input_element(), line 1015 in form.inc)
optionwidgets_*_process() is called when form_builder() parses the widget (in _form_builder_handle_input_element(), line 1036)
The order in which both events happen depends on the order of addition to the $form array. For the node form, submit buttons are added first, cck fields are added through form_alter. For the field settings page, the 'default values' widget is included first, and then the submit button at the end, and the order is wrong for us.

Bottomline is : $form_state['submitted'] is not safe for use in a process function. Only reason it works for node forms is because widgets are added in a form_alter.
if (!$form_state['submitted']) { was introduced in http://drupal.org/node/224614. Before that, we used if (empty($edit)) {, which didn't work because then optionwidgets could not be emptied ($edit comes as NULL when no option is selected, which I think is a known hairy bug in FAPI)
So, not sure what other choice we have.

Only workaround I see for now is to keep the unsafe $form_state['submitted'] check, and add the 'default value' widget in a form_alter, so that we have the same execution order than for node forms. Yuck.

Updating title to the current state of the issue

Wow! Thanks for all the detective work. But we need widgets that work anywhere so we can do our fancy combo fields and such, so I want to see if I can find a way to make optionwidgets work where they are before changing the way we hook it in. Hmm....

http://drupal.org/node/256694 Was marked a duplicate of this issue

Any new update on this? I still can't get the default value for a options drop-down form element to take hold. Also, when a user creates a new node from my form, the drop down value selected isn't stored in the database.

So for me, it's not working in both the node form or the settings page.

*bump*

So I've been having a lot of problems with the "select list" widget with default values AND the allowed values list.

Originally I was trying to store "text" into the database as they key and no matter what key|value pairs I put into the allowed values list, it would only show the key on the flip side. Finally I just broke down and started over saving an integer in the database instead of a string. This made everything link up correctly but I'm still not able to select a default value.

When I click on the "default value" dropdown list, all of my allowed values are listed but when I choose one and save the field, it still doesn't default to that value. I've tried returning a php array as well but nothing seems to make the default value stick.

Any ideas?

OK, partially solved now. I have default values working for regular optionwidgets select lists and checkboxes, but I still need to do more work to get nodereference and userreference selects working.

The solution was to get rid of the check for $form_state['submitted'] and $form_state['node_preview'] (a recent fix needed so optionwidgets didn't lose their values in a preview) and instead just figure out if the values were in the database format or the transformed format, and only transform them if not already transformed. That gets away from any need to know what order all these things will be processed in.

Nodereference and userreference need an additional fix because they are two-level widgets. I should have that working soon.

Nodereference and userreference default values should be working now. The last part of the fix required getting rid of the assumption that the form values would be located at $element[$field_name], which isn't the right location when this is a default value widget, and instead drill down through the element to find the right value.

Hi. No activity and this problem is plaguing me. Have nodes created by users. Default values are selected in the node creation form but after the node is created, the radio buttons are all empty. Basically, the default value is not being saved into the final node. This is on Drupal 5, not 6. Just wondering if there was anything I could do etc.

Coming over from here:
http://drupal.org/node/120377

Seems that this is fixed in a dev version of 6 as of August 7. I too am concerned about this for Drupal 5 at the moment and not Drupal 6.
Is the change being backported to Drupal 5? Also, any sense when this fix will be brought into a release candidate?

I upgraded to 5.x-1.7 (from 1.6.1) and found that there is still some inconsistency in how default values are managed in my account. I can shift them from being enabled to disabled and back, however it seems to be dependent on there being Allowed values list defined (or not in some tests).

Subscribing:
This is still broken in the current 5.x and dev releases.

Updating status

The D5 version is no longer being supported.