Upgrading to 2.0.7 Error

Hooks are supposed to be supported with the “My changes” add-on included with the cart. Unfortunately, there has been no documentation on how this works. However, forum member tbirnseth has provided a free Local Configuration addon; you can find out find out more in the following post including where to download the add-on and a PDF which explains them:

[url]http://forum.cs-cart.com/showthread.php?t=11656[/url]



The following post shows how to add the product weight to the product block using a hook:

[url]http://forum.cs-cart.com/showpost.php?p=55292&postcount=2[/url]



I have also used the Local Configuration add-on to create a local stylesheet which uses images also stored in a /skins/YOURSKIN/customer/addons/local/images directory. These are unaffected by the upgrade process so there is no need to resolve conflicts or redo the changes.



Bob

Upgrading did not work, the products do not appear in categories after manual upgrade. All the others fields seem to be OK. Is there another solution?

The problem seems to lie in the cscart_products_categories generation… corrupt table is the result in mysql 5.1.34 - tried updating to 5.1.37 and still no dice.



Looks like THIS bug is the culprit:



[url]MySQL Bugs: #46766: ALTER TABLE corrupts table on combined drop and add index



…based on this code in uc.sql:


ALTER TABLE `cscart_products_categories` CHANGE `position` `position` smallint(5) unsigned DEFAULT '0' NOT NULL, DROP KEY `position`, ADD KEY `position` (`position`);

Hooks are not everything they are made out to be and actually can be very dangerous when upgrading. In many places you will not be using the latest functionality or features if you used a hook. For example from 2.06 to 2.07 a lot of new functionality was added to the cart. The new code is within some very popular hooks. If you used hooks to overwrite or make changes to these areas you will not be utilizing the new features or code. Instead your old hook will be processed and not the new code.



In my opinion hooks are not very useful if you are making a lot of changes. After each upgrade you will still need to do a lot of work to make sure your old hooks are not overwriting any new functionality.



I found it easier and more efficeint to just rename the skin I am using and not use hooks.



David




[quote name=‘jobosales’]Hooks are supposed to be supported with the “My changes” add-on included with the cart. Unfortunately, there has been no documentation on how this works. However, forum member tbirnseth has provided a free Local Configuration addon; you can find out find out more in the following post including where to download the add-on and a PDF which explains them:

[url]http://forum.cs-cart.com/showthread.php?t=11656[/url]



The following post shows how to add the product weight to the product block using a hook:

[url]http://forum.cs-cart.com/showpost.php?p=55292&postcount=2[/url]



I have also used the Local Configuration add-on to create a local stylesheet which uses images also stored in a /skins/YOURSKIN/customer/addons/local/images directory. These are unaffected by the upgrade process so there is no need to resolve conflicts or redo the changes.



Bob[/QUOTE]

I’ve got the message like this

Error

The upgrade package seems to be broken. Please try to download it again



I upgrade directly from Admin panel from my shop



And then I refresh and it did successfully!

Click Refresh Packages List in the Upgrade Center to see if you get an updated package with date of 8/25 on it. I had to do that before I could upgrade my store.



Stephanie

Hello Triplets,


[QUOTE]Hooks are not everything they are made out to be and actually can be very dangerous when upgrading. In many places you will not be using the latest functionality or features if you used a hook. For example from 2.06 to 2.07 a lot of new functionality was added to the cart. The new code is within some very popular hooks. If you used hooks to overwrite or make changes to these areas you will not be utilizing the new features or code. Instead your old hook will be processed and not the new code.



In my opinion hooks are not very useful if you are making a lot of changes. After each upgrade you will still need to do a lot of work to make sure your old hooks are not overwriting any new functionality.[/QUOTE]

Interesting viewpoints to consider.


[QUOTE]I found it easier and more efficeint to just rename the skin I am using and not use hooks.[/QUOTE]



I am finding that even though I have renamed my skin folder that the last couple of upgrades have still made major changes to my customized CSS files within that skin folder, this has been quite time consuming to go over & correct! Are you also experiencing this?

