I just upgraded an installation from 1.2 to 2.1 using the automatic process and I had a few problems.
The installation’s DB is quite large so I decided I’d upgrade the database outside the browser. I tried to do it as advised with
php /PATH_TO_PIWIK/index.php – “module=CoreUpdater”
but when I did that, it just told me it was a dry run, and showed me a number of SQL queries which would be run. So, I put those in a text file and fed them to mysql.
That failed on the query
UPDATE option
SET option_name
= ‘version_ScheduledReports’ WHERE option_name
= ‘version_PDFReports’ ;
because there was already an option named version_ScheduledReports. That was happily a fairly minor failure, and I carried on feeding the remaining commands, which eventually completed (it did take quite a while with a 4GB database). I’m now left with this
mysql> select * from option
where option_name like “version_PDFReports”;
±-------------------±-------------±---------+
| option_name | option_value | autoload |
±-------------------±-------------±---------+
| version_PDFReports | 1.12 | 1 |
±-------------------±-------------±---------+
which presumably is redundant as the update was anyway trying to rename it. Should I simply delete it?
And now we come to the final, and most severe, failure - after the update I couldn’t login as admin. Presumably the update process should have created an admin entry in the user table from the details in the config file, but it didn’t (I only discovered this change in the handling of the admin user after restoring an old DB from backup and finding that there was no admin user there either, which was a puzzle initially) .
I manually created an admin user in the user table so I can now log in again, but you might want to look at that aspect of the upgrade process.