Profile Field Values are lost when performing bulk operations

After experiencing similar problems with profile fields disappearing when user_save() is called, I investigated further...

onepageprofile_user() makes the assumption that hook_user update is only be invoked as a result of editing the profile via a form, however it is also invoked by user_save().
It seems acceptable that user_save could be called simply to edit user roles, or some other user field, however onepageprofile still calls profile_save_profile() for all profile category regardless.
The result being that the core profile module deletes all fields in every profile category, having nothing to replace them with.

I have temporarily solved this by checking the $edit array for the presence of any field starting with 'profile_', however I feel there may be a better solution. I will post a patch with anything I come up with.

Peter

Same problem occurs when Logintobaggan does a role change when a new user clicks on his/her emailed registration validation link. All the profile_values data is erased and rows with empty values are created for all the profile_values fields.

Yes, this is what originally caused me problems. I assumed it was a LoginToboggan bug and implemented a hack, however it is apparent that the onepageprofile module is updating categories that aren't being edited.

We simply need the module to check whether there have been any updates to each category before calling profile_save_profile()

Peter, got a patch yet?

here's my patch...

To clarify the problem, the core profile module handles the saving of profile fields in hook_user update with its own function, profile_save_profile.

This function deletes all existing field values in the category being edited ($category, as passed into hook_user), before re-populating with the values passed through in the $edit array.

onepageprofile's hook_user update op assumes that the account is being edited from the profile form, and so loads all the categories, actively calling profile_save_profile. This is fine, as when the form is submitted, all profile categories are available, and will be updated.

If however, the user update hook is invoked directly, via user_module_invoke, or as part of user_save only one category will be set - normally 'account'. onepageprofile calls profile_save_profile for all categories, causing all the values to be deleted, with nothing there to replace them.

To solve this, we just need to know what context the user update is being called in: the profile form (all categories available, so we can proceed as before), or some other way - we don't need to do anything.

As user_profile_form_submit (the submit handler for our profile form) simply passes the $form_state['values'] through as the $edit array, it contains a 'form_build_id'. This patch simply checks for the existence of the form_build_id to establish that we're being edited from the profile form, and not by some other method.

Peter

+1 on this -- I can confirm the patch works. Thanks!

Great detective work! I've rolled a new version and released it. Thanks very much peterbarnett.

Thank you very much.
It works.