the upgrade did’nt work for us, it literally fried the cart, we never should have tried it because even if it did work it we would have lost next to all of our changes, a manual upgrade though time consuming is always the best way to upgrade…

[quote name=‘snorocket’]the upgrade did’nt work for us, it literally fried the cart, we never should have tried it because even if it did work it we would have lost next to all of our changes, a manual upgrade though time consuming is always the best way to upgrade…[/QUOTE]



Sorry to hear that - we ran into the same issue. The first package wouldn’t revert - I had to pull the backup files replaced by hand and move them back into position.



The second pack did install but the database issue remained and I was able to successfully revert.



I should note that I had to rework the admin page from my custom named scheme to admin.php for the admin page to get updated properly. I did this he second time around - but not the first. I think that had a negative impact on the reverting process.



Also Sno… are you running MySQL 5.0, 5.1 or 5.4? I am wondering if people who are upgrading without incident are using 5.0…

[quote]

Also Sno… are you running MySQL 5.0, 5.1 or 5.4? I am wondering if people who are upgrading without incident are using 5.0…[/quote]5.1.37 server mysql … error :frowning:

And after alter all tables to ENGINE = InnoDB, upgarde ok

[quote name=‘voxdizainas’]5.1.37 server mysql … error :frowning:

And after alter all tables to ENGINE = InnoDB, upgarde ok[/QUOTE]



Based on what I’ve been reading that seems like a common theme with myISAM tables when you try to pack index and key drops and adds into single alter statements.



Were you able to revert your tables to MyISAM from InnoDB - I’d imagine the performance hit for using transactional IDB would make it impractical for CS-Cart deployment. Maybe someone can chime in who still read documentation - been awhile for me.

[quote name=‘snorocket’]the upgrade did’nt work for us, it literally fried the cart, we never should have tried it because even if it did work it we would have lost next to all of our changes, a manual upgrade though time consuming is always the best way to upgrade…[/QUOTE]



Sno - could you comment on this a bit more? I understand the principle of getting the vanilla release and comparing for code revisions, but where do I find the SQL script to update the database? I’d imagine the plain version expects a person to be building from scratch. Is it possible to, say, download the upgrade package without installing it and then use the uc.sql from that?



I also found it frustrating that past archived version (stock installations) are not available via helpdesk. This is really bad - I am used to having those available in case I decide to rollback to an earlier version or want to fix a botched upgrade - for example being able to diff compare and see which files are in 2.0.6 and which are in 2.0.7 would have been ideal. However I never downloaded 2.0.6 (upgraded from 2.0.3 - 2.0.6 using the update center) and so I don’t have access to this older version.



Maybe this is something the cs-cart folks can put back into place for us?

[quote]Also Sno… are you running MySQL 5.0, 5.1 or 5.4? I am wondering if people who are upgrading without incident are using 5.0…[/quote]



Interesting question. My successful upgrade was actually on a testing server running 5.0.81 and my unsuccessful upgrade was on my localhost running 5.1.37.



I’m not sure if any of this means anything, but I am curious if it does.



Brandon

PHP v5.2.5 & MySQL v5.0.81 here, yea I just downloaded the upgrade package and manually upgraded the site, applied the uc.sql to the database manually…

[quote name=‘brandonvd’]Interesting question. My successful upgrade was actually on a testing server running 5.0.81 and my unsuccessful upgrade was on my localhost running 5.1.37.



I’m not sure if any of this means anything, but I am curious if it does.



Brandon[/QUOTE]



In my desperate attempts to maintain my job, sleuthing around took me into the deepest recesses of MySQL bugtracker hell (I think that’s the fifth circle) where I have found considerable commentary posted within the last month regarding performance differences between MySQL 5.0 and 5.1 with regard to indices, keys, foreign keys, and in particular the order and combination of alterations made to given tables.



Key file corruption was the error being thrown by 5.1.XX in at least two cases I found, with the same statements producing no corruption whatsoever in 5.0.XX - the problems also seem isolated to the MyISAM engine…



