Filtering Products by Attribute Combinations

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
13 年 前
Hi All,

Is there currently anyway to filter products by Attribute Combinations? Or is it just product specifications?

I would like to be able filter products based on one of thier attributes in this case "Clothing Size" but I only want to return Products which have that clothing size in Stock based on the Attribute Combinations.

Anybody done this before? Or shall I get coding?

Thanks

Jacques.
13 年 前
No, this feature is not supported out of the box
13 年 前
OK Thanks Andrei.
13 年 前
JaxUK wrote:
Hi All,

Is there currently anyway to filter products by Attribute Combinations? Or is it just product specifications?

I would like to be able filter products based on one of thier attributes in this case "Clothing Size" but I only want to return Products which have that clothing size in Stock based on the Attribute Combinations.

Anybody done this before? Or shall I get coding?

Thanks

Jacques.


I am interested in this too.
13 年 前
Do you mean within the product template (i.e. VariantsInGrid)?
13 年 前
danzik17 wrote:
Do you mean within the product template (i.e. VariantsInGrid)?


No, it means for the atribute combinations. Example if you sell shoes where the products attributes are colour, size and width, to have searches or filtering for thos models colour=black, size=7 and width=b
13 年 前
Ah I understand now, thanks.
13 年 前
eadameg wrote:

No, it means for the atribute combinations. Example if you sell shoes where the products attributes are colour, size and width, to have searches or filtering for thos models colour=black, size=7 and width=b


Yep, Just like that! If anyone does any work on this please let me know.. Otheriwse I might have a look into it next month.
13 年 前
I'm currently dealing with a product import where size and colour are the attributes, and it is a requirement for stock-keeping to have an individual SKU for each colour/size combination. In addition, specific colour/size combinations have their own pricing.

Method one with nopCommerce:
Add a product. Add a single variant. Add attributes for size and colour. Add attribute details for each specific size and colour.
Pros:
Attribute options presented in drop-downs.
Cons:
Can't have a price specific to each colour/size combination. Using the price adjustment becomes very messy, and it cannot cater to each permutation.

Method two with nopCommerce:
Add a product. Add a variant for each colour/size combination. Add attributes for size and colour, and one attribute detail per attribute for each product variant (adding the attributes can be considered optional for this example).
Pros:
Prices can be set for each individual combination.
Cons:
Variants are listed individually, with many products having 20+ variants this can be time-consuming for the customer to find what they need.

The system I am migrating from assigns attributes to the product itself, with attribute details being assigned to the attribute. Then variants (SKUs) are presented in a grid form showing each combination, and checkboxes are used to indicate which combinations should be generated as variants. This allows for greater versatility with product management, and avoids problems with SKU selection and pricing.

Having researched previous posts on these forums it sounds like quite a few of us are working on a solution to the same problem. I'm currently toying between two approaches: replacing the current product/variant/attribute structure in nopCommerce (very time consuming and lots of code to go through) or preparing a new product details template that displays variants as a matrix. I'd dearly love to redo the way products and attributes are implemented in nopCommerce but my concern is that if the benefits aren't immediately apparent then the nopCommerce team may be reluctant to roll the changes into the main solution - meaning that each new release of nopCommerce would require a lot of work by myself to update my branch of the code.

Any thoughts from other developers on the best approach for this?
13 年 前
Tzael wrote:
I'm currently dealing with a product import where size and colour are the attributes, and it is a requirement for stock-keeping to have an individual SKU for each colour/size combination. In addition, specific colour/size combinations have their own pricing.

Method one with nopCommerce:
Add a product. Add a single variant. Add attributes for size and colour. Add attribute details for each specific size and colour.
Pros:
Attribute options presented in drop-downs.
Cons:
Can't have a price specific to each colour/size combination. Using the price adjustment becomes very messy, and it cannot cater to each permutation.

Method two with nopCommerce:
Add a product. Add a variant for each colour/size combination. Add attributes for size and colour, and one attribute detail per attribute for each product variant (adding the attributes can be considered optional for this example).
Pros:
Prices can be set for each individual combination.
Cons:
Variants are listed individually, with many products having 20+ variants this can be time-consuming for the customer to find what they need.

The system I am migrating from assigns attributes to the product itself, with attribute details being assigned to the attribute. Then variants (SKUs) are presented in a grid form showing each combination, and checkboxes are used to indicate which combinations should be generated as variants. This allows for greater versatility with product management, and avoids problems with SKU selection and pricing.

Having researched previous posts on these forums it sounds like quite a few of us are working on a solution to the same problem. I'm currently toying between two approaches: replacing the current product/variant/attribute structure in nopCommerce (very time consuming and lots of code to go through) or preparing a new product details template that displays variants as a matrix. I'd dearly love to redo the way products and attributes are implemented in nopCommerce but my concern is that if the benefits aren't immediately apparent then the nopCommerce team may be reluctant to roll the changes into the main solution - meaning that each new release of nopCommerce would require a lot of work by myself to update my branch of the code.

Any thoughts from other developers on the best approach for this?

Maybe method three: Create just one attribute which has the combinations of both size and colour, so for each attribute value  you can assign a price increase: example "red 1" +$25; "red 2" +$27; "black 1" +$20...
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.