I am confused - user name

[Jimmi08]

I am confused (again) about display and login name.

I used login event (not sure what now - user_login or login ) and data are

// 		[user_id] => 1
// 		[user_name] => e107 login name     (this was mistake)
// 		[class_list] => 253,251,0,254,250 e107 user classes
// 		[user_admin] => 1  admin
// 		[user_email] => e107 email

after login, I needed to log in to another part of the system. I couldn't because the correct login name is not part of the data.

You can't use e107::user(USERID); in e_event - it is too soon. Or at least I got the error about not existing function.

So I moved this functionality to e_module and found that I need the field 'user_loginname'

So, I am correct with this mapping?

WP vs e107 ($data)

$login_data['username'] = $data['user_loginname'];
$login_data['user_nicename'] = $data['user_name'];
/*
$login_data['useremail'] = $data['user_email'];
$login_data['hashed_password'] = $data['user_password'];
*/

For login in e107 I need user_loginname value, correct? So why does the event work with user_name but the value is login name?

The problem is that the display name can have national characters or spaces and that can always cause trouble.

I checked the code and in the login handler value user_name is used,

Here user_name has priority...
return ($this->get('user_name') ? $this->get('user_name') : $this->get('user_loginname'));

Really? In the admin area, it looks just like the nice pretty name.

I tried to look at the real name and it is called in database user_login.

So if I want a safe user name and display Full name (Name and Surname) when browsing site, what fields and settings should I use?

Thanks

[tgtje]

well the field you are looking for is indeed the field table user_login.(guessing meant = customtitile aka 'real name' .
however..digging to some file searches the one needed seems to be user_customtitle.
As this can be set in /profile being the LAN_CUSTOMTITLE aka LAN_USER_04.
Now ok that is one thing, but why is not the customtitle? (the profile one) NOT in user_customtitle but instead in user_login field.. (edit: database)
Seems a wrong routine somewhere...
Maybe this does not help, but it is not what one would/should expect..., and for the char and spaces in name.. would need a regex??
So indeed what is to be used ? as i also see no logical behaviour...

furthermore : the displayname is mostly often used on topbars... and using that for using customtitle (if wanted) lot of re -programming.. ????

[Vodhin]

So if I want a safe user name and display Full name (Name and Surname) when browsing site, what fields and settings should I use?

e107 core settings isn't really set up to have separate First Name and Last Name. You could add your custom fields in Users > Extended User Fields and then you can access them in your own plugins. You can make these new fields requires to sign up, too. I think you can also deploy your new Extended User Fields along with your plugin via the plugin.xml file, just be sure to use a very unique field name (eg. user_pluginname_first_name not user_first_name) to avoid conflicts.

plugin.xml:
<extendedFields>
     <field name="pluginname_first_name" type='EUF_TEXTAREA' default='0' active="true" />
     <field name="pluginname_last_name" type='EUF_TEXTAREA' default='0' active="true" />
     <field name="pluginname_posts" type='EUF_INTEGER' default='0' active="true" />
</extendedFields>	

Above is modified from the e107 Developer Manual. How you can specify the label for these fields is unclear.

return ($this->get('user_name') ? $this->get('user_name') : $this->get('user_loginname')); is correct for rendering a User's Display Name: if the user_name is blank, the return user_loginname since it should always have a value.

There is a setting in Preferences > Signup Page Options > Display name and login name may be different for: [Select User Class] where you can modify this behavior and even Reset ALL Display Names which simply copies user_loginname to user_name for every member

DB Fields:
user_name used for Display Name
user_loginname used for logging into the site along with Pasword
user_login maps to the Real Name on a user's Settings Page - it's odd, but I think this is a remnant from early versions (v0.6x 0.7x).

user_customtitle is a "mini signature" primarily used in the Forum and appears below the User's Name and Avatar (I think).
and requires Preferences > Signup Page Options > User Custom Title to be set as Display for it to appear on a User's Settings Page (even though the Preferences section is for Signup Page)

[Jimmi08]

Hi,

I don't need to separate First name and surname. Just readable display name - displayed for user everywhere - not to reveal their login name. Your explanation is great and extremely helpful... Thanks

[Jimmi08]

@Vodhin
Your post was about theory and explanation.
My post was mainly about logic and correct behavior. I try to explain.

I know most of the things you wrote, I can help myself, but I can't give e107 installation to any client, I can't get money then and I can't support e107 more... It is very embarrassing if I convince them to use e107 and trivial things are not working as they should do.

User management - or membership site - is one area where is e107 better than WordPress, so why does it have to fail on so trivial things?
Is it a problem or limitation of Admin UI? And then this is the reason why I struggle with more advanced plugins then?

Example:
New installation:

_Ok, I take it, main admin can always different display name, let it be, no big issue. _ {during installation you can set a different name for main admin, safety reason etc)

But then why Quick add user allows you set display name? At least notice that a different display name is not allowed.

Ok, I take it, it is admin part, you should know what you are doing

If I fill display name and mark random user name, why still required?

With random user name, entered display name is generated too - why there is at least a notice about not allowing different names?

Why there is check for this value if it is not marked required? And display name is filled from login name?

Why I can delete display name in edit mode?

Why login name is not displayed then in user list if display name is missing?

etc etc... I haven't started with frontend and national characters.

Next finding:

I can set different names. Why it ignores my settings about different values?

This is probably correct, I don't know, no idea how this should work

So your explanation is good for anybody who wants to know how it works now and how it is confusing now.

What I want to know is How this should work or how this was planned to work?

If I know this, I can create a bug issue if it is doesn't work as planned. Or ask if it works for others and look for issue in my code only.

[tgtje]

@Jimmi08 did some testing.. i think all is intended as a method? to be able to grant things or to disallow things on sign up.
So a new user can not do certain things (reasons unknown or copy ??) anyway.
Have to agree it is not that easy to understand and how things have to work.
In my opinion, all relates to the setting of allowed difference at signup iff display and login may differ.
I do believe that the initial setting of NO ONE (inactive) is most used, and not often changed.
When you can agree on that the next thing happens :

Follow the thinking...
new user > ok inactive setting so i am not allowed to do certain things
ok, become a member anyway.

Now it is the thing : when main admin i have the authority to CAN change this.. (admin edit).
So > top class.

And THAT being (if i am correct) prevents me in Quick add user to do that same thing since at THIS point in time NO USER CLASS exists YET (in the make), and even as admin i just have a select class group to add the 'becoming' member to.

AFTER i quick added the user> he/she becomes (class=) member, and as admin i now can change that, overriding the sites Not Active mode...
So overall : the pref setting.. do you allow things or not.. what is the best to do ?

Testscase : set the pref mode (eg > partial active) for members > no issues at all i can do all i want...

SO point in time is crucial.. > another testcase : well setting to Members and do make use of signup > yep realname enabled field but STILL a no go for a new user (no field present for displayname, only username) only realname will be accepted.
HOWEVER once the new member (new member class) is active > he/she now CAN change the displayname
(NOT the username=login)

does this help ? (trouble always will be the language barrier)

[Vodhin]

I think the e107 Setup scripts should simply start in Members Only mode with no Sign Up allowed. The Setup scripts should then let you, as the Main Admin, configure how Users sign up and what fields and User Classes are needed before continuing. Then this issue of a "virgin" website without proper user configuration is avoided.

[Vodhin]

@Jimmi08
Your post starting with:

Your post was about theory and explanation.
My post was mainly about logic and correct behavior. I try to explain.

seems to identify several bugs, if not just quirky behaviour that needs cleaning up. I think you should post that exactly as it is as a bug report. I agree this should not be happening.