Automatically generate a username from realname fields.

Hi,

I installed and tested this module.
Unfortunately, after clicking the register button on the registration form I always get a white screen either using a . (dot), - (dash), whitespace or   as separators for the username generation.
If using whitespace or nothing as separator then field validation seems to be deactivated -> if some required fields are empty and I click on the register button i receive the white screen.
If I use dot and dash as separators then validation works fine but after filling the registration form out and clicking the register button I also get a white screen.

It would be sooo great if this nice module would work soon.
I'd like to continue the testing and reporting if you will publish updates. :)

Thanks a lot for you work and passion!

Regards,
Stefan

@noahb: 1) I'm not sure I understand what makes this better than what exists now. 2) We stopped using the "separator" in RealName long ago and use a pattern, which allows for "Mr. Samuel A. Jones, III" (note mixed separators).

Noah, did you had any time to get closer to a working release yet?
It would be awesome to implement this module into my current project - would be a kind of life-saver. :)

Best regards,
Stefan

Hi Noah,

The registration process works absolutely fine for me now! :)
I just found one bug. After registering: if you try to change something in your profile (i.e. user/1/edit) and click on the save button, the system wants you to enter a username.
I think this is the last thing that should be done.
We are definitively on the right course! :)

Again thanks a lot for your great work, Noah! :)

Rock on!
Stefan

Ok, now I know why and when this bug appears - I'm thinking about a carrier as professional software tester. :P *kidding*
If you update the profile as account owner (and don't have the permission to change your username), everything seems to be ok.
If you update the account as somebody who has permissions to manage users you are able to see the username field and then the system wants you to enter a username because this field is empty.
From this moment on the system wants you to enter a username everytime, either you can see this field or not.

Would be nice if there is a way to prevent that.

Regards,
Stefan

sounds great. I'm looking forward to test your next release. :)

I use both modules. core profile for birthday & user registration notification and content_profile for cck, content_taxonomy etc.

I patched the zipped files (from comment #5; patching was successfully) and when installing the patched files I instantly get a WSOD through the whole site.
When removing the patched files from modules folder everything works fine again.

Hey, thank you for your passion! :)

Hmm... stupid question: Did you mean that I should try to change the code in the realname.module?
I found your snippet in the realname_register.module so I thought that this is the point of change of your current patch that should make it work the way we discussed yesterday.
So if this is the point I was missing in the process maybe that could explain my WSOD?

Please help me to bang through my walls of stupidity. :)

Cheers,
Stefan

I hope you meant not the realname.module but realname_generate.module - I only found here the mentioned lines.
I commented the lines out and got suddenly a WSOD again. :(

The next strange thing is that since I patched the files from #5 with the patch from #10, I get the WSOD when clicking on the submit button in the registration again, although I uninstalled the module completely and reinstalled the good files from #5. I hope this is browser caching or something similar. I will try it on Monday again. After 16 hours office I'm basta.

We'll get it! ...we're on the right way ...I feel it! *magically* :D

Hi Noah, I hope you've got a great weekend. :)
Any news regarding the realname_generate.module?
It would be really great if we'll get this baby running soon.

Blessings! :)

Stefan

I get this error when clicking create new account

Fatal error: Cannot use string offset as an array in /drupal/sites/all/modules/realname_generate/realname_generate.module on line 90

Sounds like a great idea. Subscribing.

If you are getting the error that you need to enter a username when attempting to edit a user account (user/*/edit) then...

Goto: /admin/user/realname/bypass
Add this line in the "Bypass these forms:" box

user_profile_form name

Now the hidden username field will be populated with the username from the database. With the username field hidden on user/*/edit the only way to change the username in the is by changing the fields that build your realname, which is the way it should work in my opinion.

Hmm... you're absolutely right with your doubts.
I see two ways to improve the UX perspective...
1. After creations and updates of the username there may appear a message with the new generated username and that this should be used for log-ins in future. But indeed this is not the best solution - the most users will forget the username.

2. I think this is beyond the possibilities of this sub-module but maybe it's possible with the realname module yet: The user has the possibility to log-in with the realname. So the value of the username would become less important. But then there should be a notice about that possibility in the log-in block - i.e. replace the string "Username" with "Real name" or the labels of the fields that are used for the realname module (i.e. "firstname lastname") or something else.

Is it possible to use/alter the trigger module or cron to notify about user's content profile updates? I'm not a coder so this suggestions are maybe really stupid. If so, please forgive me. :)