I was looking at the uc.sql code to see if the compact ALTER statements operating on the table in question could be unrolled into multiple progressive statements. My guess is that the team will try a few options on a test corpse until something works and then update the uc.sql in the package.

After i revert my new upgrade and trying to create new orders, a Please Wait popup came and nothing work, it is looping there. I also untick dynamic html but getting same problem, Any HELP :mad:

[quote name=‘jagorny’]I was looking at the uc.sql code to see if the compact ALTER statements operating on the table in question could be unrolled into multiple progressive statements. My guess is that the team will try a few options on a test corpse until something works and then update the uc.sql in the package.[/QUOTE]

The problematic ALTER statement on the cscart_products_categories table is creating an index (position) that does not even exist in a fresh install of 2.0.7. Restoring the table from backup and then running the following SQL command seems to work:

ALTER TABLE `cscart_products_categories` CHANGE `position` `position` smallint(5) unsigned DEFAULT '0' NOT NULL, DROP KEY `position`;



Additionally, the upgrade has an additional table (cscart_shippings_suppliers) compared to the fresh install.



Bob

Same update disaster here …


Database error: Incorrect key file for table 'cscart_products_categories'; try to repair it (1034)
Invalid query: SELECT SQL_CALC_FOUND_ROWS products.product_id, descr1.product as product, products.tracking, products.feature_comparison, products.zero_price_action, products.product_type, products.tax_ids, GROUP_CONCAT(IF(products_categories.link_type = 'M', CONCAT(products_categories.category_id, 'M'), products_categories.category_id)) as category_ids, min_qty, max_qty, products.qty_step, products.list_qty_count, avail_since, buy_in_advance, popularity.total as popularity, products.product_code, products.amount, MIN(prices.price) as price, products.status, products.list_price, descr1.short_description, IF(descr1.short_description = '', descr1.full_description, '') as full_description, products.is_edp, cscart_seo_names.name as seo_name FROM cscart_products as products LEFT JOIN cscart_product_descriptions as descr1 ON descr1.product_id = products.product_id AND descr1.lang_code = 'FR' LEFT JOIN cscart_product_popularity as popularity ON popularity.product_id = products.product_id LEFT JOIN cscart_product_prices as prices ON prices.product_id = products.product_id AND prices.lower_limit = 1 INNER JOIN cscart_products_categories as products_categories ON products_categories.product_id = products.product_id INNER JOIN cscart_categories ON cscart_categories.category_id = products_categories.category_id AND cscart_categories.membership_id IN (0, 0) AND cscart_categories.status IN ('A', 'H') AND products.status IN ('A') LEFT JOIN cscart_product_sales ON cscart_product_sales.product_id = products.product_id AND cscart_product_sales.category_id = products_categories.category_id LEFT JOIN cscart_seo_names ON cscart_seo_names.object_id = products.product_id AND cscart_seo_names.type = 'p' WHERE 1 AND prices.membership_id IN (0, 0) GROUP BY products.product_id ORDER BY products.timestamp desc LIMIT 0, 5

So many disasters but update is not canceled?

[quote name=‘jobosales’]The problematic ALTER statement on the cscart_products_categories table is creating an index (position) that does not even exist in a fresh install of 2.0.7. Restoring the table from backup and then running the following SQL command seems to work:

ALTER TABLE `cscart_products_categories` CHANGE `position` `position` smallint(5) unsigned DEFAULT '0' NOT NULL, DROP KEY `position`;



Additionally, the upgrade has an additional table (cscart_shippings_suppliers) compared to the fresh install.



Bob[/QUOTE]



That additional table looked like it is getting called by a hook that allows some level of package splitting when you have multiple suppliers for a given order - there is a shipping override hook. Not sure how the plain 2.07 functions without it, unless that feature is not included in that package yet for some reason. Perhaps they started with it and then decided to do it a different way.



For those who claimed to revert but are still having problems… I had to restore files from the var/upgrade/backup folder by hand - the revert changes process did not accomplish it for me. Many 2.0.7 files were left behind.