Product variant options and attributes

[netzknecht]

Is there a good reason why the product variant differences are represented via the ProductOption and ProductOptionValuemodel instead of simply using Attribute's at the ProductVariant level?

[netzknecht]

Stupid question or are there no reasons for it? 😄 Here's a bit of thought to drive the discussion a bit.

Why is a non-redundant concept pursued in the manifestations of product variants with the ProductOption and ProductOptionValue model and a redundant concept with the Attribute model and attribute_data fields, even if the data collection requirement is essentially the same? Why isn't a uniform approach pursued here?

A ProductOption model 'Size' with ProductOptionValue models 'S,' 'M,' 'L,' etc., could easily be implemented with an Attribute for the ProductVariant model using a ListField or even better, TranslatedListField. For defining a variant manifestation 'Color,' a ColorField could be used, which could also be relevant as an Attribute for a Product model without different ProductVariant models or any other models.

Advantages:

1. More consistent data collection.
2. (Re)use of FieldTypes for defining variant manifestations.
3. Variant manifestations are indexed as attributes for search and can be considered or filtered in full text search (scout/melisearch...)

Disadvantages:

1. Redundant data collection.
2. Revision of variant generation in the hub required.

Fundamentally, a bulk editing function for attributes or the captured attribute data would also be useful at times.

[netzknecht]

Further aspects that speak for the use of attributes:

For example, uniform data collection with attributes would result in simplifications when creating a product comparison function.

When assigning attribute values, additional attributes with values ​​that depend on the input can be automatically defined using attribute rules or special field types. For example, when defining the value "DIN-A4" for an attribute "DIN format", another attribute "Dimensions" could automatically assume the value "297 x 210 mm", and another attribute "Format" could automatically assume the value "rectangular".

[zalito12]

This is an old discussion, but has anyone think about this?

Attributes are very flexible and extensible, but product options are so... simple. I know, simple is not bad but in modern ecommerce there are richer options than text, like colors or images.

I guess you could access the product variant to get an image or a color code to show on product options, but then, what are the purpose of the product options.

At this moment I think there are two main different approaches to enrich product options:

1. Add attribute data to product options.

   • May be the easiest but I think this would be a shortcut and not the best in long term.

2. Create product variants from variant attributes instead of product options.

   • I'm new to lunarphp and I don't know if this could arise hidden problems.
   • Does it really make sense to have both, options and attributes?

I think someone with deep knowledge about the core of lunar should make a bit of analysis to decide how to proceed. IMO this is a nice feature and lot of people would like to help.

I will be testing these approaches on my project development cause I need product options with colors and images.

[glennjacobs]

We do intend to have a good look at this soon. I'm not sure reuse of attributes is the correct way forward, but I can see why it is appealing. We'll certainly be considering this when we come to develop it.