Notice: Undefined property: stdClass::$original in user_save() (line 555 of /modules/user/user.module).
Notice: Undefined property: stdClass::$original in user_save() (line 563 of /modules/user/user.module).

Steps...
1. upgrade to field_collection 7.x-1.0-beta12
2. add a field collection to a user
3. remove a field collection from a user
4. get the above errors

Seems like the $account->original variable is wrongly unset on the call to field_attach_update(). This is observed because $account->original is valid on line 542 of /modules/user/user.module, but then is unset after the call to field_attach_update() when referenced on line 555.

/modules/user/user.module lines 542 - 559

      // If the password changed, delete all open sessions and recreate
      // the current one.
      if ($account->pass != $account->original->pass) {
        drupal_session_destroy_uid($account->uid);
        if ($account->uid == $GLOBALS['user']->uid) {
          drupal_session_regenerate();
        }
      }

      // Save Field data.
      field_attach_update('user', $account);

      // Send emails after we have the new user object.
      if ($account->status != $account->original->status) {
        // The user's status is changing; conditionally send notification email.
        $op = $account->status == 1 ? 'status_activated' : 'status_blocked';
        _user_mail_notify($op, $account);
      }

field_attach_update() calls numerous hooks as defined in the field_collection module. After a quick look I could not see where $account->original was unset by the field_collection module.

Comments

webservant316 created an issue. See original summary.

webservant316’s picture

webservant316 commented
Issue summary: View changes
webservant316’s picture

webservant316 commented

Reverting to field_collection 7.x-1.0-beta11 solves the problem. However, the revert is not a simple code copy because field_collection 7.x-1.0-beta12 installs some database updates.

webservant316’s picture

webservant316 commented
Issue summary: View changes
webservant316’s picture

webservant316 commented
Priority: Major » Normal

Sorry this is not major, but normal. The error makes a lot of noise, but I think there is no harm.

jmuzz’s picture

jmuzz commented
Status: Active » Postponed (maintainer needs more info)

I tried this with the latest dev version but I didn't see an error.

It has the fix from #2382089: Logic issue with fetchHostDetails() causes false "the host entity cannot be changed" error in updateHostEntity() but it didn't seem related to your error so I don't think this has been solved.

Can you provide more details about how it can be reproduced?

webservant316’s picture

webservant316 commented

My use case has a field collection defined for a particular node type and another field collection for the user profile. After upgrading from field_collection 7.x-1.0-beta11 to 7.x-1.0-beta12 I performed a few quick tests.

I opened an existing node and added a field collection ~ worked
I opened the same node and deleted the field collection ~ worked
I opened an existing user and added a field collection ~ worked
I opened the same user and deleted the field collection ~ errors as displayed above

The error is because $account->original was unset after the call to field_attach_update('user', $account). I am sure that field_collection hooks into that function.

Also as part of the upgrade I moved from Drupal 7.50 to 7.52. However, I diff shows that the user.module was not significantly changed in the Drupal upgrade.

What else can I do to test the error?

jmuzz’s picture

jmuzz commented
Status: Postponed (maintainer needs more info) » Active

Thanks @webservant316 . I tried a few more things and found that the error occurs when removing the final item but it seems to work if there are still some remaining items after one is removed.

webservant316’s picture

webservant316 commented

yes, that makes sense.

  • 3556e30 committed on 7.x-1.x 
    Issue #2828609: Fixed a problem when saving user after removing field...
jmuzz’s picture

jmuzz commented
Status: Active » Fixed

Should be fixed now.

Please reopen if it doesn't work for you.

webservant316’s picture

webservant316 commented

I'll check this out on my next round of updates. Might be awhile.

luisasasi’s picture

luisasasi commented

I have the same problem

Notice: Undefined property: stdClass::$original in user_save() (line 555 of /modules/user/user.module).
Notice: Undefined property: stdClass::$original in user_save() (line 563 of /modules/user/user.module).

1. upgrade to field_collection 7.x-1.0-beta12
2. add a field collection to a user
3. remove a field collection from a user
4. get the above errors
Reverting to field_collection 7.x-1.0-beta11 solves the problem, but now, when a user logs in, the system sends email:

Your account at Xxxxxxxxxxxx has been activated.
You may now log in by clicking this link or copying and pasting it into your browser:
http://www.xxxxxxxxx.it/user/reset/1/1479429026/stpfswBDSh_tzRIfZSHav...
This link can only be used once to log in and will lead you to a page where you can set your password.
After setting your password, you will be able to log in at http://www.xxxxxxxxx.it/user in the future using:

how do I fix?

jmuzz’s picture

jmuzz commented

Try the latest dev version.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

webservant316’s picture

webservant316 commented

when is the next release scheduled for to push this fix into production?

danielb’s picture

danielb commented

"The error makes a lot of noise, but I think there is no harm."

The effect here is that the user's status is mistakenly believed by user.module to be "blocked" and then reset to "active". This causes emails to be fired off (to customers in the case I'm investigating) there is a bit of harm there....

webservant316’s picture

webservant316 commented

still waiting for this fix to get pushed to production. what is the hold up?

rbrandon’s picture

rbrandon commented

Agreed that this needs a release. (https://www.drupal.org/project/field_collection/issues/2885870#comment-1...)

There are other implications, for example, the inadvertent save will cause Organic Group references to be deleted in some cases.

webservant316’s picture

webservant316 commented

Drupal updates for me today and I see this is not ready yet. Just trying to push it along.

webservant316’s picture

webservant316 commented

yayy field_collection 1.1 has this fix! thanks!