X-Cart forums

[ADDISON]

@Speaking about bugs a few posts above. Even the code is well done (no mistakes), if the programmer made mistakes in architecture, fore sure it is a bug. Let me give you an example. We are talking about speed in 4.6. Is it an improvement or an issue related to those engineers who were not be able dealing with speed in 10 years? If Admin interface is like a Minotaur's labyrinth, even is well done as code, it has an issue: functionality. In 4.6.0 you can see my name in changelog. It is a bug related to position numbering in DPI module. By default position was increased by 1, imagine how wonderful in repositioning images with position 1,2,3,4 and make it 3,4,2,1. How many steps you have to do to achieve the new repositiong? And this is happening in FeatureComparision too. Bugs or Improvements?

It is very ease to say: this request is an improvement, but it needs a solid argumentation. Sometimes one of the best way to make money is to call it like that. I'm personally conducting a deep investigation about XC world. With new releases some developers are asking money. I need to know if this is good or bad. Let me give you an example, I want the speed advantages but I have a module bought from a developer called X. This developer asks for money to get his module working for new version. I have to take a decision: pay it or not. This could be a long discussion but I think is very important.

This is not related to XC but it could be (no solid proves). I hate when someone is asking for money to repair his fault or things left intentionally inside the code (financial bombs for users).

[xim]

Ksenia, thank you for such useful post. Ksenia previously managed upgrade tasks in our company and she made this post basing on her experience.

Unfortunately, there is no magic sync script which will done all sync job for you. Our upgrade team has some inhouse tools to make their job safer and easier at the same time. But these tools are like very specific science equipment, which need to be used in specific conditions and for only certain stores, but not a magic wand which solve all the problems immediately.

Our upgrade team use the same diff and files from File Area, which are also available and for customers. The only difference that they have 10-years experience with upgrade process. If I cannot score all the 10 three-pointer shots, I will not say that it is impossible, because Michael Jordan can do it.

[cflsystems]

Originally Posted by Ksenia

If you have a live store on one hand ( which keeps generating new orders, customers, inventory changes) and upgraded store of a different version ( with new modules, changes to database, as well as, often, new data, such as products, images etc)on another hand, this 'synchronization tool' becomes a problem.

*which exactly type of data to move (customers? products? categories? orders?anything else?)
*how to define which data are new and require migration?
*what to do with different tables structure if the modifications/modules on dev copy affected the database?
*what to do with IDs if the same ones are present in two databases ( say , new product/user is created in live store and another new product/user with the same id - on dev copy) - overwrite, ignore? even if you personally do not add anything to dev copy, you should keep in mind that some people still tend to.

These are the problems I foresee at a first glance. If we ask upgrade team engineers, they will most probably give a dozen of other potential questions without clear answer.

Probably that's why even the upgrade engineer with more than 10 years experience often prefers this scenario:

#1 database is upgraded to target version on dev copy
#2 modifications and modules and design are applied. All the SQL changes are collected into a separate report.
#3 right before going live, the live store is being closed (and backup is saved), its database is taken as is and upgraded once again.
#4 SQL changes from #2 are applied to this database
#5 this fresh database with latest data is assigned to the upgraded software and the upgraded store replaces the old site.

Under no circumstances do I state that this is the only and best way. If we take each particular store separately, there may probably be much better solutions, and even this 'sync' script will work perfectly. But the more stores we need to cover ( and I guess you expect us to provide a solution which will work for most if not for all the users), the less is the possibility that such a synchronization will not result in new questions.

PS this is my personal opinion. Please do not consider it to be some kind of 'official comments'.

I hope Maxim will shed some light on this question later.

One thing not mentioned here and it will solve the problem of which data to sync - the dev store is there to develop the new store with new version, skin, look, fell, functionality, etc. The dev store is not there to make changes to products, categories, manufacturers, etc.. So your question what to sync or to sync new or ignore shouldn't be there in the first place.

When dev store is ready to go live sync from live store - overwrite completely
- products, categories, manufacturers and all related tables like discounts, coupons, special offers, images, zones, taxes, etc.
The dev store should not be adding, deleting or making any changes to store data.