Thanks for the new release. I will test the it (hopefully) today and give feedback.

Logging in with email can be done with Login Toboggan.

As for commenting that code, should we change the "Bypass" default to include "user_profile_form name?"

I also use RealNames with Login Toboggan and String Overrides to get rid of the concept of a username on my site. However, the one area where I haven't been able to use realnames overriding the username is when using a userreference cck field. I'd hoped with the realname dev being able to override the username on views that I would be able to use a view filter and display a list of realnames instead of usernames, but that hasn't worked. The realname_generate module works, although it is problematic since usernames must be unique and if you aren't using email login then the user wont' know what their username is.

If I could find a solution for displaying realnames on a userreference cck field then I wouldn't need the realname_generate module at all and the site would run much more smoothly.

Found my answer here: http://drupal.org/node/380460
So I don't need realname_generate anymore.

UPDATE: Ends up that I don't even need that module either. If I use a view-filter on the userreference cck field I can actually override the username and use the realname. Anyone needs help with this let me know.

subscribing. Cool module.

I get this error message from #27

Fatal error: Cannot use string offset as an array in /sites/all/modules/realname_generate/realname_generate.module on line 104

Here are the versions being used

realname 6.x-1.2
cck 6.x-3.x-
contentprofile 6.x-1.0-

I received error message using both core profile and contentprofile, will try this new zip.

Update This new zip works, also in the add user section no username input field appears until after you add and click save. Not sure if this is by design or not, it works, thanks.

@noahb: I appreciate the effort, but understand that we cannot work with a zip file, or any other form of complete module replacement. We need a real patch.

Hi Noah,

thank you very much for your work. I tested the latest release (#29) with the core profile module on a fresh Drupal installation and it works great for me.

Regards,
Stefan

: )
thanks noahb

subscribing...may try and test it if I get a chance

I am wondering since the realname module requires a security update, is this new function in the latest update, what should we do ?

I'm getting some weird behavior from this lately. When a new user creates an account for admin approval, an admin message will say this name already exists yet the name it gives is an entirely different name. It won't let you approve it but if you go into users list, the new account is created. Anyone else experience this?

Any chance you could include the zip files, patches are alien for non-programmers :)

This module is really causing havoc, its renaming usernames with other active usernames. The correct email remains but the username gets changed to the previous new user's name. I think it would be good if it did not allow duplicate names, currently it's giving each new user the same username as the previous new user thus duplicating names.

It's still happening with this new update, it's renaming the new user to the user who signed up previously.

I have new accounts set for approval by admin so when I get the notice, I edit the account, correct username displays initially but when I hit save, it replaces the username.

Would it be possible to have your Username Generate module, just work during the account creation process ? I don't really need the RealName module.

subscribing

Hi Noah

