field_collection_field_update() saves old host entity and overwrites changes

I ran into exactly this same problem. We have some custom code saving a user account, and field collection was undoing any changes to the user table itself (email, password, etc). What was worse was that the returned account from user_save() continued to have the updated data; it was just the database that was wrong.

Here's a snippet of code that triggered this for me; I think the only requirement is to add a field collection to the user entity. We also had the same problems using entity_form_submit_build_entity(); in the same manner as user.module.

    $edit = array(
      'field_first_name' => $form_state['values']['field_first_name'],
      'field_last_name' => $form_state['values']['field_last_name'],
      'mail' => $form_state['values']['mail'],
      'pass' => $form_state['values']['pass'],
    );
    $account = user_save($account, $edit);

We've run into this on Drupal.org too.

Since this is causing data loss, marking it critical.

I tried duplicating this but I may have gotten the context wrong. deviantintegral says "I think the only requirement is to add a field collection to the user entity" but Berdir in the issue summary seems to think it is related to multiple languages.

I added a first_name and last_name field to users as well as a field collection with a text field. I didn't use a form to test it (I wasn't sure where the code posted would go to test it that way) but I threw this into a script:

$u = user_load(2);
$edit = array(
  'field_first_name' => array('und' => array(0 => array('value' => 'new_first_1'))),
  'field_last_name' => array('und' => array(0 => array('value' => 'new_last_1'))),
  'mail' => 'newmail1@example.com',
  'pass' => 'new_pass',
);
user_save($u, $edit);

I tested it with and without the field collection and the name fields as well as the mail was set in both cases.

Can anybody provide more details about how to duplicate this?

I confirmed #1 works on dev for Drupal.org, patching 7.x-1.0-beta7. I didn't test 7.x-1.x.

For us, the steps to reproduce are something like:

1. Create a field collection on the user entity, not shown on registration. Ours are exported to http://cgit.drupalcode.org/drupalorg/tree/features/drupalorg_user.
2. Create a user, don't log in as them.
3. As an admin, try blocking that user. Notice they aren't blocked.

To debug, I got the backtrace to each call to user_save() for the last step. I noticed that it was actually called twice, with the second call coming from field collection. Presumably, this is an older copy of the user entity from memory, and it is saving over the first save.

If wanted, you can take a look at a Drupal.org dev site, https://www.drupal.org/node/1018084.

I followed those steps on a mostly fresh install and wasn't able to duplicate the behavior described. I tried adding and removing some field collection items from the user as well as the patch seems to change what happens when field collection items are removed but the changes to the user were all saved.

I'll try to get access to a Drupal.org dev site.

Create a user, don't log in as them.

I should say, register as the new user, while logged out. Not sure if it would actually make a difference, but I wouldn't be surprised.

They are blocked by default when I create them that way and I was able to block and unblock them using /admin/people and the user edit form.

Thanks for giving me access to a test site. I'll try it there next.

I was able to reproduce it on the test site and the patch fixed it.

A version of this updateHostEntity function was made for #1344672: Field Collection: Field translation (entity_translation) support. to solve a similar problem. I'd like to use the current proposed version of the function from that issue instead of the one supplied by this patch as it has been looked at more, it will make the transition to including entity translation more smooth, and it will be helpful to uncover any more issues it may have.

I tested this on the drupal.org test site and locally and it seems to solve the problem without causing more issues.

Agreed, looks good!

Thanks all.

I link the issues having problems related to updateHostEntity function.