I’m going to look into an adhoc modification myself… and perhaps this doesn’t affect others, but I think it might.
By default, the ability to import features for products is helpful yet limited. Although the format is nicer to work with than strict serialized output, there is a problem with the process.
If you import the same feature/value pairs you export, that’s no problem.
If you wish to add a value that is not already present, it is possible, although tedious to do this en masse.
Recall that generally speaking, the reason anyone would want to do import on large bundles is to avoid tedious repetitive labor at every stage of the process.
The problem here is that the importing process is not intelligent - i.e. it doesn’t look for changes. It essentially serializes the new import information and replaces whatever was there previously.
So… if the rest of your book information is correct, but you want to update the ISBN from ISBN-10 to ISBN-13 - you cannot simply import a new single feature value without destroying values in all the rest of the feature fields.
So, a tedious yet workable workflow includes the following - as an example:
I will export a list of books with various levels of feature data present. Normally I will load this into excel, then cut and paste the feature column into Word.
Then I search and replace globally to replace right and left brackets with pipe characters. This allows me to convert the text column into a table with pipe characters as cell breaks.
Then I bring the new set of broken out columns back into excel - I have columns that are the featured name alternating with columns of values.
Again, I can edit data in this format, but I cannot easily put this back together again because the number of data columns depends on the number of features exported with each product. While there is consistency in the order that fields are exported in, features with no value are not exported at all, forcing all of the data rows to be inconsistent in feature field length.
So CS-Cart needs to do one of two things to address this problem.
A) make the export process comprehensive - i.e. export features with placeholders even when there is no value so that the order of fields is consistent - blank out becomes blank in, etc.
B) make the import process intelligent, so that incoming fields are not merely encoded, serialized and plugged back into the features field - there needs to be an array comparison - say keyed to feature id - so that the only time an existing piece of data is erased is if I include the feature with nothing (like bracket-bracket) as the value.
For example, we are viewing product_id 12435 - load the existing feature values for the product unserialized into an array, iterate through the incoming feature values - replacing the data as necessary in the product array. Then write the feature array back in a serialized format, preserving old unchanged data while including the updated new features.
Until this happens, much of what I would use import for on a regular basis is impossible unless I rewrite the code to handle it.
Which I may do, if no one else has had to face this problem first and has a workable solution.