I installed your latest Module (#49).
It adds the cck Fields to the registration form.
But "Username:" is still there and not filled automatically based on the realname fields.

Your approach is very interesting.
Are you willing to continue to work on it?

Thanks
Stefan

I am using an exotic combination of modules to override the user registration/login experience (based on client defined requirements, not necessarily good ideas ;)

This module will be a nice solution for one of the problems that I have been facing - email_registration is auto-generating username based on email elements (not cool).

So, I will happily report any bugs that I discover and any patches that I develop.

Using:

content_profile
realname
realname_generate
realname_userreference
logintoboggan
email_registration

BTW - I agree with anyone that says that it is a UX nightmare to try to eliminate username completely from a Drupal site. It shows up all over the place, whether you like it or not.

I just discovered a problem. Users with a name that includes an apostrophe cannot create an account. The error is simply a "1" printed in the messages block on the user registration form.

I think the "1" is coming from line 124 of realname_generate.

123          if ($error = user_validate_name($new_name) && !is_numeric(arg(1))) {
124            form_set_error('name', $error);
125          }

There is no such form element in my form called 'name'. So that does not help the user to know what is wrong.

And $message is set to "1" apparently. Odd, since user_validate_name() returns error strings.

I took a look at the user_validate_name() function in user.module. Whoa! Clearly we should be doing more to clean up the username before we check to see if it will validate.

So, I took (some of) the validation code from user_validate_name() and turned it into filters that remove the offending characters. This solves the problems that I was experiencing with apostrophes. And, I can see now that there would be many other cases when my usernames would not have passed validation.

Here is the patch:

--- realname_generate.module.orig	2010-01-05 16:52:26.000000000 -0800
+++ realname_generate.module	2010-01-25 06:32:53.000000000 -0800
@@ -360,6 +360,21 @@ function realname_generate_make_name($ui
       $new_name = preg_replace('/\s+/', $separator,  $new_name);
     }
 
+    // Remove illegal characters - truncate to max length - illegal strings taken from user.module::user_validate_name()
+    $new_name = ereg_replace("[^\x80-\xF7 [:alnum:]@_.-]", "", $new_name);
+    $new_name = preg_replace('/[\x{80}-\x{A0}'.          // Non-printable ISO-8859-1 + NBSP
+                   '\x{AD}'.                 // Soft-hyphen
+                   '\x{2000}-\x{200F}'.      // Various space characters
+                   '\x{2028}-\x{202F}'.      // Bidirectional text overrides
+                   '\x{205F}-\x{206F}'.      // Various text hinting characters
+                   '\x{FEFF}'.               // Byte order mark
+                   '\x{FF01}-\x{FF60}'.      // Full-width latin
+                   '\x{FFF9}-\x{FFFD}'.      // Replacement characters
+                   '\x{0}]/u',               // NULL byte
+                   "", $new_name);
+
+    if (strlen($new_name) > USERNAME_MAX_LENGTH - 3) { $new_name = substr($new_name, 0, USERNAME_MAX_LENGTH - 3); } // -3 chars in case we add unique counter
+
     // Add a serial to the name for uniqueness.
     $counter = 1;
     $base_name = $new_name;

It seems like the whole sanitization and validation section of the code should be refactored, but I'm happy enough to move forward with this little hack.

-ped-

subscribing - i'm looking forward to the reroll!

I think this should stay in it's own module, email_registration is a bad idea, nothing I"d be interested in. Who wants a username based on an email johndoe001, especially when many emails are alias or fake xyzzzz37@. Member sites these days are starting to focus more on real name aspects, I think this is a good idea which makes this module even more of a need.

using patches in #49 & #55 -- so far so good. The only issue I've noticed so far is when Username Pattern is set to 'Simple Separator', the username is still generated from the RealName pattern instead. Looking good though :)

I am in windows and can't really apply patches well. Any chance this will make it into the dev version anytime soon?

Well crap! Thanks :)

I have a few questions:
1) I was wondering if the custom module at #60 requires email_registration module?
2) I use the field firstname for realname. What happens with username generate if there are many users with the firstname John?

Thanks!

1 ) no

2 ) usually it would be firstname.lastname and the duplicate would display with a number added to the name, ie firstname.lastname1, -1, etc.

In your case firstname and another with the same name would be firstname1 or firstname-1, can't remember the exact displaying.

I have a few questions:
1) I was wondering if the custom module at #60 requires email_registration module?
2) I use the field firstname for realname. What happens with username generate if there are many users with the firstname John?

I am giving the module in #60 a try and all except one important yet critical bug is working.

When my new user signs up they get the following email telling them their account is pending admin approval.

U4Y7gFn8N6,

Thank you for registering at...

Obviously the garbled mass of letters and numbers in the begining is supposed to be their name.

The good news is that when their account is finally approved, the email they then receive is fixed and contains their name.

Thanks for the response and sorry about the messed up priority setting.

noahb: I've got this working on my site now and I am running into one more issue.

To reproduce:

Edit a users profile and uncheck "Automatically generate a username." and then manually type in the preferred name, and save.

Now when the profile edit page reloads "Automatically generate a username." is checked again, and if you were to edit another field and save your manually entered name would be over written.

Go here for a video showing the problem http://www.screentoaster.com/watch/stUEpdQkNBRFtYQFhUXV9QVFdX

I think this functionality (in my use case) is pretty important and would warrant another column.

I work for a non-profit anti-war veterans organization. We often have member who want to speak out against the war but are still in the military. This feature allows us to generally obscure their identity from the public while sharing it with the fellow membership. I'd hate for their identity to be revealed before they were read/able because some checkbox kept getting reset.

I'd be happy to test any ideas/patches you might come up with.

A user got through with a blank.blank for realname, not sure how that happen. I tried out the register form myself and it's designed to not send without filing in all the fields, yet a user managed to do it with blank.blank as username. Any ideas ?