When dev site is ready to go live do NOT sync from live store at all
- config, languages, modules and related tables
These tables hold the store config and settings so they should be taken from the dev store and not modified by the upgrade script.

It is that easy to determine what to sync and what not.

When syncing the actual store data do it by specifying exact fields in the query so even if for example products table has new fields added by a modification the query will not fail, also do it with "replace" and not with "insert". This has been a problem with many upgrades because XC sql patch uses "insert" and if a patch or modification has been applied years before with the same data the upgrade fails...

This all assumes once an upgrade is started it doesn't matter if it takes one week or couple months - no changes to live store config/settings should be made as this will not be transferred over and no changes to store data should be made in dev store (other than for testing) as this changes will be overwritten

Another one - how to determine what data is new and what not - this is design flow of XC.
- Orders can be determine as there is order date. But if you use AOM to modify the order 2 weeks from that date .....? Does the order date changes? Probably
- Customers cannot - there is no date when customer profile was created. There are dates for when it was last accessed or modified but no fixed date when it was created. Not a bug but design flow.
- There is no date when a product was created. There is date when it was last modified but no fixed date when it was created. And as many want to show new products using this date it so happens that this is wrong - create a product today, 2 months from now you see you made a spelling error in the description - correct it, the date changes and makes the product new again... Wrong. Serious design flow.

[jrsvsp]

Originally Posted by Ksenia

If you have a live store on one hand ( which keeps generating new orders, customers, inventory changes) and upgraded store of a different version ( with new modules, changes to database, as well as, often, new data, such as products, images etc)on another hand, this 'synchronization tool' becomes a problem.

*which exactly type of data to move (customers? products? categories? orders?anything else?)
*how to define which data are new and require migration?
*what to do with different tables structure if the modifications/modules on dev copy affected the database?
*what to do with IDs if the same ones are present in two databases ( say , new product/user is created in live store and another new product/user with the same id - on dev copy) - overwrite, ignore? even if you personally do not add anything to dev copy, you should keep in mind that some people still tend to.

These are the problems I foresee at a first glance. If we ask upgrade team engineers, they will most probably give a dozen of other potential questions without clear answer.

Probably that's why even the upgrade engineer with more than 10 years experience often prefers this scenario:

#1 database is upgraded to target version on dev copy
#2 modifications and modules and design are applied. All the SQL changes are collected into a separate report.
#3 right before going live, the live store is being closed (and backup is saved), its database is taken as is and upgraded once again.
#4 SQL changes from #2 are applied to this database
#5 this fresh database with latest data is assigned to the upgraded software and the upgraded store replaces the old site.

Under no circumstances do I state that this is the only and best way. If we take each particular store separately, there may probably be much better solutions, and even this 'sync' script will work perfectly. But the more stores we need to cover ( and I guess you expect us to provide a solution which will work for most if not for all the users), the less is the possibility that such a synchronization will not result in new questions.

PS this is my personal opinion. Please do not consider it to be some kind of 'official comments'.

I hope Maxim will shed some light on this question later.

I agree the devt store should not be adding products/users/categories etc .

This sounds good in theory, but in practice there is no simple way to collect all the SQL changes ? Unless I missed something..... If this was possible it would certainly help.

I think an easy way is to provide simple export/import for all the major customer related items, such as :

Customers (you could select by last logon date maybe)
Orders (by date)
For products then I think you can maybe freeze new products, but you do need a simple import/export for prices and quantities in stock

This is not a total solution, but would be a practical approach. What we lack at the moment is the ability to import/export orders, quantities or prices in a simple manner (we can export orders, but not import, and we can import prices and quantities but not export in the same format).

By the way, if the advice is correct, then why can't we go from 4.4.5 to 4.6.0 by upgrading the DB and then connecting to a fresh instal of 4.6.0 instead of having to instal 4.5.0 and then apply an upgrade to get to 4.6.0?

[cherie]

I'm glad we're revisiting the upgrade discussion. Hopefully this will spur a new vision for future improvements to the upgrade system that went the wrong direction with 4.5.5.

[elmirage001]

Dear X-Cart Team,

Question Please: Why is there no DB upgrader 4.5.0->4.6.0 ?

