Hi,

I have the problem, that when I alter the user profile programatically (so the user profile is not loaded after that), the real name of the user gets deleted.

Looking at the code, you have :

/**
 * Implements hook_user_update().
 */
function realname_user_update(array &$edit, stdClass $account, $category) {
  // Since user data may have changed, delete the existing realname.
  realname_delete($account->uid);
}

Is there a specific reason, why you are using here realname_delete() instead of realname_update() ?

Thanks,
Nikolay

Comments

nibo’s picture

OK,
I see, that only using user_update() doesn't override the old realname, but wouldn't be better to call both: so first delete the realname and then update it?

dave reid’s picture

Deleting it will force it to be updated whenever it is needed to be displayed next.

nibo’s picture

Hi Dave,
Thanks for the reply!

The problem in my case, is that I am using views with realname as exposed filter, so I can search within the whole realname and searching after the realname returns nothing, cause the realname is not generated yet.

I have tried calling the realname_update() in the hook_entity_update, but somehow using both realname_delete() and realname_update() in the same user_save process doesn't work. Any idea?

grimal’s picture

Same problem here.
User disappears from views after any field update.

In my opinion there is no good reason to delete the realname instead of update it, realname isn't used just for displaying and generate it on the next user load isn't a good solution.
Furthermore, realname's update actions delete realname instead update it. An operation named 'update' should update not just delete!

Nikolay Borisov i've solved in this way:

// mymodule must have an higher weight than realname module
function mymodule_user_update(array &$edit, stdClass $account, $category) {
  realname_update($account);
}
hass’s picture

Title: realname_delete() on user_update() » Always update realname on user updates
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new1.14 KB

@Dave: How is a realname updated if it is used first? Cannot find the way how this is done.

Patch attached replaces all these delete functions with update functions.

hass’s picture

I guess David is referring to hook_user_load() that causes a realname to be updated.

I think we are able to commit this patch as this will not break anything of todays logic. But I fear to run an update of all realnames if the realname table get's truncated what happens in the function realname_delete_all() #2125737: Use db_truncate() to clear realname table if the realname token rule has changed. In such a case we wipe the table and it build over time. Something that you should only do once after realname installation and not very often. This means I don't think we really need to implement a batch to create all realnames after realname_delete_all() has been executed. But it would be safer and cleaner...

hass’s picture

Status: Fixed » Closed (fixed)

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

scottsawyer’s picture

Issue https://drupal.org/node/1409666 is marked as a duplicate of this issue, however, I think it is in fact a slightly different issue, or at least this patch doesn't fully resolve the issue I discovered.

I have my profile edit screen on a separate page, and my real name pulls from fields in the profile. When I update my profile, the real name does not update. However, I discovered that if I then save my user account, real name does update. My suspicion is that the hook used to trigger the real name update does not fire when profile edit is on a separate page from the user account.

Does anyone happen to know? Do you think if I made a module that hooks hook_profile2_update, I could force real name to update?

EDIT: Well, I am so happy now. That was the exact solution.

function mymodule_profile2_update($profile) { // provided by the Profile2 API
  $uid = $profile->uid;
  $account = user_load($uid);
  if($account->uid){ // just checking that I have a legit user 
    realname_update($account);
  }
}

While I don't suppose this would be a bug for Real Name, Profile2 is a pretty common module. It would be nice if Real Name could consider that a profile update may take place without user_update. Not sure what that test would look like, and I know that it can't test for every possible field used to generate a Real Name.

Or could it? How about if Real Name looked at the actual tokens used to generate the real name and tested for each of those entities to update? I can't put more brain power on it at the moment ( I don't have much to spare ), but maybe this helps someone.

hass’s picture

I think profile2 should run the realname update if it knows that something has changed.

jessehs’s picture

jessehs’s picture

I'm still experiencing problems when using tokens from the profile. See #1044130: Real name not computed when profile field is shown on registration page

daniel-san’s picture

I have found this same issue on a site as well.

Create a user
Edit user
Edit user profile page
Add first and last name fields (these generate the real name) and save
Username is not updated
Resave on the main user account page and realname is generated.

Drupal 7.31
Profile 2 7.x-1.3
Real Name 7.x-1.2

hansfn’s picture

Status: Closed (fixed) » Active

I can confirm the report from daniel-san above - without Profile 2 - where the first name and last name field is added directly on the user.

First try:

Create a user
Enter the first and last name fields (these generate the real name) and save
Username is not updated

Second try:

Select the user created above on the users over (admin/people) and select "Update realname"
Username is not updated

Third try:

Edit the user created above
Save and the realname is generated.

Drupal 7.31
Real Name 7.x-1.2

hass’s picture

Status: Active » Closed (fixed)

See #10.

hansfn’s picture

Status: Closed (fixed) » Active

Hi, hass.

Thx for the very quick reply, but my issue was without Profile 2. Anyway, I tracked it down to the replace pattern. I had used

[user:original:field-firstname] [user:original:field-lastname]

in stead of

[user:field-firstname] [user:field-lastname]

user:original isn't set for new users, of course.

Sorry about the noise.

hansfn’s picture

Status: Active » Closed (fixed)

And I didn't mean to open the issue again ;-)