Magento

@Brady I was also wondering how you are doing with the live production site.

How do you manage making tweaks to the upgrade (like theme changes) on a test installation and then having new orders/ new customs sign up on the live site? Is there an easy way to somehow sync the two when it’s all done and ready to go live?

I’m in the same situation a client just asked me to update their 1.3.2.4 install, the instructions seem pretty straight forward but how bad does the template get screwed up? Does it need to be totally redone from scratch?

Here’s the best strategy I’ve found for upgrading templates.  If you are on a Mac use the FileMerge utility that is bundled with XCode.  If you are on a PC I think there is an app called BeyondCompare.

1. Do a comparison of your 1.3 stock theme versus your 1.6 stock theme.  I’m assuming here you are using a stock Magento theme like Blank.
2. Also do a comparison of your 1.3 stock theme versus your modified 1.3 theme.
3. Take the changes from 1.3 stock versus modified and apply those manually to the stock 1.6 theme.  Use #1 to understand where fundamental changes in the theme have occurred.

There is also an alternative method that can be quicker but you need to know how to use Git.  Peepcode has a great Git screencast if you are new to Git.

1.  Take your stock 1.3 theme and make a git repository.
2.  Make a branch called “13mod”.  Change branches.  Copy the 1.3 modified theme files into the directory.  Commit the changes.
3.  Now make a branch called “16stock”.  Change into that branch.  Copy the 1.6 stock theme files into the directory.  Commit the changes.
4.  There are a bunch of different ways of doing this at this point.  I think the best is merge the 1.6 stock code into the master branch, and then rebase the master branch with the 13mod branch.  What this essentially does is take all the changes between 1.3 and 1.6 and replays those changes onto you 1.3 modified theme.

Note:  The git method will produce a lot of conflicts if your theme is heavily modified from the stock theme.  In this case it’s probably better to use the first method and find all the changes from 1.3 to 1.6 stock and apply those to your 1.3 stock theme.

Hope this helps!

@cdnNick:: Remember not to wholesale copy the layout files from you 1.3 to you 1.6 folder, besides having a different folder structure there are many changes in the XML that will render part of your 1.6 site inoperable. (Namely checkout.xml)

I would take only the layouts you need and use as much of the base as you can. In fact I would start with just your header and footer in the begging and leave all the default layouts stock. Move them over one at a time.

The upgrade went ok, but when I try to simulate an order, I get the following message in checkout:

“Stock item for Product is not valid”

Has anyone had this problem too? Any solutions?

Thanks

Brady - 20 October 2011 11:52 AM

Here is my process going from 1.3.2.4 to 1.6. I suggest NOT doing it on your live site.


- [ADMIN] Deactivate all third party extensions

What you mean deactivates? Where you done that?
Thanks in advance.

You can deactivate modules in a few ways, but the best way is to go into your app/etc/modules/ folder and remove the module’s xml file.  So if you have a Fooman_SameOrderInvoiceNumber module, you’ll remove the Fooman_SameOrderInvoiceNumber.xml file.  You’ll want to leave the Mage extension files (like Mage_All.xml or Mage_Api.xml) since those are part of the core.  And just to be clear don’t delete them permanently, back them up since you will likely need some/most of them when you are ready to enable the modules again.

Another thing that can be done is to go into the Admin -> System -> Configuration -> Advanced, and then set the modules to “Disabled"… honestly not sure if that fully disables the module or if it just prevents it from outputting anything.

Than you, I’ll try this.
With greetings

I found a solution for “Integrity constraint violation: 1062 Duplicate entry” error here
http://phpmysqltalk.com/1099-magento-1-6-upgrade-errors-with-solutions.html

Well, I got everything working on a test setup but trying to do the same steps on the live site doesn\’t work at all. I\’m getting piles of errors and can\’t get the site to work.

I\’m not stuck on this error: mysql4-upgrade-1.5.9.9-1.6.0.0.php\” - SQLSTATE[HY000]: General error: 1005 Can\’t create table

Can\’t find a solution at all for it. I\’ve been trying to get this going for 6 hours now. I\’m hoping I can switch back to the old version but the way today is going that\’s not going to happen.

cdnNick - 05 February 2012 10:00 AM

Well, I got everything working on a test setup but trying to do the same steps on the live site doesn\’t work at all. I\’m getting piles of errors and can\’t get the site to work.

I\’m not stuck on this error: mysql4-upgrade-1.5.9.9-1.6.0.0.php\” - SQLSTATE[HY000]: General error: 1005 Can\’t create table

Can\’t find a solution at all for it. I\’ve been trying to get this going for 6 hours now. I\’m hoping I can switch back to the old version but the way today is going that\’s not going to happen.

This is probably error on foreign key constraint.  For me, it was due mismatch of collation between `directory_country`.`country_id` and `weee_tax`.`couontry`. I need to change latin in country_id to utf8_general_ci to remove the error.

Ive got the same problem, although I dont have multiple stores, just the one.

How did you go about removing your duplicates Brady?

I ran into the same issue (SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘xxxxxxxx’ for key 2)

I modified Brady’s queries a bit to work regardless of store (or at least I hope so ).

SELECT count(*), increment_id, order_increment_id
FROM sales_flat_invoice_grid
GROUP BY increment_id, order_increment_id
HAVING count(*) > 1

SELECT count(*), increment_id
FROM sales_flat_order
GROUP BY increment_id
HAVING count(*) > 1

SELECT count(*), increment_id
FROM sales_flat_order_grid
GROUP BY increment_id
HAVING count(*) > 1

SELECT count(*), increment_id, order_increment_id
FROM sales_flat_shipment_grid
GROUP BY increment_id, order_increment_id
HAVING count(*) > 1

SELECT count(*), increment_id
FROM sales_flat_creditmemo
GROUP BY increment_id
HAVING count(*) > 1

SELECT count(*), increment_id, order_increment_id
FROM sales_flat_creditmemo_grid
GROUP BY increment_id, order_increment_id
HAVING count(*) > 1

SELECT count(*), increment_id
FROM sales_flat_invoice
GROUP BY increment_id
HAVING count(*) > 1

SELECT count(*), increment_id
FROM sales_flat_shipment
GROUP BY increment_id
HAVING count(*) > 1

I didn’t try this but this may work as well:
http://phpmysqltalk.com/1099-magento-1-6-upgrade-errors-with-solutions.html

In the app/etc/config.xml, change this
- SET NAMES utf8
To this
- SET NAMES utf8; SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;

I would assume that will squelch errors during the upgrade process but not sure what other issues that can cause down the line

Can anyone confirm that if you do error out due to a dupe during the upgrade process, if you can “pick back up where you left off”?  Before fixing my dupe, I tried to hit the homepage and it immediately tried to update again and threw the dupe error.  After fixing the dupe and reloading the home page it looks to have continued on with the upgrade process.  Not sure if that is the proper way or not (would hate to restart the whole process).