It's like getting in your car in the back seat and having to climb over the seats into the drivers seat to drive. It can be done but...

I will be moving a copy of my live 4.4.5 database to 4.6.0 two to three more times before I go live on 4.6.x and having to install a fresh copy of 4.5.0 each time just to upgrade the database from 4.5.0 to 4.6.0 is not an efficient use of time.

Thank you,

Paul

[Jon]

The database changes from 4.5 to 4.6 are very minimal and seems to me could easily be applied with an SQL patch rather than an upgrader.

[carpeperdiem]

Originally Posted by Jon

The database changes from 4.5 to 4.6 are very minimal and seems to me could easily be applied with an SQL patch rather than an upgrader.

Jon, there were major database changes from 4.5.4 to 4.5.5, and that's where the trouble (and the process) started to get "tricky".

A 4.5.4 to 4.5.5 upgrade is a bigger challenge (I have not been successful doing this with my 4.5.4 - tired 3 times and gave up - documented in the forum) than 4.5.5 to 4.6.0 (which I have been able to do with default databases and default products).

The way I test upgrades -- make a fresh install, then upgrade it. If it doesn't work on default virgin installs, there is no way in hell it will work on a gently modified store. I had nothing but trouble going 4.5.4 to 4.5.5 and if you can't do that, there was no way to do 4.5.4 to 4.6.0 (unless they've made substantial changes to the upgrade script).

I am at least a few weeks away from wanting to upgrade 4.5.4 to 4.6.x, so I am actively following along - but until my mission critical mods are 4.6.x ready (including 3 of your essential mods:

WCM CDSEO Pro
WCM Remember Me
WCM ezUpsell

and the rest of my "mission critical I won't launch an xcart site without these mods"
AC OnSale
AC Checkout_One with tools suite and XPC
AC cash rewards
CFL popup error messages
CFL quick view
-> I am also using TXS X-Menus (my new BFF) and 2 TXS templates, but TXS claims to be compliant with 4.6 -- that was fast.

... have no interest in building the 4.6 store without these 3rd party solution, so X-Cart needs the devs to come to the table in full force. Did they send you all flowers or candy?

Any developers reading this, how much code do you really have to change to take a perfectly fine 4.5.5 mod and make it work with the new 4.6 module system? Is it really one line of code, or is there more to it than that? [just wondering] -- PS the 4.6 module system is totally cosmetic and doesn't change any functionality -- it simply categorizes modules by type, and then uses ajax to turn them on or off. This is a feature that is simply cosmetic, but the fact that it requires mods that I own to be modified, and the devs of these mods may (should) charge me for the work required to edit and re-encrypt and test and distribute... and if I have any integration issues because I used to have version 4.5.4 and now I have version 4.6.x, so there will be debugging and possible support requirements... the X-Cart team did not consider what a minor cosmetic change to the module page would do to every upgrading store.

Which takes me back to:

The Prime Directive -- er, bug fixes only for minor releases, new features in major releases - XCart can and should charge a nominal upgrade fee for major (new features) releases - I doubt ANYONE will not pay US$50 for a boat load of new features every 12 months. But with the power comes great responsibility -- the incremental releases must be rock solid.

http://www.carpeperdiem.us/xcartforum/broken-record.jpg

[aim]

If after placing the upgrade pack XC4.5.x-XC4.6.0 contents in the X-Cart installation folder you see a white screen or receive an HTTP 500 - Internal Server Error, and your store has Customer_Reviews module enabled and the option 'Use new module initialization routine' disabled, you can try and fix this problem using one of the following methods:

* Temporarily (for the time of upgrade) comment out the call for
//func_customer_reviews_init();
in the file
modules/Customer_Reviews/init.php

or

* Temporarily disable the module Customer_Reviews via the restored Admin area or using the sql request "update xcart_modules set active='N' where module_name='Customer_Reviews';" (Be sure to clear the 'var' cache directory)

or

* Temporarily enable the option 'Use new module initialization routine' via the restored Admin area or using the sql request "update xcart_config set value='Y' where name='use_new_module_initialization';"

[ADDISON]

I would like to know when FeatureComparison and ProductConfigurator will be ready for 4.6.0.