From what I could see the values were blank which then generated blank.blank. I guess I should have looked in the database before I deleted the user.

Yes I did do a test and it does not submit with blank fields, that's why I can't figure out how this one got by with blank.blank. Maybe it was a browser glitch and only looked like it was blank ? But then why does the log show New user: . (email address). I also tried blank spaces and that doesn't work either so not sure how it happen. Guess I'll have to wait and see if it happens again then check the database.

What about non-latin characters?

I've tested this patch, and in the profile module fields I've tried spaces, apostrophes, and accented characters like é. All works fine.

The only change I would suggest is to farm out the username sanitization code to a separate function, so other modules can make use of it.

Since this new problem seems resolved I want to point out that my earlier issue #66 still remains. After running several scenarios for account creation it appears as if the name isn't generated until the account is authenticated for the first time. Any further insight would be helpful.

Sub

Hi,

Installed this and its perfect for what I need to do (IT repair, we sign the user up in store and the less to do the better). As per #80/#66, we also have this issue with the username not being generated/accepted until the user turns off and on the generator bit on their account page.

This is extrememly useful little module if this could be fixed and will chipin if needed.

Thanks,
Paul.

Given that this is a completely separate module, and that the maintainer of this one says on the project page that she doesn't have much time to maintain it, I wonder whether the best thing might be to create a new project for the module in this patch.

It be really cool if someone could become a co-maintainer and contribute to RealName with this new feature as well as help develop the main module further..but it's a lot to ask =)

Realname definitely needs to be overhauled. I use to be against using real names but now I rather enjoy the transparency. Realname itself doesn't do much but with the auto generate username it becomes a much needed module.

I add a new user using the admin view. Using core profile and first/last name of "john smith". If I goto the admin list and see the users, I see gDbXW2iYPY. If I then edit that user and click save without doing anything else, it will update and the name changes to johnsmith.

Apologies if I didnt make myself clearer.

Could it be that we do not expect our users to verify? In the same way as [#66], the realname is not being set on user creation but after another event like verification. Can it be hooked _after_ username has been automatically generated by drupal?

Apologies, PHP and coding is not my strong point ;).

P.

I'm getting the same problem as stated in #87, using the core profile. As stated, after editing the users account the random username will then update to use the realname format on save.

Help appreciated.

> Maybe if the autogeneration code could be generalized a bit to work with more than just RealName might be what's needs to truly justify a new project

Not necessarily, it's fine to have a project that is only an add-on to another -- for example http://drupal.org/project/hs_user_terms

I notice if admin tries to manually created a new user, the necessary fields to generate username do not appear only the email field. Is this by design ?

Update: Interesting note, that issue I had before about the blank.blank username. When a user is added manually since there are no fields to generate username, it creates a blank.blank username. The one I mention before though was not added manually but by the user themselves.

I'm having the same issue as #87 & #88, but it also happens during normal registration: the temporary random usernames get saved instead of one generated from the realname. The realname appears correctly everywhere, however. Strangely, this was working fine on my local development system. I've gone through all the settings screens and they match. I'm using Content Profile.

Could this be something to do with module weights and the order things get run?

A bit of debugging turns up that when realname_generate_user() responds to hook_user('validate'), $account is an array, not an object, and doesn't have a uid, which makes realname_generate_make_name() return an empty username because user_load doesn't give it a user.

Then, hook_user('insert') rolls around, the $new_name variable is empty, and so realname_generate_update_name() fails as well.

Why is realname_generate_make_name() called on validate rather than insert? $account is an object with a uid at that point; would it work better there?

Sorry for the multiple consecutive posts -- I think I was wrong about user_load, that doesn't get called in realname_generate_make_name() on registration, because of the conditional.

I've actually solved the issue for me, however. For some reason, the realname_profile_module variable wasn't set, despite being Strongarmed and despite the fields being configured. After saving the module selection page again, username generation started working.

mrtorrent what did you do to solve the issue?

Just went to RealName > Module and re-saved it.

mrtorrent doing that did not resolve #87 for me, can you tell me what settings you are using ?

Specifically I am wondering about the "Override username theme" at admin/user/realname/general

Is it checked or unchecked? What does it actually do?

Hi,

Just reported a bug in this, thought I should point it out here too as its under review.

http://drupal.org/node/824782

