Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

My experience upgrading 1.5.1 to 1.6
 
drew.gillson
Jr. Member
 
Total Posts:  15
Joined:  2009-07-30
 

Hi everyone just thought I would share a quick summary of my experience upgrading our dev environment from 1.5.1 to 1.6 - I have not yet done this in production, so part of my motivation in posting this is as much to organize my thoughts about the process as it is to help everyone else. Discussion encouraged!

Here’s what I did:

1. Following the instructions at http://www.magentocommerce.com/wiki/1_-_installation_and_configuration/magento_1.5_to_1.6_upgrade, I tried to use the ./mage script to pull the 1.6 code from Magento Connect. This was where I encountered my very first problem… surprise surprise. I didn’t have the ./mage script in my root directory. Beats me why, but I ended up manually downloaded the 1.6 package and pulling the ./mage script out of it and into my root directory.

2. The ./mage install command ran fine and updated all my files. There were no errors.

3. At this point, I tried to load /admin. This was when I discovered this massive 1.6 database upgrade process. After staring at the loading indicator for a few minutes, I got a MySQL timeout error. I fixed this by asking our host to temporarily increase the value of innodb_lock_wait_timeout in our MySQL config file.

4. Next error: after resolving the InnoDB timeout issue, I began receiving the ‘cannot rename table to tmp table’ errors that seem to be caused by a MySQL bug. This has been discussed in other threads. My solution was to comment out the three calls to ->dropIndex() in lines 1263 to 1276 in mysql4-upgrade-1.5.9.9-1.6.0.0.php and to add the disable foreign key check and unique check statements to the initStatements tag in /app/etc/config.xml. I still haven’t removed this. Does anyone know what the ramifications are?

5. The next error I received was while trying to manually reindex everything by running ‘php /shell/indexer.php --reindexall’ - this one complained about the missing ‘date’ field. This part of the rigamarole is a little hazy. I believe what happened was that the first error I received was about a missing ‘website_date’ field. At this point I renamed the column ‘date’ to ‘website_date’ in catalog_product_index_website, but later, I had to rename it back to ‘date’ to quell another error. I think there are some very bizarre sequence-of-events and chaining issues that occur with these upgrades and it seems almost entirely random what errors you’ll receive and in what sequence…

6. So at this point I had managed to run the database upgrade process (note that I didn’t have to restart the MySQL server once, after every error I would simply try again), and my indexes were refreshed successfully, but I was still not able to access /admin! The next errors I received had to do with Tinybrick’s Lightspeed module. I have not yet figured this one out, and will have to get in contact with Tinybrick. Anyone have any ideas / experience here? My solution was to disable the module (remember to point your default DirectoryIndex in your htaccess file back to index.php from lightspeed.php if you’re using Lightspeed), clear the caches, delete everything in the /var/session/, /var/cache/, and /var/locks/ folders, comment out my cachePage directives in catalog.xml and cms.xml in my /layout directory, and I finally was able to get into /admin.

6. So, at this point, the front-end still displayed a blank white screen, but no errors. After a break and another short troubleshooting session, I tracked this one down and it was not Magento related. We use minifier to serve our CSS and JS, and we have placed an include to the minifier code at the beginning of /index.php. Simply adding this include to the new 1.6 /index.php did the trick. I guess the lesson here is to remember and document every single one of your dependencies!

7. Finally, our development site was back up on v1.6. I could access the front-end and back-ends. However, the URL rewrites were not working properly as none of our navigation did anything but return 404 errors. Even though i had refreshed the catalog_url index several times by this point… I did it again… and lo and behold - it worked!

Conclusion: I haven’t yet performed any tests regarding the actual functionality of the site. The next step is to work through all of our user flows and make sure everything is working. We have had a nasty intermittent bug where a shopper adds something to their cart, proceeds to the cart page, and gets a ‘Your Cart is Empty’ message. This happens to about 5% of our users. I’ve tried all the suggestions on this bug re. increasing cookie timeout, etc. to absolutely no effect. Really hoping some new internal 1.6 magic does away with this one.

So that’s that. Hope someone finds this useful.

 
Magento Community Magento Community
Magento Community
Magento Community
 
alexufarte
Jr. Member
 
Avatar
Total Posts:  6
Joined:  2010-10-28
Spain
 

Hello,

I have done the same as you but add:

First get the 777 permissions to files and folders.

find . -type f -exec chmod 777 {} \;
find . -type d -exec chmod 777 {} \;

After I leave well enough alone.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

Can see Resetting File Permissions.

I did not give me error and now I can go to the manager and the front. Of course I’m also in development. If you try it tell me how it goes.

Best Regards

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top