Can you please share your use-case. Why don't you want separate products for variations?
Probably you will use current (old) implementation of combinations.
The whole idea with this Variation thing - is to make it separate products. Because, in fact, when you sell t-shirts you sell many physical products like "t-shirt big white", "t-shirt small red" etc. And it is much easier to export/import these variations as usual. To manage them as separate products.
Hello,
Just a few more questions:
1. Will the products have different URL's (seo purposes)?
2. Will it be possible to share features in feature variants. I for example want to define group item id's so that google will recognize it is an option variant. Will this be possible as this would save me a lot of time!
3. What will not be possible to edit with those variants? What limitations does it have? And how does the database structure change? (so that we can future proof our store).
4. What will the product id's be? For example, now I have created it as follows, you have one main product which is linked to other products by defining a costum option. The ID's for the products will be a mockup of the original ID. So if you have product A with ID 1, the ID of product A variant 2 would be 1_2. This made API calls for me a lot easier, how will this work in the next version?
5. What can we expect performance wise? So after I did this huge database purge I got my store like insanely fast, but this mainly was after deleting all the options regarding the google product categories. Cant this be stored in a seperate table so that the filtering won't be affected by this? Because my store has about 250 products and 100 of them have variants. This store is also in 6 languages. So in the feature table I allreayd have about 5000 entires of features (in all languages). But then the big hit comes in. The total amount of google product categories entries is over 23000. Which makes filtering a PAIN!!!
This will do for now 