Hello all!

What's the most efficient way to taking username out of equation: both in registration and further use of the website on the front-end?

I am currently hiding username during registration and using email to log in to the front-end. The problem that I encountered is that CB auto-generates usernames from the members' names. This means that another person with the same name cannot register.

Possible solutions to that are:

1. Auto-generate a unique username from the e-mail address;

2. Auto-generate a unique username from first + last name + random number.

Please help me solve this dilemma.

Thanks a lot in advance.

Hi timurdavidov,

Firstly thanks for spotting this, I to am not using usernames but had not spotted this issue. I am just about to go live and this could have been a bit embarrassing.

Anyway I have now got my site registration by using the email address as the username. I only accept unique emails so there will be no duplicates.

This took a little finding to follow the registration flow but to solve this I changed:

components/com_comprofiler/library/cb/cb.tables.php
Line 1379to
I also have the cb_connect plugin which uses the username from the external site (eg. Facebook) as the new username. This may cause duplicates so I also changed.

components/com_comprofiler/plugin/user/plug_cbconnect/cb_connect.class.php
Line 618to
These changes got everything working again for me.
But you might want to wait until one of the Admins has confirmed if these changes are okay and do not break anything else or if I have missed something.

Kind Regards

Mike

timurdavidov wrote: ... 2. Auto-generate a unique username from first + last name + random number...

Here are some interesting posts with similar requests and valuable information:

Autogenerate random username

Auto-generate numeric username

There might be other ones...

In general, you should have a look at CB-Auto-Actions in Incubator plugins.

Thanks, Krileon! I am all for avoiding hacks, especially when there is a plugin that can do the job.

By the way, where can I find documentation for Auto Action plugin?

Hi Kyle,

Apologies for giving a hack as my response to the question however having spent some time on solving this I could not get Auto Actions to work on this occasion to solve this problem.

I have this evening again looked at the code and found why I could not get it to work with Auto Actions, this is something you may want to have a look at.

Apologies for this long explanation.

I like, timurdavidov, am not wanting to use the username field, however CB always requires that one is set.
To disable the use of the username on the field page of the CB setup I changed the username field settings to:
Required - No
Profile - No
Registration - No
Searchable - No

Now that part works fine. (I have a separate request/issue though I will ask later).

With these settings on registration the username is created either from the name field or if you do use name field then the email.

Like timurdavidov this is where we get the username warning as two people with the same name can't be registered as it creates a duplicate username.

So I looked at Auto Actions to help, what I found was:

Trigger onAfterUserRegistration is too far along the process you still receive the error when registering as this trigger is done at the end once the data is in the tables.

I then tried the onStartSaveUserRegistration trigger which does get fired before any data is entered.
The field action type wont work here as nothing has been set yet we are still working with the $_POST data.
So I tried using the code type and method of PHP and my code was:This did not work I still kept getting the username warning. Even though the saveRegistration function in comprofiler.php uses the raw $_POST variable.

This is where I cheated I just did the core hack rather than figure out why that simple auto action did not work.

I have now gone back and had look at why this was not working.

So I followed your functions through the registration process.
I will mention everything I noticed.

comprofiler.php
line 959 saveRegistration function starts

at line 960 the $_POST is brought it and doing a print here I can see that my form submission $_POST is empty.
auto action triggered and $_POST = 'test' as set in my auto action.
my update $_POST is used here but it was returning false so the javascript alert is show 2 lines below at 1044.

looking at the saveSafely function.
administrator/components/com_comprofiler/library/cb/cb.tables.php starting line 1350
this passes the $_POST in as the variable $array.
$array is still correctly set as "test".

this accepts the $array variable with my username but outputs to $bindResults with the username set as empty.

As the username has now been unset, starting at line 1367 the username is set to the name field. This is the bit I hacked to be the email instead

Up until $this->bindSafely everything was okay but it unsets the username.

the bindSafely function starts line 864
doing a print shows $array is still set with the new username.

lines 928 to 936 is where the $this variable which is at this point just has empty fields in it gets populated with the processed fields and the username becomes empty.

Now I can keeping drilling down in to the code

But I noticed at this point if in the field settings for the username field you select yes to show on registration.
Then the username field is not unset and stays as the value I set in my Auto Action.

So wherever the code goes next between 928 and 936 when it populates the $this variable. There must be a check being done that if we are not showing the username then unset it and let the code as described above change it to the name or email.

I am just guessing from trial and error that the code between 928 and 936 is looking at the user plugins in components/com_comprofiler/plugin/user and in particular the plug_cbcore but I can't get my head around where it unsets it as the file is quite large.

To cut a long story short
To make this work with auto actions and not have to use the hack then it must not unset the username.
Now I guess this unset is done by design so if the site is not using usernames a user can not inject their own username in to the original $_POST and have it set.

As a suggestion instead of the unset being so far down in the registration process bring it right to the start of saveRegistration. If the username is set in the $_POST unset it then let the auto action at onStartSaveUserRegistration set it to whatever.

Apologies again for the long reply but I thought it better to explain what I had found rather than being unhelpful and just saying "it does not work".

Kind Regards

Mike