RealName hitting recursive bug

I'm not quite sure what you mean?

I have hit a recursive real names token bug too, and I have followed advice and installed the token_tweaks module. Originally I posted this issue on the OG module issue list http://drupal.org/node/1440284 and have found it may be token and real name related. Can anyone give me any advice? I have attached the error message. At the end of my tether with this bug.

This seems to be a real name module issue. More testing is required on my part tomorrow but I will endeavour to get to the bottom of it if possible and will post my findings. Please advise if you think this should be a separate bug report or if you think this is the right place.

I can confirm this is still an issue in the recent dev.

Yep, after whole day of testing I can confirm that realname is this module causing the issue in my case. Everything fine without module but I can't find the offending code, I'm afraid someone with a bit more knowledge of how all these modules fit together might be required to find a solution.

Is anyone working on this issue at the moment. Because it spans a few modules it's a tricky one and beyond my own experience with token module. I'd imagine it's a difficult one to recreate though so let me know if I can help with testing in any way.

Just to provide some more input. I hit a recursion error when

• Adding a custom field "field_last_name", "field_first_name" to users (People)
• Attempting to log in with the realname field set to "[user:field_last_name], [user:field_first_name]"
• Upon attempting to log in to a non UID 1 user script times out after 120 secs

If I changed the tokens to "[user:field-last-name], [user:field-first-name]" instead, there were no issues.

I experienced exactly what traverus is saying..

i had realname configured to: [user:field_dev_name] it worked at first, but after a while every user that wasn't an admin would be getting a 500 server error when they tried to login... couldn't login at all.. but funny though the #1 user (admin) didn't have this issue..

Now i use: [user:field-dev-name] and it's been working well..

not sure if this is a bug with token or realname.. but here's the fix if anyone is experiencing the same troubles Traverus and myself experienced..

I'm unable to reproduce this problem with the latest 7.x-1.x branch of Realname. I cross-posted my attempted reproduction steps at http://drupal.org/node/1341868#comment-6374802 .

1) Fresh Drupal install with OG 7.x-2.x dev
2) Define name_first and name_last fields.
3) Configure RealName to use [user:field_name_first] [user:field_name_last] for the user token.
4) Create a public group
5) Create a Bob Jones user
6) Log in as Bob Jones
7) Join a public group

Ditto.

The [user:name] token cannot be used as it will cause recursion.

With regards to comment #15, I can concur that this works. I _think_ that the token with the dash is provided by the entity_token module, and does not suffer from the issue which the token module has. entity_token is provided with the entity module.

Regarding #16: this looks like it's fixed in latest version (7.x-1.2)

I just installed the module and set up a nice tokened-string (which was wrong, bug in token?) and when I save the admin form, there is an unending recursive loop:

* realname_load_multiple tries to load the realnames
* it doesn't find the realnames so it does a realname_update
* which loads the tokens, which needs a user object so it does a user_load
* this triggers a realname_user_load which does a realname_load_multiple
* etc

I fixed this (also in attached patch):

// in function realname_load_multiple:
// ...
    // For each account that was not present in the database, generate its
    // real name.
    foreach ($new_accounts as $uid => $account) {
      if (!isset($realnames[$uid])) {
        $realnames[$uid] = FALSE;
        $realnames[$uid] = realname_update($account);
      }
    }
//...

In the `realname_settings_form` function, the token_tree is loaded with the option '#dialog' => TRUE. This appears to be a bug in token (??) as this loads the wrong token-list: I get a big list of [current-date:*], [current-user:*], [current-node:*], etc. tokens.
If I remove this option, I get a nice token-list with just the [user:*] tokens.

Works great, please commit.

Please add a test that verify functionality. What other modules have added this bandaid?

Is this still an issue? I have read Dave has added a protection years ago...

There still is issue: just installed RealName module, played a bit with settings of 1 menu item, logged out/in couple times, cleared cache, and... got my site down with Memory limit / Bad gateway error! Urrrr.....
Thank You topicstarter for patch #1 - I recovered the site in just 20-30 minutes after I tried to do many things with other modules, too, and found out this thread. Very nice solution.

Can you share a repro plan, please?

Thanks for the Patch - it worked for me on version 7.x.1.3
I could not batch delete users with Drush (delete_all module) or view the user admin screen if specific users were loaded in the 50 of the first page. The web pages just timed out and drush delete would bring the webserver down!
After looking all over for fixes I found this post and adding the patch sorted it out!

This still seems to be an issue. The code in the patch fixed a problem I was having with a number of drush problems (drush uli causing a Segment fault and core dump) for example.
Login in to the site also failed with a stack limit exceeded.

Here's a new patch for the 7.x-1.4 branch as the location has changed.