I would like to migrate my website from Kirby 2 to Kirby 3.
Just started reading into the Kirby 3 migration docs. About user accounts it says:
Delete accounts and avatars
The Kirby 2 accounts and avatars are not compatible with Kirby 3. Please delete your /site/accounts and assets/avatars folders and install accounts from scratch.
I have roughly 200 user accounts and can hardly recreate them all manually. It would also be painful to tell my users that their avatars and user settings have been lost. I really hope there is a helper-program or procedure to migrate the accounts into the new structure?
Since you can read all user data from the old Kirby accounts, you don’t have to recreate them all manually but could export the old information and then import into Kirby 3. I’m currently not sure what to do with the passwords, because they are hashed, but they could be taken as is and be written into the new .htpasswd files.
Currently, there is no ready-to-use helper routine that I know of.
Oh, and one more thing: Password requirements (password length now min 8 chars) have changed. If your users use shorter passwords, they won’t be able to log in with these passwords anymore after the accounts have been transferred.
about the helper: the k2 user files are just yaml. you can use the k3 dir class to iterate the folder, the f class to read the file and the yaml class to parse the data into an associative array.
users can be created using https://getkirby.com/docs/reference/users/create
the htpasswd file can be created with the f class.
The htpasswd file is auto-created when you create a new user using User::create().
You have to create user blueprints for all user roles you used in your K2 installation, otherwise, the user role is set to nobody when creating the new users.
Thanks bnomei and texnixe for your hints. I will have a more detailled look into how user accounts are handled in K3 next week and see if I can make sth work.
It worked fine in our tests. However, given that this isn’t a trivial migration. Please make sure to have a complete backup in case anything fails during the process. And if so, please let us know, so we can work on improving it. Also do if everything worked
Thanks! Also for explaining the general user account structure in the guidelines transparently. The script generally seems to work.
I did encounter two issues though:
I do have users without email (which was not required in K2). The script stops ungracefully on those. inserted an "if ($email != “”) " to filter out those.
I do have several accounts with the same e-mail address. I myself have several (one for each user role for testing purposes) other users have several accounts with the same e-mail for other legitimate reasons. In these cases the script also stops because K3 can not create two accounts with the same email.
So for me this new user account system seems to be a somewhat larger obstacle for migration
I also do not understand why the user-folder is named so cryptically. It is very difficult now to identify users in the filesystem (do I really need to use “grep” to find out where data of a specific user is located?)
As we pointed out in the migration guide, migrating users is unfortunately not trivial.
As an idea, you could filter them out and then attach an “@xyz.com” to the username to create a fake email address, to nevertheless convert these users into working K3 users.
As regards the second obstacle, am I wrong to assume that there are not hundreds of users with multiple identical email addresses, so the additional roles could be recreated manually without too much effort?
Thanks a lot for your insights and suggestions! I’m sure with these I can make the transition work somehow.
PS: I would like to make a general comment though, that the new user account system so far doesn’t feel like progress compared to K2. I just don’t get the rationale why K3 now forces me to use an email address as account identification, while it worked nicely with a free-format username before. Plus information is now distributed across three files, while it was neatly accessible in just one file before.
We had thousands of request to use the email address as username, so that felt like a good step.
That step was necessary to allow user files and keep the password separated from the rest of the user information, which wasn’t possible at all with the setup in Kirby 3. The user folder now works similar to a standard content folder (with the exception that you can’t have subpages).
And to provide some more background on the reasoning behind this (citing @bastianallgeier)
But then … I thought about what happens when you check the files into Git. The user.txt will be checked in as well, including your password hash. That’s not good! So far we had the accounts folder in the .gitignore and you actively had to check it in if you wanted to add it to your repo. But with the new user files (even just the profile pic) this is not ideal anymore.
…
Here’s my suggested solution, that I wanted to introduce first before I build it.
Everything for a user is still stored in the accounts folder.
All custom user fields go into a user.txt and can also be translated with a user.en.txt for example
User account info (role and language) are stored in an index.php that looks like this
'role' => 'admin',
'language' => 'en'
];```
This has the additional advantage that it would block index listing when the server is not protected correctly.
The password is stored in a .htpasswd file in the same folder. .htpasswd files are automatically ignored by servers. Having the password in a separate file would also mean that you could decide to ignore either the password and the account info or just the password in Git.
Hope you will come to appreciate the new user setup once you have explored its possibilities.
