Ok, I’ve managed to narrow down the error a bit, but I’m still not sure if it’s what’s causing it.
After the upgrade, var directory is not writable by Magento and it’s causing it to write to /tmp/magento. I tried changing the permissions to 777 for the whole installation to no avail.
Export the existing database
Import that existing database into a new database
upload the new version files to a new folder on the server, redirect domains to the new folder.
run through the installation, connecting to the new database which I imported the old database into.
re-install the extensions
transfer accross the themes, and update any changed files.
then setup a clean database install in a 3rd database and run a repair on the database I just upgraded using magento repair database tool.. running a repair is not necessary but I do it anyway to root out any corruption in the database, as on the odd occasion I have found corruption to occur during the upgrade process… so its more of a good practice thing.
run through all the settings to check, and also update any new settings which didnt exist previously.
but doing it that way, any upgrade you do is not effecting the existing site, and you are free to revert back at any time should the upgrade go wrong.. effectively you are setting up a 2nd website to run alongside the existing website… then shutting down the existing website once the upgraded site is fully functional.
takes me on average about 4 hours to do properly… but well worth it to minimize corruption… and gives you an escape route should things go wrong.
I already tried commenting this line yesterday and let Magento update the database (it’s already big so it took quite sometime), after getting back in the office, it looks like it ran fine.
Now I’m still wondering why reset() is being called from an upgraded Magento. Could it be due to extensions?
Also, I’m not sure I find the need for resetting the appRoot variable.
In earlier versions appRoot wasn’t cleared in the reset function, I’m wondering why they choose to do so in 1.7.
So I guess it’s not that important to have it cleared.
I have similar problem.
@magentoinchina - can you please which exactly AITOC module should be upgraded? Is it any specific module or something like \"install\" or \"sys\" module?
I have their Reviews Booster, Custom Options Templates, Shop by Brands.
Hello, I have experienced your error, and user magentoinchinais correct in saying that AITOC extension (custom options template for me) may be the problem.
AITOC’s programmers for some strange reason put App.php in app/code/core/Mage/Core/Model/App.php
which overrides any xml extension disable commands. this makes some believe they have a problem with their core when they try to disable all extensions but still cannot get it to work. I suggest you upload newest version of AITOC and problem should be fixed or rename that file (it’s only purpose is to serve AITOC’s extensions and try to load site again.
