To reproduce:

  • In a content type with a field using formatter_field, add another test field, no matter what the type or other settings are, the only thing required is the cardinality set to unlimited.
  • Go to a node of that type and make sure the field using formatter_field has values.
  • Then, from the other test field just created, hit "Add another item".
  • Save the node.
  • Go back and edit the node and check the formatter_field field values.
  • If the issue is still present they should have been set to empty, unchecked, etc

This seems to be caused by the ajax callback triggered by clicking on the button from the test field. During this call the function formatter_field_field_widget_form is run, but the field being processed is not our formatter_field field, but the multivalued field whose "Add another item" button triggered the ajax callback. To avoid this we could add an extra check to formatter_field_field_widget_form:

  if (!empty($form_state['values']) && isset($form_state['triggering_element']['#field_instance_name']) && $form_state['triggering_element']['#field_instance_name'] == $instance['settings']['field_name']) {
    $path = array($field['field_name'], $langcode);
    $items = drupal_array_get_nested_value($form_state['values'], $path);

and in the element definition:

element['type'] = array(
    '#field_instance_name'=> $instance['settings']['field_name']

Thanks jec006.

Members fund testing for the Drupal project. Drupal Association Learn more


fxarte’s picture

Here is a patch with those changes.

arpieb’s picture

Version: 7.x-1.0-beta2 » 7.x-1.0-beta3
Status: Active » Needs review
1.09 KB

The above patch actually didn't quite work due to the fact that when another AJAX-enabled field triggered a refresh of the field widget, it didn't populate the $form_state['values'] for this field widget. The attached patch addresses this, as well as "beefing up" the conditional check on $form_state['values'] so we can tell if our field is actually defined prior to calling drupal_array_get_nested_value().

zipymonkey’s picture

I haven't used this fields that cardinality other than 1 but I used patch #2 in another patch and it seems to work fine:

futurist’s picture

Title: Field value(s) reset when another field, with unlimited values, gets added a new value in the node form. » Field value(s) reset when a field with unlimited values gets added a new value in the node edit form.

I noticed that this bug not only occurs when a new value gets added but also when a value is removed, i.e. in an image field: a new image is added or an existing one is removed.

The patch by arpieb in #2 fixes this issue for me.

acrollet’s picture

Version: 7.x-1.0-beta3 » 7.x-1.x-dev
Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

Patch applies fine and works well. Taking the liberty of upgrading the priority to major, as this breaks the module's functionality for a fairly common (imo) use case.

claudiu.cristea’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

I tried by adding a textfield with unlimited cardinality. Cannot reproduce the error. Can you give some more specific details?

acrollet’s picture

claudiu.cristea: I was experiencing the issue when using an image field and a formatter field together in a field_collection field of unlimited cardinality.

claudiu.cristea’s picture

Still cannot reproduce. I added a collection field with unlimited cardinality. Then defined in the collection 1 image field, 1 formatter filed (pointing to image). I added to collection items and saved the node. Then get back to edit form and pressed "Add another item". Added the 3rd image and saved the node. All 3 items of field collection are in place.

So, what?

claudiu.cristea’s picture

Issue summary: View changes

adding thank you notes

cachesclay’s picture

Patch #2 fixed an error we were having when adding/removing fields on a Fieldable Panel Pane in IPE. Admins had to save the FPP twice for a Views Field Formatter. Very helpful, thanks!

ron_s’s picture

Patch #2 and the patch on this thread ( overlap. I believe #1394566 is the right approach, since it is using the $instance and not the $field.

Instance is the version of the field attached to the specific bundle, while field is the generic item not bound to any bundle.