Display name and website fields do not update -- potential fix

ISSUE
display name and website fields do not update -- User Registration Add-on 1.5beta1

STEPS TO REPRODUCE ISSUE

1. Create form with name and website fields.
2. Create an "update user" feed pointing to the form
   • set Display Name to {first name}{last name}
   • set Website (under User Meta) to your website field
3. Embed form and test whether it updates the values for display name and website.

My setup: WP 3.5.1, vanilla Twenty Twelve theme, GF 1.6.12, User Registration Add-on 1.5beta1, no other plugins active

APPARENT PROBLEM
Look in userregistration.php, GFUser::update_user(), on line 2184: self::add_user_meta($user_obj->ID, $config, $form, $lead, array());. This appropriately updates the user meta with the data submitted by the form. The problem appears to be on the very next line, line 2185: $user_id = wp_update_user($user);. This updates the user meta again, overwriting the new data with the old $user data.

Note: If you want to debug with var_dump() etc. in GFUser::update_user(), turn off ajax for the form.

APPARENT FIX
For the GF devs: I'm guessing that the logical solution would be to prevent the overwriting of the updated data. The user id still needs to be passed to the $user_id variable, so line 2185 could be replaced with $user_id = $user_obj->ID;. This seems to make everything work correctly for me, but time will tell whether it creates more problems.

For those that don't want to hack the GF files: (I haven't tested these other ideas.) A different workaround may be to update the user meta data using the (at present undocumented?) gform_user_updated action hook, which fires just after the code above, on line 2191: do_action('gform_user_updated', $user_id, $config, $lead, $user_data['password']);. Another option may be to use the gform_after_submission hook as suggested here when another GF user noticed the display name failing to update.

Thanks for sharing the later version of the add-on. You responded to my email within 20 minutes. Great service! I regret I didn't make time to try it out sooner. The revised version appears to resolve the original issues I was having. Data for display name and website now update successfully.

However, in the version I previewed -- 1.5beta1.14 -- the code edits that fixed the original problem appear to cause the password to be overwritten (preventing future login) and the email field to no longer update. The fix may be simple, however, and perhaps your devs have already caught it.

As a great alternative to code line 2 in my second post above, the devs refreshed the $user data array, and comment it with, "// refreshing $user variable because it might have changed during add_user_meta". The problem is that the refresh wipes out the adjustments that were made to $user['user_pass'] and $user['user_email'] just a few lines higher in the code. The solution appears to be to move those adjustments down a bit, placing them after the $user refresh but before the wp_update_user($user);. After shifting those adjustments downward, the revised code might appear like this: ( applies to 1.5beta1.14 )

// update user meta before display name due to dependency
self::add_user_meta($user_obj->ID, $config, $form, $lead, array());

//refreshing $user variable because it might have changed during add_user_meta
$user_obj = new WP_User($user_obj->ID);
$user = get_object_vars($user_obj->data);

// update display name format
$user['display_name'] = self::get_display_name($user['ID'], $config);

$user['user_email'] = $user_data['user_email'];

// if password provided, store it for update in $user array and then remove from $lead
if($user_data['password']) {
    $user['user_pass'] = $user_data['password'];
    GFUserData::remove_password($form['id'], $lead['id'], rgar($meta, 'password'));
} else {
    unset($user['user_pass']);
}

$user_id = wp_update_user($user);

This appears to work for me for now, but I'll try to report back if I notice any problems.