PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

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

  1. Phil

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


    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

    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.

    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.

    Posted 10 years ago on Wednesday February 27, 2013 | Permalink
  2. Phil

    The "Apparent Fix" "For the GF devs" in my original post caused password updates to fail (and may have caused email updates to fail -- I didn't check). I think I understand what is happening a little better now.

    The line 2185 code needs to run as it was originally: $user_id = wp_update_user($user);. Of course, that will cause the original problem of the display name and website being overwritten to their original non-updated values.

    My new best guess on the fix for the GF devs is to 'unset' the keys for $user['user_url'] and $user['display_name'], right between the existing lines 2184 and 2185. So, the revised lines 2184-2185 could look like this (becoming 2184-2186):

    self::add_user_meta($user_obj->ID, $config, $form, $lead, array());
    unset($user['user_url'], $user['display_name']);
    $user_id = wp_update_user($user);

    Seems to work for me (for now!). Ideas and feedback welcome. Thanks.

    Posted 10 years ago on Wednesday February 27, 2013 | Permalink
  3. I'll bring this to the attention of the development team. Thank you for your troubleshooting.

    Posted 10 years ago on Thursday February 28, 2013 | Permalink
  4. Phil, would you please send me an email at - I have a later version of the User Registration add-on I would like you to try. The display name issue has been resolved for sure, and I believe the website field as well. Please let me know if you would like to try the new add-on to verify. Please include a link to this topic in your email. Thank you.

    Posted 10 years ago on Wednesday March 6, 2013 | Permalink
  5. Phil

    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 {
    $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.

    Posted 10 years ago on Sunday March 24, 2013 | Permalink
  6. Phil

    Yesterday a Gravity Forms developer sent along a more recent version of the beta in which all the above issues appear resolved.

    Thank you for the excellent support. Your ubiquitous good reputation is well-deserved.

    Posted 9 years ago on Wednesday March 27, 2013 | Permalink
  7. Thank you for the kind words.

    Posted 9 years ago on Saturday March 30, 2013 | Permalink

This topic has been resolved and has been closed to new replies.