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:

• immediately (or soon) after copying the new files to their destination, we force a redirect (ie php closes the session and releases resources)

(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 [3398]) refs #1331 - temporary workaround

(In [3459]) refs #1331, refs #1897

[3572] 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 [5955]) refs #1713, refs #1331 - workaround for auto-update

(In [5980]) refs #1713, refs #1331 - this should fix the one click update

(In [5988]) refs #1331, refs #3021 - remove #1331 hacks

(In [5991]) 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.

Review/questions

• Did you test auto-updating from 1.7.1 to trunk?
• Did you test auto-updating from trunk to an imaginative next release?
• Did you check that errors/warning are reported when there are some?

Thanks!