Clarifying product attributes and what it does / doesn't mean
Hope the dramatic title drew you in. I believe this is a serious issue for DC, and is clearly being ignored (probably for very good reasons) by those in the know (probably because they are sick of the issue).
However, as understandable as the above is, it doesn't help the project.
As a previous long-time Virtuemart team member, repetitive questions should not be ignored. They are repetitive for a reason, and sometimes the same question needs to be asked and answered in 20 different ways before searching for the answer is effective.
Most importantly, DC is missing a whole arena of e-commerce uses by linking what is an attribute and what is a product.
Virtuemart took huge strides in the Joomla e-commerce field with the brilliant division of attributes vs child products. When you understand the concept, the distinction is clear.
The VM experience taught me an important thing. If you want to a any type of online shop system, you can't ignore whole sectors of use cases. This ends up making a large percentage of potential owners dependent on 3rd party modules.
Nothing wrong with 3rd party modules, but if more than 50% need them to create the basic version of their shop, then the e-commerce system is lacking.
From what I can see, from reading every discussion and article I can find, this is the trap DC has fallen into.
One thing in e-commerce (and real commerce) is super-duper clear - attributes as attributes and attributes as products are two very different things.
Here is an example of attributes as products (The famous T-shirt example):
- Star Wars T-Shirt, 3 different sizes and 3 different colors -
It is clear that each variation of this t-shirt is a different and distinct product. DC is your friend.
Here is example #1 of attributes as attributes
- Dull Deskup Computer 100GB HD, with possibility to have 1GB, 2GB or 3 GB of RAM -
The different RAM options are NOT separate products. The computer case, HD, etc are the same physical items. The only separate product is the RAM itself.
Is DC your friend here? Perhaps product bundles, but we are already in 3rd party module territory with just this basic setup.
Here is example #2 of attributes as (pure) attributes
- Custom T shirt, Large, White, choice of 5 printed slogans
Here, again each of the 5 slogans is not a separate product (the physical t-shirt is the same). Stock control is on one product. The printed slogan is not a separate product.
The shop owner would need to create a separate product for each t-shirt size and each color. This is clear and logical.
But for each t-shirt size, color and each slogan? This is counter-intuitive, and not representative of the physical product. (plus it could mean 100s of products needing to be created if there are the usual range of sizes and colors).
DC is not your friend here.
I hope the above examples highlight one thing, if nothing else. That 'attributes' is not a 'one size fits all' global term for product variation. Or vice versa.
VM solved this years ago with child products vs attributes. Which is fine if you want to use Joomla.
If DC want to stay in this 'framework only' zone, fair enough, but I genuinely don't believe it makes sense to be an Ubercart alternative which then relies on 3rd party modules to produce basic and standard e-commerce functionality.
With the DC terminology, product variations are only attributes as products. I think this clarification is important both for the community and for DC to see what it does not do.
I just want to talk to myself for a moment ;)
What I am finding useful (I think so far), is splitting the concept of attributes / variations in a way that makes sense based on the product.
The Commerce Pricing Attributes module seems to work very well, particularly with elements that add to a product but are not in themselves physical products.
Then I'm using fields with the product variation type to define the different ways that product can exist.
For example, using customised photos in frames as an example (where the frames are made, non-existing before purchase):
The different photos and different photo sizes are fields in the product variation type. So when the various variations are added, there is a different variation for each photo and each size (which may come at the same price or different, but exist as real physical different products).
Then, the frame which is selected by the user by choosing the type of wood (and doesn't exist as a frame before the order is made), is a Pricing Attribute where the different type of wood used affects the price.
So far, this approach seems to be working.
Anyone else tried this?