A bit frustrated with the migration process from 3.x to 4.x. CS Cart believes we can just do the store import and be running in production 5 minutes later. I wish it were that simple. We have spend weeks tuning and modifying the Cart for our upgrade. As such, we need to import the core data: products, orders and users, on a regular basis for testing and then one last time right before we cut over. The issue is that the import function does not respect the product_id and user_id on the imports so they break all of the links. Here is how to modify the import of users to preserve the user ID. Keep in mind you need to start with an empty customer table. Keep your administrator accounts, just make sure there is no duplication of user_id
I modified
app\schemas\exim\users.php
adding
'User id' => array(
'db_field' => 'user_id'
),
after
'export_fields' => array(
'E-mail' => array(
'db_field' => 'email',
'alt_key' => true,
'required' => true,
),
make sure you csv fields are in order and case matches on the header row.
1 Like
What's wrong with using the store import addon? It's supposed to keep all data correlated and intact.
Yes, store import is what you wanted to use originally (it will preserve the ID's so that related tables are still related (I.e. users/orders, etc.).
But if you did an upgrade, you can't then use store_import (or at least I've not gotten it to work - it just eats up memory and then dies).
The export/import mechanism is intended to be non-id related so that it can be used to go into new systems as well as upgraded ones. hence new user_id's may not reflect in new orders (assuming both are exported/imported).
I've asked about having store_Import be available for just the 'actualize' portion (syncs orders, customers, products, categories, etc.) but leaves all addons and 'design' stuff alone. But they responded that store import isn't intended to be used to sync between stores and provide no other alternatives.
Using store import is a one shot deal. It needs to be done and then put into production to avoid downtime. You can't make changes or properly test. It's just not practical for a busy store.
EZ, you are correct. Store import is a great starting point, but we need to sync the data (what we are doing manually) for a few weeks while we make changes and debug the new store.
The store import does everything that you're talking about. When you are done making changes and debugging, then you actualize within the store import to resync your data.
The store import does everything that you're talking about. When you are done making changes and debugging, then you actualize within the store import to resync your data.
Yes, but in my experience, if you've already upgraded, then you're pretty much stuck,
The store_import will just eat memory and not complete.
Only effective if you did the store import first on a completely clean current store. Then do your modifications and actualize when you're done.
This solved my issue.
Thanks.