Thanks,
Paul.

Regarding the issue in #87, I tracked down the offending code and fixed it (at least for my settings).

I'm using a single profile text field for Name which is the realname field. It's almost 4am, so I apologize for not rolling a real patch, but... its too late, I have to sleep.

I'm not gonna leave you hangin' though, here is the offending code:

On line 353 of realname_generate.module (taken from the latest zip file on this thread):

<?php
if (isset($edit[$key]) && !empty($edit[$key][0]['value'])) {
?>

This is where the problem lies - the profile module does NOT store the field as an array, its just a string, so... I just changed line 353 to look like this:

<?php
if (isset($edit[$key])) {
?>

I did that, and it works. Why? Because the lines beneath 353 check to see if its an array, so the check on line 353 was redundant, and looks like it was just copy and pasted from the content_profile section (see the code block starting at line 368 and you'll see what I mean). Anyway, it did this and tested it and the name is generated correctly.

I hope this helps someone!

- Steve

Yes, it helps me!

The name is created on first blush, but the message status that comes up afterwards to say user logged in, user created etc also shows the original name so might not be kicking in at the right time? anyhow, thats trivial, for me this is now working great! I guess this might actually be down to the same problem with !username not working in the emails...?

Thanks for your help with this, it couldn't have come at a better time for me :).

Thanks,
Paul.

is the top .zip the most current ? It would be nice if this had it's own project page if its not going to be integrated with real name. This thread is getting rather large and difficult to keep up.

#98 Seems to be working so far, thanks a billion!

hi thanks for this module, very helpful
i have 1 question :
when i create a user the genration is made only with one field (surname) and not with the two fields i want (title and surname).
Any idea why ?

Thanks

yes, and once i resaved it (editing the user) it worked.
is it because my first field is the title of my content profile ?

I've made a little patch for those having the issue that I had: I was getting "Cannot use object of type stdClass as array" in realname_generate.module, line 326. The problem was that the function realname_generate_make_name was being called from "realname_generate_nodeapi" with $node as an argument to a matching array parameter. I made the conversion to an array from $node and then called that function using the converted array. I hope that helps.

I don't know to what file the system testing was applied, so I am attaching my original version of realname_generate.module.

#107: realname_generate.module.patch queued for re-testing.

You can't patch code that doesn't exist in the module.

Will this be ported to D7 (maybe as an option in RealName settings) ?

Sorry, guys, I'm new at posting patches :) I don't know how I can delete those posts.
Let me just upload the entire, patched, module. It's working for me, so hopefully will work for others.

For D7, I think this seems like a similar module.. http://drupal.org/project/realname_registration

@aliceduck, realname_registration does not allow you to configure anything, it has to be like said on the presentation page. So if you want usernames to be like firstname.name, you just cannot !

I'll try the patch in #114 and say how it goes :-D

I also think that http://drupal.org/project/realname_registration module is solution to this issue.

@FrequenceBanane: I don't understand - if you are using RealName module, why would you want to configure how usernames will look like? :)

@tibip Thanks for the ＃114　module. It works fine on my site but only the problem is that when I choose "RealName pattern" in "Username Pattern" section the username is stored with random charactors like EbDJMHbuZa. But useing "Simple Separator" it works as expected. My real name pattern is %1 %2 %3 %4 using 4 profile fields.

I also have used Realname_registration module but it looks like doesn't work for my site.

I have 2 roles which have 2 different profile fields each for real name. For example "Role A" has profile fields for real name "field_1" and "field_2" , "Role B" has "field_3" & "field_4". Using Realname module with #114 it can be done by setting "name pattern" to "%1 %2 %3 %4" then it creates username as "field_1 field_2" for "Role A" and "field_3 field_4" for "Role B". As far as I understand Realname_registration module doesn't work this way for different fields for different rolls.

Setting to Needs Work, since the current patches are meant for D6 rather than D8.

I am using a combination of:

- real name module
- - - field validation module can be used to further validate and restrict real name component fields.

- custom username validation module (requires a one line patch)
- - - I restrict username input to the following regex - /\A[[:alphanum:]]+\z/i - which limits input to alphanumeric characters

--

The result is that both the username and "real name" fields can be edited, and can be different, but all work together.

Throughout the site, users see real names.
For URLs I stick to usernames, which have been limited to alphanumeric strings which work well with Views contextual filters.

Works well.