You can clone with
HTTPS or Subversion.
I just upgraded two Piwik installations from 0.5.5 to 0.6 and ran into the same issue twice. During the upgrade process, a fatal error occurs:
Fatal error: Call to undefined method Piwik::getLoginPluginName() in /some/path/htdocs/core/View.php on line 129
After reloading the URL http://some.host/index.php?module=CoreUpdater&action=oneClickUpdate where that error is shown, I get the message Your Piwik version 0.6 is up to date. However, accessing http://some.host/ afterward redirects to http://some.host/index.php?module=CoreUpdater again where a Database Upgrade is required.
Your Piwik version 0.6 is up to date.
After doing this upgrade, Piwik seems to be updated.
I just got the same error. Additionally I took a look at the SQL that gets executed afterwards:
UPDATE piwik_option SET option_value = "0.6-rc1" WHERE option_name = "version_core";
Doesn't seem right to me as option_value should be set to 0.6 instead of 0.6-rc1..
halfdan: Under normal situations, Piwik bumps the version number with each each update script applied (core/Updates) and then finally, to the current version number (core/Version.php).
mburger: This error is a side-effect of the auto-update, where an out-of-date file is already loaded in memory but Piwik references new code in the updated file.
AFAIK there is no fix for this (ie to explicitly unload classes from memory). We might (?) be able to mitigate this by:
(That's an oversimplification. The risk here is that the changes to CoreUpdater experiences the same underlying problem as reported in this ticket.)
I think you should provide a proper warning / error message, at least. Currently, there is no chance I could figure out whether the shown error message indicates a major issue or it is just a cosmetic issue.
Just My 2 Cents...
I think the redirect solution might work. After the files are overwritten, we issue 302 redirect to the coreUpdater with a parameter done=1 and it displays the messages. If an error occurs before the files are copied over (or when the files are copied over), we don't redirect.
If we could, then yes, I agree a warning would be nice. In this case, it's a non-catchable fatal error.
Propose to implement the "redirect" solution.
such a small issue, we can implement such change if it happens again in the future.
Argh. Happened again with 0.8.
Fatal error: Call to undefined function _glob() in /path/to/piwik/core/AssetManager.php on line 371
And it happened again in 1.0.
Fatal error: Call to undefined method Piwik_Updater::getComponentsWithNewVersion() in /var/www/piwik/plugins/CoreUpdater/CoreUpdater.php on line 61
(In ) refs #1331 - temporary workaround
(In ) refs #1331, refs #1897
 refs #1331 too
The webtest now catches the errors and we will fix them to prevent any bad update experience.
if we want to implement a different update logic, maybe we can look at how wordpress does it for plugins for example.
Wont fix for now, since webtest catch all issues and they are easy to fix, but building this 'new feature' is not trivial.
(In ) refs #1713, refs #1331 - workaround for auto-update
(In ) refs #1713, refs #1331 - this should fix the one click update
(In ) refs #1331, refs #3021 - remove #1331 hacks
(In ) fixes #3021, refs #1331 - adds Piwik_View_OneClickDone
During a Piwik software update, there will be instances of old classes
loaded in memory. This is problematic as we will start to instantiate
new classes which may not be backward compatible. This class provides
a clean bridge/transition by forcing a new request.
This class needs to be self-contained, with no external dependencies.