Username Overridden in Comments But ...

With the other changes I have committed, I am not seeing this. Please try the -dev version when it rolls up this evening. If the problem is gone, please mark this issue as "Fixed."

This is happening in 6.x-1.1-rc1.

Please try the -dev version. You may need the patches I created for Token.
#325227: Provide e-mail and commenter homepage tokens for comments
#307520: Date formatting function

Okay. I'll try.

Curious. I briefly reviewed the two patches you mentioned. Why would those two patches be related to not being able to comment?

I was wrong. I emptied cache with 6.x-1.1-rc1 and it works fine. Sorry about that. Thanks for your help.

Closing issue.

I was wrong again. The fix actually doesn't work. The only reason why it was working for me was that I was logged into the site as the admin account. Regular users still can't make comments, and are getting the exact error message posted at the top of this thread. "You have to specify a valid author." I tried both dev and rc1 versions and it's happening in both as a regular user.

For 6.x, a slightly modified version of the fix posted at the top of this thread is in order. I have created a patch based on the 6.x-1.x-dev code downloaded today. So I know it's current. I would imagine that if you didn't incorporate the fix from the first reply in this thread in the 5.x release, it would need it there too, but I would not be able to test that for you. Here's the 6.x patch that fixes the issue.

Committed to both branches.

Thanks!

Actually, I have found a problem with anonymous users.

First $form['author'] is only set for an existing comment, and it seems to be fine on all my sites even without any of these patches.
$form['name'] is used for a new comment. This is where I am seeing a problem. It is pre-filling the name and email address with values that I don't seem to be able to successfully alter. I don't have any idea where it is getting these values either - they are from an earlier comment, but even after I change the comments in the database those values are still there.

I am totally baffled at this point and going to leave it for a little while in hopes that something will spring to mind.

I'm sure it's a good catch. I look forward to your elaboration.

Another pair of eyes would be nice...

Subscribing

I am no longer seeing this issue.

I'm still seeing this issue after applying the patch and upgrading to the latest dev version.

This is still occuring in 6.x-1.1-rc3.

Tried -dev?

I've tried dev.

Subscribing...

Any news to solve this?

As far as I know it is solved.

Ditto.

Just to note, this issue is not solved in 5.x dev, I can't test 6.x right now, so don't know, but wanted to mention that here. Although, I am close to a solution.

I'm running RealName 6.x-1.1-rc3 on 6.8, and I can't submit comments (specify valid author - error)

Others indicate that it is fixed in 6.x-1.x-dev, please try that version.

Same in 6.x-1.x-dev: Please specify valid author. Only way I can get to comment is if username is identical to full name...

We are having a similiar problem with privatemsg, see #349022: Private Message to work with RealName module. I am wondering why it is necessary to change $account->name. Isn't it possible, atleast with drupal 6, to override the username-theme *without* changing $account->name? What about a preprocess-hook that does set the $account->name attribute, then it is only changed in theme functions.

Something like (untested):

function realname_preprozess_username(&$vars) {
    // If theme then replace name with realname.
    if (variable_get('realname_theme', FALSE) && $vars['object']->realname) {
      //Store it for places where it needed
      if (!isset($account->realname_save) && is_object($vars['object'])) {
        $vars['object']->realname_save = $vars['object']->name;
        $vars['object']->name = $vars['object']->realname;
      }
    }
}
// and then remove that code from realname_user....

I don't really like to add a realname-specifiy check to privatemsg, would be great if this can be solved in another way.

subscribe ... thx!

With the new "forms bypass" feature this should be fixed. It is only available in the -dev version.

Thank you NancyDru! this is tremendous.

Please what would I add to bypass the Private Message form?

Wishing you a Wonderful 2009!

Lilian

I don't use that module, so I don't know. Perhaps the issue mentioned in #30 will turn up something.

No, it does not yet work with privatemsg.

The privatemsg form does not save the name of the current user but the recipients, and it is possible to define multiple recipients, for example "name1, name2, name3". So there is probably no easy way of replacing the names. The exact problem happens when a user clicks on a profile link to send a user a message, a url like "messages/new/{id}", the form function then uses the attribute name to display the username. When submitting, the username is validated and because it can't be converted back to a user object, it is considered invalid and the validation fails.

  if (isset($account)) {
    $recipient  = $account->name .', ';
  }

However, I still don't understand why $user->name needs to be overwritten. When I simply comment out the following line:

        //$account->name = $account->realname;

in the function realname_user, everything seems to work just fine, the theme function phptemplate_username in realname_theme.inc is called and the realname is displayed correctly. If other modules access $user->name instead of theme('username', $user), they probably want/need the actual username and not anything else.

@Lilian: Can you go ahead and try commenting that line out, please?

@Berdir: Other than that some people don't use the "Override username theme," it does seem to be working for me. I have not yet seen a place where the realname is not being displayed. I do know of places (including the user module itself) that fail to use theme_username (for example, check #73813: Main Navigation Box should allow for greater flexibility in customization (user.module)) and don't really need the unmodified version.

So, I'm asking that all users of this module try commenting the line suggested (in function realname_user) and document any failures to show the realname. If you do this, you will need to make sure that "Override username theme" is turned on.

If it turns out that this solves a lot of problems, perhaps we can simplify the module and make "Override username theme" the default rather than an option.

I just committed a change the "Override username theme" default to true and removed changing $user->name.

The new dev version does work fine for me.

Thanks for the update.

The new dev-version works fine for me too, and so for example send msg function in PrivateMsg works correctly.

But now another module (tribune) shows user login name instead of realname in msg entries.

Before installing the dev-version, this module show realname correctly.

Does anyone have an idea to fix this ?

I have D6.8.

@digemall: I just transferred an issue to Tribune - please check that issue queue.

Ok thank u NancyDru ;)

Is this issue fixed just for -dev at the moment or has it been committed to the stable branch?

Thanks,

Well, according to the project page, this is still in the -dev version.

This issue is still unresolved in the non-dev version of 5.x-1.1

Part of the code is there, but it is commented out and missing a line. Under realname_form_alter, there should be a switch for the case "comment_form" that looks like this:

    case 'comment_form':
      if (!isset($user->realname)) {
        $user = user_load(array('uid' => $user->uid));
      }
      $form['author']['#default_value'] = $user->realname_save;
      $form['author']['#value'] = $user->realname_save;
      break;

Please check the -dev version. Once a release is published it cannot be changed; that's why -dev exists.

NancDru, I am using this in a production site. I do not wish to be using -dev versions for a live production site. If this has made to the -dev and the -dev is stable, why don't we release the -dev as the production version?

Branch is no longer supported.