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 ;)
1. No, this is not planned. I'm not sure it can be achieved easily. What's the point in variations if the will be displayed at separate URL. I understand SEO purpose - but still don't understand why would one use variations in this case. usual separate products will do the trick.
2. Changing Features in variation products is not planned. When we will adapt variations for Data Feed & Google Export probably will add this feature.
I suppose you are talking about GTIN here?
3. We are working on detailed description and demo - I think it will be easier to take a look in real life.
4. Each variation will have own regular product id. Example parent product has id 1, variation A has id 2, variation B has id 3 etc.
5. No test were mades regarding performance yet. Most probably variations won't be took into account in filtering. Can not say anything certain regarding this at the moment.
1. No, this is not planned. I'm not sure it can be achieved easily. What's the point in variations if the will be displayed at separate URL. I understand SEO purpose - but still don't understand why would one use variations in this case. usual separate products will do the trick.
2. Changing Features in variation products is not planned. When we will adapt variations for Data Feed & Google Export probably will add this feature.
I suppose you are talking about GTIN here?
3. We are working on detailed description and demo - I think it will be easier to take a look in real life.
4. Each variation will have own regular product id. Example parent product has id 1, variation A has id 2, variation B has id 3 etc.
5. No test were mades regarding performance yet. Most probably variations won't be took into account in filtering. Can not say anything certain regarding this at the moment.
1. We do this so that there is a dedicated URL that is content specific. So google will index every product as a different one, and therefore this will work out better if you search for a certain product variant in google. Furthermore, we just need the variant selector (as we really need this to show that we have variant products!)
2. Great to hear, but for now we just need to specify the color in the properties for all variants, which is not that useful either.
3. Okay, please send some sort of link whenever this gets release (slack perhaps).
4. Okay, seems reasonable.
5. Will all the google categories be submitted in a seperate database as this does increase filtering performance by a TON.
I asked one of my clients who uses options heavily to write something up, see below. I hope it helps.
We have a few thoughts:
1. Regarding the structure of the way products and options are set up: Comparing CS-cart’s current method of option combinations with the way they say that Amazon and others do this, the OTHER is definitely superior – to create separate ITEMS that are then grouped together for sales. It would be a definite plus for many reasons, especially for inventory… BUT we would want to make sure that there would still be a way that SINGLE products could use options that did not necessitate the creation of new products. For example, some of our products have so many options that if we had to create a separate product for each option combination, we’d be making thousands of separate products. We COULDN’T do it!… and we would still need the ability to create option combinations that would display an image for each unique set of options. There also would need to be a way, even on those separate products, to add options that would not have to define the product URL.
2. It would be SO WONDERFUL if we could have a way to have an option add a fixed cost to the TOTAL instead of to the cost of each item. This is useful for anyone that sells a SERVICE connected with a product. For example, we sell announcements in multiples of 10. If a customer wants lined envelopes, that adds $0.25 to EACH announcement – that’s easy… it’s how the options currently function. But if we want to add a RUSH to the order, that’s a fixed cost of $10 and we want it to apply to this product as it adds to the cart, but they don’t want to pay $10 for EACH announcement. A checkbox that would let us define an option as a “single charge†would open up wonderful possibilities for us.
3. It would be SO WONDERFUL if when ordering a product we could group options together that are related. For example on a computer order have a hardware option area, then a software option area, etc. Some of our products have so many options the page gets quite long, we had a addon done to allow grouping of options in a popup window so the customer doesn't have to keep scrolling down. This would be a NICE feature to have built in.
4. It would be SO WONDERFUL if we had the ability to add more text, html, pictures, tables, etc with an option to help the customer. The current limited option description capability is not sufficient to describe some complex options to a customer.
5. Limit the SQL query or memory requirements for options. On the current version of cs-cart, we hit a PHP or memory limit on options that have hundreds of variants. This should not be happening. Better coding should prevent this in the new version.
5. Limit the SQL query or memory requirements for options. On the current version of cs-cart, we hit a PHP or memory limit on options that have hundreds of variants. This should not be happening. Better coding should prevent this in the new version.
Well, they could make it way faster if they would somehow cluster the option descriptions. You could ask the creator of your product option modification to add an extra column that gives the groups of options a 'group_id' which would then be queried first (as this would reduce the time of the queries by a great amount if you indeed have 100's of them).
What also might be an idea is to store the product option variants in a seperate table, or just the normal products to reduce the categories loading time and total table size.
I asked one of my clients who uses options heavily to write something up, see below. I hope it helps.
We have a few thoughts:
1. Regarding the structure of the way products and options are set up: Comparing CS-cart’s current method of option combinations with the way they say that Amazon and others do this, the OTHER is definitely superior – to create separate ITEMS that are then grouped together for sales. It would be a definite plus for many reasons, especially for inventory… BUT we would want to make sure that there would still be a way that SINGLE products could use options that did not necessitate the creation of new products. For example, some of our products have so many options that if we had to create a separate product for each option combination, we’d be making thousands of separate products. We COULDN’T do it!… and we would still need the ability to create option combinations that would display an image for each unique set of options. There also would need to be a way, even on those separate products, to add options that would not have to define the product URL.
2. It would be SO WONDERFUL if we could have a way to have an option add a fixed cost to the TOTAL instead of to the cost of each item. This is useful for anyone that sells a SERVICE connected with a product. For example, we sell announcements in multiples of 10. If a customer wants lined envelopes, that adds $0.25 to EACH announcement – that’s easy… it’s how the options currently function. But if we want to add a RUSH to the order, that’s a fixed cost of $10 and we want it to apply to this product as it adds to the cart, but they don’t want to pay $10 for EACH announcement. A checkbox that would let us define an option as a “single charge†would open up wonderful possibilities for us.
3. It would be SO WONDERFUL if when ordering a product we could group options together that are related. For example on a computer order have a hardware option area, then a software option area, etc. Some of our products have so many options the page gets quite long, we had a addon done to allow grouping of options in a popup window so the customer doesn't have to keep scrolling down. This would be a NICE feature to have built in.
4. It would be SO WONDERFUL if we had the ability to add more text, html, pictures, tables, etc with an option to help the customer. The current limited option description capability is not sufficient to describe some complex options to a customer.
5. Limit the SQL query or memory requirements for options. On the current version of cs-cart, we hit a PHP or memory limit on options that have hundreds of variants. This should not be happening. Better coding should prevent this in the new version.
David
Hi David,
Thank you for detailed feedback, as I see most of them concerns current options and combinations implementation, not the new variation feature. I will try to go through your points.
1) Is this about that you would like to keep old combinations work same way as it work now?
I can say for sure that current options will work as before in new implementation. So you will be able to
a) select a single product with options, modifiers etc (same as you can now)
b) select a configurable product (the one that stores its option combinations in separate products)
2) I see. You need option modifiers independent of quantity. I don't thing we will add this. It's more like a custom feature.
3) It's rather unique case when you have a lot of options, and it's more about design/template to configure the look and feel, not about how it works.
4) We have comment and description fields for all options, and in case you want to show there more information - it's also about templates / styles
5) Sql and PHP should work fine even if there are a lot of options. If you have any exact bug reports or problems we will investigate this. Please write me about this.
5) Sql and PHP should work fine even if there are a lot of options. If you have any exact bug reports or problems we will investigate this.
This is a big headache for my clients that needs to be fixed in the next release. Some options have hundreds of variants. The Admin area won't let any more variants after say around 80 (yes, it is server configuration dependent). But this is poor coding if this limit exists. We are forced to use PHPMyAdmin to add more variants. The Front-end works fine, just the admin is hitting a PHP variable limit.
5) Sql and PHP should work fine even if there are a lot of options. If you have any exact bug reports or problems we will investigate this.
This is a big headache for my clients that needs to be fixed in the next release. Some options have hundreds of variants. The Admin area won't let any more variants after say around 80 (yes, it is server configuration dependent). But this is poor coding if this limit exists. We are forced to use PHPMyAdmin to add more variants. The Front-end works fine, just the admin is hitting a PHP variable limit.
David
We will take a look and try to optimize it if you can provide a sample DB or access to your store.
If you are on the child product page then there is a link to the parent product:
[attachment=12376:variation-of.png]
2. In the Products advanced search popup in the admin area, there is a section where you can select what type of products you'd like to search for. By default "Variation products" are not included in the search.
[attachment=12375:advanced-search.jpeg]
3. Now you can change feature values in variation products. The main idea is to have separate GTIN for Google Export.
4. You can change Shipping properties of variation products.
5. You can change Quantity properties of variation products.
6. Rest API is extended to work with Variation products.
The "Get product list" method now accepts the product_type array with values: P (simple product), C (configurable product), V (variations). By default, only simple and configurable products are selected.
If you want to create a new product varaition, you should specify the following parameters:
product_type = V - type of the product
parent_product_id - id of the parent product
variation_code - variation code in the following format: {parent_product_id}_{variant_id1}_{variant_id1}, e.g.: 12_14_17.
Im hoping that each Product Variation will upload to eBay as a separate eBay item, and conversly, when orders are sync/Downloaded from eBay, that each item will then show in CSC orders as the applicable Product Variant. Will this be the case?
Then there still remains the problem where a Option Variant is actually another product, making a Product Package.
The ebay order for such would need to show in CSC orders as having the separate products the same way it will if using the Product Packages addon.
Im hoping that each Product Variation will upload to eBay as a separate eBay item, and conversly, when orders are sync/Downloaded from eBay, that each item will then show in CSC orders as the applicable Product Variant. Will this be the case?
Then there still remains the problem where a Option Variant is actually another product, making a Product Package.
The ebay order for such would need to show in CSC orders as having the separate products the same way it will if using the Product Packages addon.
I'm not familiar with Product Packages addon.
We will check the work of Variations with Ebay, but I can not guarantee we will adapt it before release.
First you create Simple products (Child products) with its own description, images etc.
Afterwords you create Configurable product (Parent product) and assign child products to that configurable product. Although I did not find how to assign simple products to parent product (probably not yet ready on demo version).
Looks good, but few things:
Could you please show the new sructure of import CSV?
Will we finally have only 1 import CSV, which will include: old product combinatination, extra images, product discount tables, product features?
Could you please bring back product combination price = modifiers (Now called Simple Products prices probably) next to each variant as before (at least for Radio buttons) and add discounted price next to it. So the client do not have to change the combination to know the old and new price.
BTW Any idea when it will be released, next month or later?
First you create Simple products (Child products) with its own description, images etc.
Afterwords you create Configurable product (Parent product) and assign child products to that configurable product. Although I did not find how to assign simple products to parent product (probably not yet ready on demo version).
Could you please show the new sructure of import CSV?
Take a look at attachment, first line is configurable product, lines 3 to 8 are variations. Ass you can see some fields of variations are empty (like Category, Downloadable etc) - this is because variations inherit some of the properties of their parent (configurable) product. [attachment=12380:options_csv.png]
Will we finally have only 1 import CSV, which will include: old product combinatination, extra images, product discount tables, product features?
Yes you will.
Could you please bring back product combination price = modifiers (Now called Simple Products prices probably) next to each variant as before (at least for Radio buttons) and add discounted price next to it. So the client do not have to change the combination to know the old and new price.
No we can't. If we are talking about variations which have two or more options you just can not find out modifiers price for each option. This is becaise we set absolute price for variation product, and it is not based on modifiers anymore.
BTW Any idea when it will be released, next month or later? Thanks
We plan to release it in "Beta" stage in 4.6.1 in June probably.
No we can't.
If we are talking about variations which have two or more options you just can not find out modifiers price for each option. This is becaise we set absolute price for variation product, and it is not based on modifiers anymore.
I meant could you show Absolute and Discounted Price next to every product variation? For example if you have as follows
Combination product = 20 USD * price of selected variation
Imac - do you have plans when you go to Products > Options to have a search box to filter the options list as well as being able to copy options here? Would be so much easier and the functionality is already there for other screens.