Before reporting this as possible bug, please advise which method is recommended (best practices), also if the behaviour is correct (by design) or not. I cannot replicate this on demo.cs-cart.com since in demo version import/export features are disabled. My cart was first installed by default as 3.0.2 and successfully updated as 3.0.3 (no single custom changes in templates, code, database etc)
Use case:
I have a cs-cart PRO v.3.0.3, using two languages, currently defining categories and products with related features and filters (so far so good).
Once I have defined appropriate features and tested them manually for various products to display ok, I'd like to bulk update more products at once. I have identified two methods for this:
a. Select products (by category or keyword, for example), then Select All, click Choose Action/Edit Selected, then uncheck all attributes except Features, then click Modify Selected. In Edit All page, I can quickly update features I want for each product (also can “Apply values to all the selected products” as once, where appropriate), it works fine. Note that once this bulk update page is saved, both my languages are updated (previously, I defined feature names and their variants in each language, they are displayed in storefront as expected when changing languages). It makes sense, since each feature has same ID in database, then a proper definition for each language.
b. Second option for bulk update would be using Import Products feature, where in advance I prepare a csv file with features defined according to [url=“CS-Cart Documentation — CS-Cart 4.15.x documentation”]CS-Cart Documentation — CS-Cart 4.15.x documentation (namely {Feature ID} (Group name) Feature name: Feature type[Feature value][color=#555555][font=Arial, Helvetica, sans-serif][size=3] format) - proper IDs for each feature were found in advance by export[/size][/font][/color]ing a product with manually filled in features. The import also works fine (I mean no error reported, so the syntax is fine).
However (here is where I think the bug is exposed):
as opposed to first option (manually bulk edit for selected products), the import version is only updating and overwriting the language selected at import time (say, English).
more exactly, if using first method to bulk update a few products for say, Feature1, Feature2, Feature3, you end up correctly displaying these three features for each language.
afterwards, preparing a csv file with Feature4 and Feature5 (plus mandatory product codes, of course), and importing it for EN language, the import succeeds, however front store will display for respective products:
– in EN: Feature4 and Feature5 (previously created Feature1, Feature2 and Feature3 are no longer displayed)
– in second language: Feature1, Feature2 and Feature3 are displayed as before (I assume, since csv import has been applied to EN only?).
I was expecting similar behaviour as for bulk manual updates, since feature IDs are the same, both languages should have been updated with Feature4 and 5, while Feature1,2,3 should be there as before, in both languages.
another thing that makes me think this is a bug, is that if I go again and edit any product in the Second Language (the one still having Feat1,2,3 correctly in place) and simply save it again, this will again overwrite Features for EN, so I will end up again with Feature1,2,3 displayed ok in both languages but no longer Feature4 and 5 (?!?)
Are these two methods of bulk updating incompatible or I am missing something obvious? Only 2-3 months experience with cs-cart so far, I think is a great product, not sure such bugs were exposed also in v.2 or they just landed in v.3.
Additional note: I don't want to say that the whole product import feature is broken, since I successfully used it before to import (for example) Product code;Category;Product Name;Price;Quantity.
It seems the Feature import is somehow overwriting existing features instead adding next to them (or updating existing ones, if needed).
Sample of my csv for updating two features (already defined in advance) for my products:
Product code;Features
“CODE1”;“{6}(First Features Group) Feature 4: O[0.77]; {10}(First Features Group) Feature 5: O[0.7]”
“CODE2”;“{6}(First Features Group) Feature 4: O[1]; {10}(First Features Group) Feature 5: O[0.9]”
…
In the end, for English version I only had these two features displayed, although I previously added a few other which were displayed correctly (and still are, buit for the other language only). The IDs for these two features above ({6} and {10}) are correct, I noted them when I exported first a similar product with Features already filled in in respective product page. Thank you!
This is the way features have always worked when importing. The reason why is because the feature information is one long string stored in one cell. So when importing feature data, only all feature data can be imported. If you only import partial data, then the cell will be overwritten with the partial data.
Hi The Tool, thank you for your reply. I think indeed this would make sense, if one single Feature field in DB would hold all features as serialized string, this would be one time update for whole string, no matter how many serialized features would contain.
However, having a quick look at database it revealed three features related tables (see below some excerpts):
(there are two more tables for feature variants, but they are not relevant and they also don't contain any serialized value.
As you can see, seems there are no table cells holding strings like
“{6}(First Features Group) Feature 4: O[0.77]; {10}(First Features Group) Feature 5: O[0.7]”
or similar, that would be indeed updated once for all and would explain overwriting.
It seems the import procedure is actually parsing the Feature string from csv file then updates relevant tables accordingly, for respective IDs only. If they can do so, I still don't get it why it completely overrides all previously saved features, when instead is should do inserts or updates for each parsed feature.
Appreciate for your reply, I don't intend to contradict you, maybe I'm still missing something - again, this is v.3.0.3 Pro here, not sure how this import used to work for v. 2.x.
Yes, my mistake. The information in the DB is separated for each feature and each product in cscart_product_features_values. I suppose CSC went the easiest route to import the features which is one string for all features.
brandonvd had a thread on this not too long ago and I believe tbirnseth came up with some kind of solution to be able to import partial data. Most likely it required modifying the queries.
I would love to see an addon or even better, core update that would make Features behave as independent fields (just like any other attribute - Price, Weight, Quantity etc). Not sure how many others have a need for such feature, I would gladly donate if enough users would gather with same intent and if price of developing would be fair enough.
I will still report this as bug, to see what developers say about the overwriting issue, plus for following reason (which can be easily reproduced I think):
create a feature of type Other/Number (say Test-FeatureEN), then switch to a second language and translate its name (say, Translated-Test-Feature)
edit a product to fill in some value for above feature in first language, save, then switch to second language - you will see the label name for the feature is changed, but the value is the same filled in before (which makes sense, number values should stay the same for features no matter the language)
where 38 above is the new feature ID (must be replaced with actual one in other tests, you can get it with a select from cscart_product_features_descriptions or simply exporting the product first, including Features field); The value 17 could be any number in format X.YZ, different that the value inserted manually when editing product (I used 5 originally).
after importing the CSV file for EN language, get to frontstore and check the product in both languages; you will find only the value for EN has changed to 17, while for second language it's still the original one (5 in my case).
This means the import script is behaving different compared to manually editing the product in Features tab.
Thank you for pointers, will check and hope to also get an answer from brandonvs and tbirnseth.
Thank you The Tool for searching this for me. Definitely useful, will be great to be adopted as default behaviour in core (after all, just like for other fields during import, it makes sense to do an insert if new stuff or update if already existing).