if u can share beta v2 addon i will work on . thank you
This new feature is awesome!
In my personal opinion:
1 / In each Variation should allow sellers to create more options.
2 / Instead of displaying Variations in the select form, we should add another way of displaying that the radio will be richer.
3 / If a Variation has other features, then it must apply the position? While Variations 1.0 does it
I'm glad you like it.
1. We'll be looking into it soon.
2. Currently, only the "Drop-down list" feature style is available. More styles may appear in future versions.
3. Sorry, I could't understand that part.
if u can share beta v2 addon i will work on . thank you
Unfortunately, we can't share the add-on yet. However, we are planning to provide a "Release Candidate" version before the actual release of 4.10.1.
then when ?
then when ?
then when ?
then when ?
A couple of weeks before the release of 4.10.1. Currently, 4.10.1 in planned for April.
If you add different images for different product variations under color, then you cannot see color thumbnails on the product page. In current implementation of product variations you cannot group variations in one catalog item for Color and have color picker (image thumbnails) on the product page. I think that this scenario might be essential to many users especially if you sell product where model is important and customers are aware that there might be many different color options. Try to implement a car purchase scenario, you first pick model, then you pick color etc. (e.g. https://www.toyota.ru/new-cars/).
Moreover, if model is important the description is the same for all of the color variants. If we copy paste descriptions we will get penalty for duplicate content in search engines. Please address this issue somehow.
Thank you for your suggestion, it is logical. I've listed the color/image picker as a "feature request". It may be addressed in the initial release, or in the future versions.
As for the SEO concerns: when variations belong to one catalog item, all the variations that have "variation_id" in the URL will also have a canonical URL leading to the default variation. Basically, a catalog item equals one page in your store, and "variation_id" only serves as a direct link to selecting particular feature values.
Please remember, that in new product variations if you choose purpose "Group variations in one catalog item" features are inherited from the base product. That is why barcode cannot be displayed on the product page after choosing different variant.
We're planning to address it without a setting in the add-on. So, whether variations will inherit the features of their default variation or not will be your choice.
-
As for your other questions, it's best to keep track of our video reports. Here's the YouTube playlist. Ilya demonstrates all the significant changes, so if anything changes in the presentation of variations on the product list, this will probably be the first place where it will appear (unless we decide to create a dedicated forum topic).
Sounds like there are a lot of use-cases that need to be investigated. That you've announced that it's coming out of beta and there are still all these use-cases with responses of "we're thinking about doing" sounds like you don't really have a product to take out of beta yet.
Given this is a pretty radical change to the definition and presentation of products (along with many changes on the back end to deal with pricing, etc) I'd encourage you to get this one right BEFORE releasing it into the mainstream.
It's more about 2 things:
• Whether or not the new architecture of variations meets the requirements of our clients. So far, it seems like it does, and many requests can be addressed via tweaks, without significant changes.
• What tweaks improvements we can make in the time left until the release of variations. If the new variations didn't suit the majority, we wouldn't have announced their soon release. And that's the reason why the original variations remained in beta for as long as they did.
Variations were marked as [Beta] partly to warn developers that they could change along the way (so that people wouldn't invest in making their add-ons compatible with variations and have those add-ons reworked later). Now that we've moved variations from options to features, there shouldn't be any technological changes of that scale, so the [Beta] tag is no longer necessary.
I personally don't see a lot of difference between this and option combinations (other than price can't be applied to a combination, it comes from the option modifiers). Seems the difference is in grouping and presentation within the catalog.
Seems to me an easier path for existing clients would be:
1) Add price override to combinations indicating that any option modifiers within that combination should be ignored and the fixed price used (then calculate quantity discounts and process promotions).
2) Add a title/name to the combination (default is value1/value2/value3)
3) Modify the listing pages and catalog data to show option combinations like products if they exist for a product.
With those 3 changes, what is the difference between having a whole new data type and fixing an existing mechanism that's been in place for years (not requiring all addon developers to make changes to existing addons nor really any re-training of merchant personnel).
Yes, backward compatibility and familiar interface are a very good point. That's why variations were originally created based on options. But they didn't meet all the requirements and had to remain in beta until we could find a better solution that met most of the needs of our clients.
I'm not a developer, so I can't speak on the technical nuances of why one solution was chosen over another. But variations have been in development for quite a while, and I think that developers considered all the options.
Thank you for your suggestion, it is logical. I've listed the color/image picker as a "feature request". It may be addressed in the initial release, or in the future versions.
As for the SEO concerns: when variations belong to one catalog item, all the variations that have "variation_id" in the URL will also have a canonical URL leading to the default variation. Basically, a catalog item equals one page in your store, and "variation_id" only serves as a direct link to selecting particular feature values.
We're planning to address it without a setting in the add-on. So, whether variations will inherit the features of their default variation or not will be your choice.
This will introduce another problem.Don't make this a global option. If the product has many features then I would need to copy all of those features for each variation. I've sent you an example in PM, please just try to implement this product in new product variations having in mind SEO, productivity and customer friendliness (don't make them to scroll through category pages with thousands of products which are basically the same.)
If you don't want to introduce separate barcode field in cscart_products table then add an option in feature setting if it's value should be inherited from variation, like on the screenshot below. Then we could decide to show e.g. size for t-shirt in feature list as well:
https://ibb.co/pWDwb5Y
Another thing is that in new product variations you got rid of the base product. If I want to have categories where product model is the main criteria to decide if I want to buy or not and color is of secondary importance then:
1) I would like to have a product URL like www.toyota.ru/toyota-rav4 not www.toyota.ru/toyota-rav4-blue
2) On model selection category (www.toyota.ru/models) I would like to see names like "Toyota Rav4", "Toyota Yaris" not "Toyota Rav4 Blue", "Toyota Yaris Blue"
You're getting close to solving all of the problems but I think that you need to make another option:
- Group catalog items as variations
- Group variations in one catalog item
- Group variations in abstract base product
If you choose Group variations in abstract base product then all we need to do is name the Variation Group and add Variation Group url.
I've read many complaints from people who sell radiators, it would solve their problem as well.
It's more about 2 things:
• Whether or not the new architecture of variations meets the requirements of our clients. So far, it seems like it does, and many requests can be addressed via tweaks, without significant changes.
• What tweaks improvements we can make in the time left until the release of variations. If the new variations didn't suit the majority, we wouldn't have announced their soon release. And that's the reason why the original variations remained in beta for as long as they did.
Variations were marked as [Beta] partly to warn developers that they could change along the way (so that people wouldn't invest in making their add-ons compatible with variations and have those add-ons reworked later). Now that we've moved variations from options to features, there shouldn't be any technological changes of that scale, so the [Beta] tag is no longer necessary.
Yes, backward compatibility and familiar interface are a very good point. That's why variations were originally created based on options. But they didn't meet all the requirements and had to remain in beta until we could find a better solution that met most of the needs of our clients.
I'm not a developer, so I can't speak on the technical nuances of why one solution was chosen over another. But variations have been in development for quite a while, and I think that developers considered all the options.
and where might one find these requirements of which you speak?
Also, other than the brief forum threads here that happen post-development, where is the customer input and most importantly customer requirements related to variations.
Please identify specifically what requirements you have would not be met by the extensions I've outlined above. Seems that things are geared entirely on the simple case of things like clothing product properties. How does it fit for custom engraving when you have properties like:
Material: wood, brass, pewter
Size: 5x8, 3x2, 10x10
Outline color: black, blue, green
Engraving text: [input box with text]
And anything that might be sequential in nature like cart parts with make->model->year->engine.
None of this is addressed in any of the documentation so it's hard to figure out where this is going to apply other than tee shirts.
Just trying to understand the extent and purpose of the implementation.
How do you define which feature precisely will be used as a SEO name differentiator?
So, instead of having separate product options, now each feature will be having product-constitutive options...
How do you define which feature precisely will be used as a SEO name differentiator?
So, instead of having separate product options, now each feature will be having product-constitutive options...
It's simple: a catalog item is supposed to have its own SEO name. So, if a feature warrants a separate catalog item (that is determined by the "Purpose" you choose for the feature), then it will have a SEO name. Variations based on that feature will have "variation_id" and a canonical URL leading to the "catalog item".
and where might one find these requirements of which you speak?
Here's the list of shortcomings of option combinations addressed by Variations 1.0 (the Beta add-on that's been available since version 4.6.1).
Here's why we worked on variations 2.0. As a non-programmer, I could say: "Hey, variations are good. Just add filtering by variations, SEO names, the checkbox to 'Show this variation in the catalog as a separate product', and improve the import, and they'll be ready to go out of Beta." But there were technical reasons why it wasn't feasible or possible, and why we developed "Variations 2.0" based on features. That's as much as I can say.
How does it fit for custom engraving when you have properties like:
Material: wood, brass, pewter
Size: 5x8, 3x2, 10x10
Outline color: black, blue, green
Engraving text: [input box with text]
Custom engraving is an option rather than a feature. Whatever you add to the existing product, it doesn't affect the quantity of that product. In short, whatever affects inventory should probably be a product feature; whatever doesn't affect inventory can probably be an option. But it's a very case-by-case thing, that's why the documentation doesn't cover it yet. But now that you mentioned it, that could make a good article or a tutorial video which would stay relevant for quite a while.
And anything that might be sequential in nature like cart parts with make->model->year->engine.
Wouldn't that be better off as filters? I went to the first car parts site I could find, and that was indeed the case. At first glance, you might not even need variations in that case, just products with features.
This will introduce another problem. Don't make this a global option. If the product has many features then I would need to copy all of those features for each variation. [...] Add an option in feature setting if it's value should be inherited from variation, like on the screenshot below. Then we could decide to show e.g. size for t-shirt in feature list as well:
https://ibb.co/pWDwb5Y
I may be missing something, but I don't understand why you'd need to copy all those features. I think that in most cases they'd be there already. Could you tell me:
1. How often you have to add a new feature/change feature values for existing products?
2. If you need to add a new product, would you generate variations from an existing product, or import a CSV/XML file?
3. If you use import, then doesn't your file already have separate entries for each stoller model/color, with prices and quantities?
Don't make customers scroll through category pages with thousands of products which are basically the same.
That's exactly the reason why we added two distinct "Purposes" for features. To have fewer products, you'd need to select another purpose. You did mention the problems that would arise from selecting the purpose I suggested, and we've taken note. That's why we're planning to let variations have their own feature values (like variations 1.0 could). There's also a matter of thumbnails, but that's what the "Feature style" field is for. We may add variants other than "Drop-down list" (like "Radio group", "Colors", or "Images").
I think that you need to make another option:
If you choose Group variations in abstract base product then all we need to do is name the Variation Group and add Variation Group url.
- Group catalog items as variations
- Group variations in one catalog item
- Group variations in abstract base product
I've read many complaints from people who sell radiators, it would solve their problem as well.
Personally, I think that an extra purpose would overcomplicate the product without need. "Variation group URL" is already the SEO name of the default product, and we're planning to add "Common name" to the default product as well.
Another thing is that in new product variations you got rid of the base product. If I want to have categories where product model is the main criteria to decide if I want to buy or not and color is of secondary importance then:
1) I would like to have a product URL like www.toyota.ru/toyota-rav4 not www.toyota.ru/toyota-rav4-blue
2) On model selection category (www.toyota.ru/models) I would like to see names like "Toyota Rav4", "Toyota Yaris" not "Toyota Rav4 Blue", "Toyota Yaris Blue"
This scenario can be handled by current variations:
1. Make a feature "Color" with the "Purpose: Group variations into one catalog item" (this is where a "Feature style" other than "Drop-down list" would come in handy).
2. Create a product Toyota RAV4. (SEO name will be /toyota-rav4) Choose any color for it.
3. Generate variations with other colors.
4. Set the "Common name" for the default variation to "Toyota RAV4" (we're planning to add that field before the release of 4.10.1).
5. You get a "Toyota RAV4" without color in its displayed name or SEO name.
It's simple: a catalog item is supposed to have its own SEO name. So, if a feature warrants a separate catalog item (that is determined by the "Purpose" you choose for the feature), then it will have a SEO name. Variations based on that feature will have "variation_id" and a canonical URL leading to the "catalog item".
Thanks. Will the variations have a "child" access to the main product_id-related features, descriptions, etc., or they will be reproduced in a separate product table raw?
If you have a special template for creating the product Title, meta-descriptions, -tags, and SEO name, will this template work with the variation_ids? I am asking this because the present Common Products for Vendors (BETA) is not allowing the generation of such product pages. In short, whatever product is not entirely cloned, will create problems for the other parts or vital addons of the system.
Thanks for the detailed response. So in essence, if a product is identified as a combination product (forget the name you use) it will be like Shopify. I.e. there is no real parent product just a bunch of variations that are "based" on the same core product.
Regarding the car stuff (or sequential options/filters to get you to the products you want/need). Selling car covers in 2 different materials and 4 colors. But are make/model specific. I.e. "Blue" "canvas" car cover for 2010 GM Camaro. Where "Blue" and "canvas" would be the features that have variations.
Another question is upon import, will unknown features specified be automatically created? I.e. if someone imported a product that had Magenta as the color but Magenta didn't exist in the Color feature.
My summary... Please correct where wrong.
A product designated for 'variations' will have options set in the parent product and then each variation (cs-cart combination, shopify variants) will have it's own name, page title, product_code, seo info, price for each combination of the features identified for the product.
The parent product will then not be visible to customers, only the variations and there will be no SEO info related to the parent. However, the parent product can be imported/exported to set the features/options, base price, etc.
So if one sells car covers with 10 colors and 2 fabrics but covers for Corvettes have a $10 modifier the general config would look something like:
Car cover with "model" option where "Corvette" would have a $10 option modifier
The Color feature would be selected and the applicable colors for the variations can be selected for each base product.
The Material feature would be selected and the applicable materials would be selected for each base product.
In this case there would be 20 variations of the product and each one could be affected the the "Model option" and possible modifiers.
It would be possible to adjust the price for those variations where Material = cotton versus polyester.
The customer would see a listing for 20 products (the variations) but would never see the base product from which the variations were created.
If a new color becomes available, it can be added to the set of Color features and then selected in the base product. Will the 2 new variations (Material/NewClor) be added automatically? Or will the variations need to be rebuilt?
If the base product is imported with a new price, is that reflected in the variations? Or will one have to go edit the price for 20 different variations?
My summary... Please correct where wrong.
A product designated for 'variations' will have options set in the parent product and then each variation (cs-cart combination, shopify variants) will have it's own name, page title, product_code, seo info, price for each combination of the features identified for the product.
There is no base product in new variations. Each product has to be a phisically sold product so you will not be able to create a pseud-parent product. And that is a huge problem for part of the offer in my store.
@Ikoshin please forward this message to @Imac
If you think of the new product variations as inheritance in OOP (object oriented programming) then you forgot to implement abstract parent class.
I may be missing something, but I don't understand why you'd need to copy all those features. I think that in most cases they'd be there already. Could you tell me:
1. How often you have to add a new feature/change feature values for existing products?
2. If you need to add a new product, would you generate variations from an existing product, or import a CSV/XML file?
3. If you use import, then doesn't your file already have separate entries for each stoller model/color, with prices and quantities?
I would need to copy all of those features because I don't clone the products, I create them via API based on data gathered in my ERP system.
I treat cs-cart as a presentation layer of my offer. In order to not manually duplicate same data in many different systems I have an integration.
1. I don't have to change feature values for existing products at all. The problem is that in my industry I have to add many new color variations because the product model remains the same for many years but the colors are changing (in many cases a few times a year).
2. We create products via API (ERP integration) and all of the products will be grouped later on by the category manager in the cs-cart admin panel. The workflow for us is following:
a. We create products in our ERP system based on price lists, add images etc.
b. From the level of our ERP we add the products to cs-cart via API.
c. category manager groups the products into variations.
I think that you make a wrong assuption that all of cs-cart users clone or generate products based on assigned features. It's not true.
3. Even if I would use import/export in cs-cart, my suppliers don't provide specific information. Usually you get information like:
a. Product name
b. purchase price
c. VAT
d. SRP price
e. GTIN
Those are simple price lists without any features, images and many other essential information. There is in most cases someone involved who prepares the data manually and collects information from many other sources with semi-automatic methods. It doesn't matter if I choose import/export or create products via API. It doesn't make any sense for me to care about the features in those tools.
Even if there would be features in the price lists which we get from our suppliers we still would need to add our own features, e.g. in order to use addons such as intellectual selection of products with features. If you don't believe me, create a poll and ask how the cs-cart users clone products and what is the workflow in managing (adding) products in big stores (above 10 000 products).
That's exactly the reason why we added two distinct "Purposes" for features. To have fewer products, you'd need to select another purpose. You did mention the problems that would arise from selecting the purpose I suggested, and we've taken note. That's why we're planning to let variations have their own feature values (like variations 1.0 could). There's also a matter of thumbnails, but that's what the "Feature style" field is for. We may add variants other than "Drop-down list" (like "Radio group", "Colors", or "Images").
Personally, I think that an extra purpose would overcomplicate the product without need. "Variation group URL" is already the SEO name of the default product, and we're planning to add "Common name" to the default product as well.
This scenario can be handled by current variations:
1. Make a feature "Color" with the "Purpose: Group variations into one catalog item" (this is where a "Feature style" other than "Drop-down list" would come in handy).
2. Create a product Toyota RAV4. (SEO name will be /toyota-rav4) Choose any color for it.
3. Generate variations with other colors.
4. Set the "Common name" for the default variation to "Toyota RAV4" (we're planning to add that field before the release of 4.10.1).
5. You get a "Toyota RAV4" without color in its displayed name or SEO name.
It will not solve the problem because of a few reasons
1. In our use case there are too many changes with new colors coming to the offer and old colors leaving the offer. Changing all the time seo name would be frustrating and dangerous. What if we need to delete old color and we've spent our SEO budget for linkbuilding /toyota-rav4. We need to create 301 redirect, right? If we change this multiple times a year it also influences performance which leads to SEO penalty for given URL...
2. Right now there is no color picker in this purpose so we cannot use this.
There is no base product in new variations. Each product has to be a phisically sold product so you will not be able to create a pseud-parent product. And that is a huge problem for part of the offer in my store.
@Ikoshin please forward this message to @Imac
If you think of the new product variations as inheritance in OOP (object oriented programming) then you forgot to implement abstract parent class.
Then how are options applied to the variations? I.e. a product variation must be able to have options and option modifiers. I.e. non-feature items (using car paradigm), Model=Corvette is $10 more than other items where "Model" is an option, not a feature. Also there are things in common across variations like descriptions, page_title, etc.
There better be a parent product for all the things in common or there's no value in having variations at all. Might as well just create a whole bunch of new products.
As far as I understand, all products having a product_id are turned into abstract products, each representing a set of general ideas (called features). The concrete products are now those that bear a variation_id, which represents the materialization of this or that general feature, say, color, into feature variation red, blue, yellow, etc. If a general product Shirt has no color or size variations, it will remain in the Plato's cave, hovering in the limbo of abstract ideas.