After an upgrade (7.2 to 8.1 and 8.3 or 8.x RC 8.4) the admin can't login anymore in some situations

• Conflict of two features (each works well independently)
• Consistency
• Error
• Usability
• Documentation (or Advocacy)

After upgrade the admin can't login anymore

The failure sequence :

1. Create a new directory or repository for the new version
2. Update with your files (particularly images or icons)
3. Site enable (example a sub-domain) on Apache
4. Copy the database on new name
5. Install manually .htaccess (compare and insert your valid options )
6. Update "local.php"
7. run <your new domain>/tiki-install.php. Goto the end (note an error occurs if your say at the end "run tiki" without locking or not because tiki-setup tries to re-open a session already automatically opened by installer). You just launch again (default tiki-index)
8. Try to login as admin : You will be rejected as wrong password

Analysis - many possible reasons :

There are a lot of reasons to be in this situations. So to be successful a lot of conditions must be satisfied :

1. If your new version uses the same current domain (after upgrade for my own I defines the same "servername" as current one and then keep the other when a particular name containng the version :

- The Cookies of session will try to reconnect an older version and a trace shows that the password is not the one you have given (generally empty). So the cookies of the site name must be cleared on your navigator

1. The temp files or session table contain too wrong data : they must be cleared on server for your current copy (SVN update case)

2. Your admin record in user_user record contains sessions data : they create a conflict which makes crash your login

3. Be careful of the fact that you can have an open session in your navigator with the same site (sometimes we uses a lot of tab management which can create this : on firefox use showcase and search to clear your old sessions

4. Generally avoid these problem is sufficient but at the end you will be prompt to update your password (as for the first login as admin with password admin). This can fail for the following reason : if the .htaccess is not set or modrewrite not well operational the <site name> will include the "port" used by your server. If your NAT translates the port address (i.e. 80-> 4397) you will get the following url <site>:4397/.... which fails

This situation is common and complex for whom have to manage product and data migration from one version (or several) of tiki to a new one.

It is not seen generally by developers, because it is not at all their common upgrade process nor test.

The true solution is a modification of installer and userlib which will make useful resets that I have done successfully manually (after a lot of hours of work). It had been reproduced and tested twice.

The manual operations are described into "workaround" which can be reached only after summit.

Manual operations

1. Be sure to have closen the url
2. use phpmyadmin to access user_user : edit the admin record : set to null

- provpass
- lastlogin
- currentlogin
- challenge
- pass_confirm

1. Clear "temp" files and "sessions cache" if not in "temp"
2. On the computer for the domain clear the cookies
3. Launch the url: http(s)://<site>/tiki-change_password.php?user=admin
4. You will be proposed to change the password (you must use a new one, even after login you go back to the old and current one)
5. You are now logged in and will never have any problem

Everything will be now OK.

note for others users working on others computers:

For others users new sessions will be created. Some problem can occur with PHPSESSID for others users running a session while you make your update. Even they disconnect (you close the site during update - needed), when they reconnect the PHPSESSID cookie can give wrong data. The solution is to clear this cookie before reconnection after an upgrade (soft version and data structure).

Option :

- You can reset the admin record with the tiki.sql corresponding record. But be careful, if you have changed the minimum size of password you will fail...
I have developped an sql request which resets full default configuration for logins and reset admin default. But as it can change with new version I can be given only as example (valid till 8.4).
Naturally some of this operations are not necessary depending of options.

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org

This bug has been demonstrated on show.tikiwiki.org

Please demonstrate your bug on show.tikiwiki.org