Some form field values don't persist across steps

Hm, I don't why but Drupal does not store some values across multiple form reloads (as done with all other values, e.g. title or body or reference fields, or ...).
This does not affect taxonomy autocomplete only but for example the checkbox "Provide a menu link" also (its strange, because other values of tab "Menu settings" are saved).
I need to investigate further, where exactly is the problem.

I am not sure what precisely you mean by

This does not affect taxonomy autocomplete only but for example the checkbox "Provide a menu link" also...

This happens with the core "Autocomplete term widget (tagging)" widget, when as ndiom stated, you create a new tag in a taxonomy field, and then go to the next step (without saving). This also happens (because of a similar reason of the node not being saved), if you have a file/image field that allows for multiple values and rearrange them. You get the message that states that you need to save or your rearrangement will be lost, but if you are not on the last step, you can't save. Just like with creating a new taxonomy term, the new rearrangement is lost if you go to another step.

I suspect that the motivation behind #1772450: Is it possible to save the node after the first step? is to handle issues like these. At least I am thinking about using code like that to handle my situation of having both taxonomy terms being created and multiple image fields being re-arranged in intermediate steps. I'm secretly hoping you'll tell me I'm wrong and that this is solved somehow.

The curretn behavior (7.x-1.x-dev) is that the values are saved if you do not go back to the steps containing the taxonomy field (or multi-value filefield).
I'm still not sure why the values are lost on going back because I'm simply using the core functions for restoring the values. There must be something I'm missing here.

"Provide a menu link": in the vertical tabs with additional settings (such as menu link, URL alias, etc.; not visible in 7.x-1.2 yet) some options are saved if you go back and forth, some are not :(

For some fields the form state is not saved correctly when switching to the next step.
At the moment this field types where mentioned:
* "Taxonomy term reference" (autocomplete widget)
* some checkboxes in vertical tabs "Additional information"
* order fields with cardinality != 1 (including file fields and field collections)

My group have just fixed this issue with below method!

Step 1: Implement hook_form_form_ID_alter and add new validate with a new function.
ex: array_unshift($form['#validate'],'yourmodule_form_name_validate');

Step 2: Implement yourmodule_form_name_validate function
ex:
if (isset($form_state['values']['field_tags']['und'][0]['tid'])) {
//with a new element doesn't exist in term list, It will be generated with tid = 'autocreate' and we based on this to resolve.
if ($form_state['values']['field_tags']['und'][0]['tid'] == 'autocreate') {
$term = new stdClass(); // create new term
$term->name = $form_state['values']['field_tags']['und'][0]['name'];
$term->vid = $form_state['values']['field_tags']['und'][0]['vid'];
$term->parent = 0;
taxonomy_term_save($term);
$form_state['values']['field_tags']['und'][0]['tid'] = $term->tid; // set form_state again with tid for this field
}
}

Regards

Please do not change the issue title since it does not affect term widgets only.
Furthermore it would be great if you could provide a patch to make this work in general (without using field language and selecting a single field value).

Thanks for your suggestion, but before we have a general solution for this issue, we could resovle issue for case Term referrence with autocomplete widget(tagging) with my suggestion.
Regards

So the code in #6 is more or less what taxonomy.module does in taxonomy_field_presave. From what I can tell of this module (I'm still new to it) the node being edited is updated every time you move from step to step, and $form_state['node'] then becomes the basis for the form values when the form is rebuilt.

In the case of fields that do not require manipulation before saving, this is satisfactory. But in the case of an autocomplete widget, for instance, the value of the text input comes from the taxonomy term stored on the node. The key "autosave" (as opposed to an actual tid) is just a trigger for taxonomy.module to create the term and then replace "autosave" with the new tid. I came to this issue through that use case, but I suspect the other widgets affected by this have a similar mechanism in play.

The attached patch adds an invocation of field_attach_presave() after the entity_form_submit_build_entity() that's already being called. This seems to work in the case of the autocomplete widget, bearing in mind that the value input gets saved as a new taxonomy term immediately, even if the user returns to that step and changes it, then creating another term. In my case that's not a problem though it is noisier than the usual workflow where only the final value is saved.

#10 worked for me. Thanks, @bradjones1.
In my case a geofield was losing data while stepping through the form.

Please notice that a required Tags-field validates to true without saving any of the tags.

It seems that the node_validation of Taxonomy fields uses some other data than the node_presave hook.

Looks like based on the feedback in #12 this should be back to needs_work?

@sawascwoolf, any interest in a patch and interdiff? :-)

@bradjones1 this indeed needs work; field type checkboxes (list-text with multiple values) aren't keeping their checked-states. I haven't found a fix yet.

Thanks for the patch #10. It solves the taxonomy term problem, however it also seems to introduce a new bug regarding file fields (images, attachments etc). See https://www.drupal.org/node/2604650.

The added field_attach_presave() method from patch #10 calls file_field_presave() which sets all uploaded file statuses to permanent. This causes problems when advancing to a next step which will cause the error below.

The file used in the Image field may not be referenced

I have applied a fix which will set all file fields statuses back to temporary. See attached patch and interdiff.

This works as a hotfix for our usecase with optional taxonomy fields, however the problem from #12 seems to still be there. And then there is also the "issue" that certain values such as taxonomy fields will now get saved immediately when advancing to the next step, which can cause (a lot of) rogue data when the node does not get saved after all.

Maybe we should look for an entirely different (higher level) approach on preserving values while switching between the steps.

Am I the only one who thinks that calling field_attach_presave() inside a validate callback looks very, very wrong?

I ran into a similar issue with free-tagging terms not being passed to the next form step while working on scald_add_fields (not using msnf, and the values are actually passed from one form to another via entities).

This is the solution I came up with:

// Deal with "autocreate" taxonomy_term items.
// See taxonomy_field_widget_form() to understand why this is
// necessary.
foreach($form_state['values'][$field_name] as $langcode => &$items) {
  foreach($items as $delta => &$item) {
    if(isset($item['tid']) && $item['tid'] === 'autocreate') {
      $item['taxonomy_term'] = (object) $item;
    }
  }
}

This code is run inside a submit callback. Hope it helps.

Edit: Please not that this does still not properly deal with multiple autocreate terms. Only the last term is kept since they all share the same tid "autocreate".

... This is already borked in core Taxonomy. There's no elegant way to work around it, so the only options to deal with multiple autocreate terms are:

• Modify the form_state values even further by replacing the tid with e.g. "autocreate-$delta", and pray that nothing else besides taxonomy_field_widget_form() tries to process the terms. After that it's smooth sailing because the terms have been imploded to a string.
• Add custom processing of the term_reference widget (e.g. via hook_field_widget_form_alter()), check for any autocreate terms, rebuild the tags list and replace #default_value with a second call to taxonomy_implode_tags().

Thoughts?

@16,

I totally agree with that one. It can (and in fact does) cause a lot of problems with certain fields. IMO attempts to patch this are futile since there can be so many different edge cases depending on which contrib modules are used. Not really suitable for the big audience.

Agree with @16.

But patch in #15 gives Fatal error : cannot use object of type stdclass as array when content type has workflow (https://www.drupal.org/project/workflow) integration. Since workflow adds 'workflow_entity' as an object in $form_state['values'].

Just modified a patch which also checks for array.