As username I always have…
jens.tornell
One of the few places I can’t use that is KirbyCMS. Only jens-tornell is a valid username.
My suggestion is to make dot available and maybe even @ for using an email-adress as username.
Thoughts?
Atm this limitation is in place as the username directly determines the account file name. See also Allow usernames with capital letters – just as info, not a reasoning.
Edit:
And to give some more context, at the moment Kirby loads and initializes all users by looking at the files in the account directory and registering them with the filenames as their usernames. Only when the actual user data is needed, the file content will be read. Diverting from the concept that username equals (possible) filename would imply that every account file has to be read first to determine the actual username. I’m wondering what this would do to performance. Other thoughts?
Yes, I saw that.
I think I have a kind of a solution for that as well. When saving a user save it like today, for example…
firstname.lastname > firstname-lastname.txt
When logging in, load it sanitized the same way…
firstname.lastname > firstname-lastname.txt
The real username is in the textfile. The only downside to this would probably be that these two could not exist at the same time…
firstname-lastname
firstname.lastname
…BUT the dot-version cannot exist today anyway so it probably wouldn’t matter.
To go far out it could be possible to prefix duplicates, like this…
firstname-lastname.txt
firstname-lastname_2.txt
…for the usernames…
firstname.lastname
firstname-lastname
…and then check inside the text files for the real usernames. It’s a very odd case but it would be waterproof that way.
The problem I see here is that you would have to start to actually read the files to get the actual username. In the case of duplicates with suffixes even multiple files. I’m not sure if this wouldn’t pose a performance issue.
@distantnative, perhaps you could explain why the file names themselves can’t contain multiple periods? Is it a matter or exploding the file name into usable fragments?
Wasn’t referring to just dots, I think this issue has come up multiple times also in regard to capital letters in usernames or other characters/symbols such as the @. So there are several reasons why each one could be a good and bad idea to allow, but I feel if this issue should be tackled, we should think of a general change/approach and not just consider whether additional dots would be ok or not.
I’m personally of the belief that certain symbols/characters should be allowed in usernames, and certain should not. - _ . all seem acceptable to me. ! @ # $ % ^ & * ( ) not so much. + is a toss up. I’m not sure where or when this opinion was developed, but I imagine it’s largely derived from what I’ve seen tolerated on various signup forms for the last 15 or so years.
For support for more characters in general i think the only way would be to have those usernames in the text-file, not as a filename.
However it would not be so nice in the file structure. Maybe like this:
423ffew234jmrwe.txt
8ekkewr8kewrwtt.txt
Less readability.
Another thing would be to use one file as a username index. However that might be slow if there are 100 000 users.
Hard case.
Gmail handles dots in usernames/email addresses in a similar way as proposed by @jenstornell. However, they simply ignore dots in email addresses.
Thus, sending an email to first.lastname@gmail.com has the same effect as firstlastname@gmail.com or f.i.r.s.t.l.a.s.t.n.a.m.e@gmail.com.
This is really useful as it prevents common mistakes when sending email or giving your email address to another person. Maybe this is an option for handling usernames in Kirby as well?
There wouldn’t be any performance problems and I doubt that there will be many situations in which you’d really need two different user accounts with usernames that only differ in a single dot character.
3 Likes
I like that suggestion, and also the information share… I did not know that about gmail addresses.
Wouldn’t you still need to read the file to know the username? To know if it’s first.lastname or firstlastname or maybe fristlast.name?
For some context: The users are initialized through the following code in kirby/core/users.php:
$root = kirby::instance()->roots()->accounts();
foreach(dir::read($root) as $file) {
// skip invalid account files
if(f::extension($file) != 'php') continue;
$user = new User(f::name($file));
$this->append($user->username(), $user);
}
And then the User class is just
public function __construct($username) {
$this->username = str::lower($username);
// check if the account file exists
if(!file_exists($this->file())) {
throw new Exception('The user account could not be found');
}
}
For a better solution, it seems to me atm that we would need to read the file at this point to get the actual username. Prob not such a huge performance problem as this isn’t done all the time, but compared the current version def a difference, you don’t think so?
I don’t think you have to delve into the file over that. When you create the user, if it has a period, you just strip it out… when you submit login, if it has a period not followed by an extension, you strip it out. This allows users to use their preferred method with no strain or significant change on kirby side.
Ok, I see. Just that $user->username() would never really return what the user think its username is.
Ok, so on signup… you strip it from filename, but add it to username field? Verify login against filename as usual, $user->username() is correct with period.
I admit, it seems like an odd solution as I write it.
I admit, it seems like an odd solution as I write it.
However, this would be the most user friendly way in my opinion.
I honestly think we should test the performance difference of reading the file names vs reading each file in an environment with a large number of users. If it’s negligible, I believe that is a better solution as you can easily accommodate a wider variety of characters if you should choose to accept them. If there’s a performance hit, you could also do some sort of narrowing via file name based on submission and checking those instead of all. For instance
user logs in as “distant.native”,
file searches for “distant”,
26 results with “distant” in it,
search 26 files for username: distant.native
vs
200,000 total files.
You could even go as far as
user logs in as “distant.native”,
file searches for “distant” && “native”,
1 result with “distant” && “native” in it,
verify username in 1 file.
Regular people just mess up their usernames at the moment as they can’t use their email address as username, like they do, are forced to and does everywhere else 
and there isn’t a “forgot your login-informations” option for the panel at the moment either (AFAIK). Not the best UX there.
1 Like
Has anyone an idea how I can still support an email address as a username. Unfortunately I have to do so in a current project.
Would it be possible to generate a random/unique username and store the mail address during a registration process and then find a user by mail address while logging in with the found credentials?
Any other ideas?
I guess logging in to a custom front-end form and then redirecting to panel could work. Only guessing here.