restore the capability to have variations in a product (colors, sizes, etc.)

I think that the color/size/whatever taxonomy variations are going to be too limited. Product derivatives are still products and should be treated as such. A product's price, description, weight, color, or any other attribute may vary, and while it may display differently (as part of a product's variations and not on its own page), it should benefit from existing inventory, pricing, etc. functions. In short, the need for sub-products is a display problem and not necessarily a data problem.

To keep things simple, my recommendation would be to add a parent_nid to the product table. Listings would display for _only_ products where parent_nid is null, and that page would display product variations using the main product as parent_nid.

The subproducts, displayed in either a dropdown or an unordered list, can adopt the same "add to cart" link and will require no further tampering with the checkout or delivery process.

For the present time, each sub-product can indicate its variance by title (e.g. "Red Shirt", "Blue Shirt", etc.). Going forward, additional development may lead to more mature product attributes, which will become applicable to both parent and sub-products.

> Not sure if you missed that, or if you are proposing something different.

Both, actually.

I was thrown off by the delimited string of termIDs and flat-out missed the parent_id bit. I guess what I'm saying is that attribute/term variations and sub-products are two different issues and I think they should be treated as such.

I believe that a sub-product can be introduced by simply adding the parent column and the whole term id bit can be deferred. By doing this, a sub-product becomes its own entity and can have any attributes it needs --either now or later. The only things that products and their sub-products share is their overall description and page they appear on, and every other attribute is independent.

Done and done, right? Am I wrong?

Following, I would like to see more mature attribute definitions so that you can search for products by color or size, use weight attributes for shipping calculations, etc. If terms and vocabularies only solve part of this problem I feel that rolling them into the sub-product issue will introduce confusion without addressing these issues properly.

What I'm saying is that sub-products and product variations are discrete issues. I would like to see product variations implemented holistically, but I don't see how adding tids is going to make enough of a difference in the short-term to warrant potentially having to back out when a more universal solution is worked out.

I am hoping that, as smart and rational people, we can reach a solution that works all-around. I would love to discuss further changes to attributes and variations, but I have a lot to do and believe that the most logical approach is to work these things in serial.

If you would like, perhaps we can work out a roadmap so that we can all be sure that most needs will be met going forward, things are addressed in rational order and nobody has to go around ignoring chunks of the data model because its not going to work for their needs.

I have a handful of ecommerce sites that I'm hoping to use drupal for, but the ecommerce module is a stretch for these. I would prefer to devote some time to making these changes over switching to another ecommerce package, but it only makes sense to work it this way if these discussions can be constructive.

I added some feedback to the proposal moshe and I put together, trying to think through the GUI aspect of subproduct creation.

I envision the vocabulary mapping feature to provide a couple of benefits: 1) it's a quick way to generate all the subproducts and 2) We can generate drop down fields of all the subproduct options on one page (the base product page). In otherwards you wouldn't have to view the Large, red, t-shirt subproduct just to add it to your cart. Lastly, the user only needs to be concerned with creating base products. However they can edit subproducts if need be.

vauxia, any other ideas how we could implement 1, 2, and 3 differently?

> trying to think through the GUI aspect of subproduct creation.

Good approach. Starting with common ground:

> 2) We can generate drop down fields of all the subproduct options on one page (the base product
> page). In otherwards you wouldn't have to view the Large, red, t-shirt subproduct just to add it to
> your cart.

I agree wholeheatedly here. I think this is what we're all talking about with subproducts/variations.

Now then, my concern is that your approach is doing too much thinking for the users while creating an infrastructure that may become way too complex very quickly.

Let's say I use your approach on a site that sells iPod's. Must I go to the vocabularies section in order to create a "Capacity" item for the 20GB/40GB models? How do I put the "U2 Special Edition" iPod into the vocabulary? Do I need to create an entirely separate vocabulary for the iPod Shuffle and iPod mini's because they have different capacities?

Problem #1: this vocabulary approach won't scale well if my store contains a variety items. Let's say I used to sell 10GB, 15GB and 30GB iPods too, and can't take these capacities out of the database because of legacy product info. Will every product using "iPod capacity" now contain 10,15,20,30,40GB capacities until I go back and delete the sub-items?

What if I also sell RAM ( capacity(4,8,16,32,64,128,256,512,1024,...) * format (EDO,SIMM,DIMM,SO-DIMM,PC2100,PC2700,PC3200...) * speed (60,100,133,266,333,400) * type (ECC,REGISTERED,...)). That's pushing 800 products, even though it is very unlikely I'll have 400mhz 8MB EDO SIMMS in stock. You can argue that this example would be less extreme if you broke it down by using a memory type as the main product, but you have to admit this gets messy fast.

Now, in addition to RAM and iPods, let's say I also sell hard drives (Capacity - again, cache, speed), Cables (length), video cards (a whole 'nother capacity), CRTs (size), Flatscreens (another kind of size) and well, the list goes on. With a store of any variety, your vocabulary:product ratio might approach 1:1, which makes for a sizeable array of checkboxes on the subproduct generator.

Problem #2: For the sake of this simplicity, let's limit things to the vanilla 20/40GB iPod. I have taken the time to create an "iPod Capacity" vocabulary, which contains each of those. Now I am back in "create product" territory, where I create the iPod 20GB product/description. I click on "this item has sub-products", and indicate my newly-created "iPod capacity" vocabulary as the variable factor. When I click on "save", my $300 iPod 20 is created, but so is a $300 iPod 40GB! That $300 iPod 40 is immediately ready for purchase, and if I don't catch it in time, I'm out $100/product.

This automatic -- and instantaneous -- product creation will have similar issues with stock availability, pricing and other attributes.

My next post will be more constructive...

So from a UI standpoint, this discussion is about how we go about sticking sub-products onto their parent node.

Basically, a sub-product is a completely distinct item with only a shared description (and therefore display page). Page 1 of node/add/product can have "this product has sub-products or variations" -- either in the form of a checkbox or a numeric dropdown to indicate the count of variations.

Currently, page 2 has more specifics for downloadable (filepath, filesize) or shippable (availiability, etc.) product info. Given that $n is the number of variations from page 1, my proposal is to present a) this page as-is where $n=0, or $n short-forms on this page. Each short-form displays everything but the description, path alias, product type, and other parent-only items.

Now, my initial proposal is to use "title" as the descriptive variation. Yes, I'm aware that this is naughty and unstructured. But I also believe that it is a way to give us a level of distinction without having a solution that only partially works, and without having to eat the whole attribute elephant. So while it is bad that you have to key in "Small Red Shirt" and "Large Blue Shirt", having these descriptions won't hurt us in the long run when we find a programmatic means of describing colors and sizes. In the short term it is quick and dirty and can clearly be expressed on invoices, etc. with no additional monkeying.

I agree 100% that there oughtta be some kind of metadata functionality - perhaps you'll convince me that vocabularies make the most sense, perhaps it is an attribute definition process. In either case, these metadata items can just start showing up in the sub-product short forms, which means that *not* using terms here gives us a cleaner migration path than using tid's.

I think this problem is a fundamental design limitation of Drupal. The problem being as I see it, a inability to associates nodes directly or even partially with node to term. I'm building a shopping cart and the client wants to sell (a) shippable products (b) take bookings for courses they run.

I took on (b) first in which I said "We'll just use events which we'll turn into products for the courses and have a 'page' to describe the course which never really changes". Easy. But then we have a Description flowing without any means to link to the events associated with it? What I ended up doing is having a 'Courses' vocab. with a term for each type of course then having the course and the events in the same term. I then had to hack the page module's 'view' hook to generate a list of events associated with the same term(s) as the page (which required 2 SQL statements, one being three table join). Now the 'page' node has code specific to the 'event' module in it (not to mention specific SQL to the event table). Ugly, but how else do you associate nodes together specifically?

Maybe there needs to be another core hook for rendering all nodes of a child term as: a table of links; a link to all sub-categories? I now have a product that has 30 variations in size and I want a dropdown box to select the size before they chose 'add to cart'? Your right in each variation on the product is its own node/entity. The sub-terms might work again, but here what they are really selecting is a different serial number for each of the 30 variations, each of which needs its own stock tracking. A new hook would have to be given the list of nodes it should be concerned with and allow control over what its output will be while at the same time not caring what type its sub nodes are (polymorphism).

The other half of the problem is admin UI. My client, as usual, is as computer literate as G.Bush is subtle, so the process of creating something AND THEN adding product information was challenging enough. One can't expect them to grasp the vocabulary/term idea let alone hierarchies and associating the right sub-products with the right sub-term. If sub categories are to be used then it has to be automated. Perhaps a vocabulary of node IDs in a hierarchy that is automatically generated? A unified interface is needed for the poor simple merchant.

Perhaps a new module type would work that merely 'collects' its children (who might be products) together into a unified interface for the user and the admin? Its basically a one-to-many relationship were dealing with here.

Looking at the ec_product table, from a data point of view if the table were given its own primary key (i.e. and 'nid' was not, bad schema design. Tables should always have their own unique primary key to avoid problems of this nature) then we could have entires with the same 'nid' in it (i.e. change the node-to-product relationship from 1-to-1 to 1-to-many).

This would allow each product variant to have its own price/stock tracking/etc... This only leaved the interface problem...

Sorry, I’ve never used a forum that could change the topic with each post.

Anyway, I've been bashing away at it for days now and it seem I've opened a can of worms by introducing a unique primary key into the ‘ec_products’ table as well as a description field to display in the dropdown. I thought that I would just have to change the product module and the rest wouldn't need to know the difference. But there is no encapsulation so I have had to change the 'cart', 'store', 'payment' and 'tangible' (the only one I'm interested in for the current job) modules so far. Also had to introduce columns in 'ec_cart' and 'ec_product_tangible' plus add a new record in 'sequences' table for tracking the new primary keys.

I still haven't managed to work though it. I'm thinking that this is too much of a fundament change to the nature of the cart. The taxonomy hack is starting to look good about now. I’ve noticed fragments of code left over form when it was working. I only partly understand the strategy.

For god sake, putting a parent_id column in the ec_products table is taking an existing mistake and making it worse. Since the ‘product’ is an ‘epiphyte’ module the relationship we want is a one to many with the node that has the description, NOT with itself. A move like this would only limit the scope for growth in the long run.

The underlying system should allow for maximum flexibility while the interface(s) should narrow this for ease of use. I need a solution to this before the weekend. I’ll post whatever I come up with.

I don't see the unique nid in the ed_products table as a design limitation since I think each subproduct should also be a node. For example, you may want a different title or body text/image for each subproduct.

The real problem is how are these subproducts are created/maintained? I still think the answers lies somewhere in vocabularies.

It also may be a good idea to incorporate the node relativity module into presenting the relationships between subproducts and their parents.

But if you have a different title or body text/image for each sub-product then you have a different product and you might as well just make them separate products. What would be the point of sub-producting them then? I thought the whole idea here was same title/description/picture but variation on one or more properties (no? yes?).

Given that there is some common attribute you want to share across them all, if you create, say 30 (just like I need to), variations, if you create 30 new nodes and then decide to change this shared piece of information you have to go though and change 30 nodes.

The whole idea is that you have one point to change the info which makes it easy to maintain. I think that there may be some confusion in what is actually desired here, i think that there are two cases here:
(a) to have a shared product properties (i.e. same 'price', and that’s about all) with possibly different descriptive info (title, description, image).
(b) Shared descriptive info and different product properties.

I'm in boat (b) here, I think the system caters for (a) already, you just have to make a new product for each because that’s essentially what you have.

What ever the case they will all want individual stock tracking so you'll need individual records in the products table, but not necessarily different nodes for each. As I've said this means a 1-to-n relationship between nodes and ec_product tables.

Look at it this way, if you do get this 1-to-many relationship happening you can do (a) and (b) without it you can only do (a). I guess you could get (b) with a recursive relationship (i.e. parent_id). The children could ether share the parents values for price and what-not and if the parents value was null this could indicate to individual values for each. You wouldn't need separate nodes for each (or you could optionally could).

Something just doesn't feel kosher about it. You still have the same complexity of a 1-to-many with the 'node' table, and even more complexity with the hierarchy structure to maintain.

Ether way I think sub-products should share the node.

Anyway, I’m now looking for a dirty hack. What was the last version of this module to have the taxonomy solution in it?

The relativity module rocks! This overcomes what I thought was the main limitation of Drupal. It should be incorporated into the core Drupal code and allow for more flexibility. Its interface is a bit rough and ready, but hot dam: it works!

The only thing is it doesn't work with products because products are not nodes in themselves so the hook is never called. I guess you'd have to associate whatever your attaching a product to with itself in order to get this recursive parent-product thing happening.

Also need to hack the relativity module a bit to get it to make a dropdown for the sub-products. If this were core functionality you could just put a hook in the child module and it would know how to display itself as a child. I think that’s what I'll do...

p.s. Still need to make an automated interface to generating many variations but not for this job...

I think your reasoning for why subproducts are needed and the workflow to create 'em make sense. I don't think you'll find much argument there ;-)

The Drupal way to implement this is by using vocabularies. I stand by that, since vocabularies are be definition content/node/product attributes. However there are two problems with this approach.

1) Product type attributes (i.e., the download url for file downloads, inventory tracking for shippable items) should be tied to subproducts. Price adjustments, new sku numbers and such are not a problem since they are the things that make up any product.

A potential solution to 1) is to introduce a primary key for products which would allow one node to be tied to multiple products. We'd also add a comma delimited tids field for the vocab mapping. A tid of 0 would then be the base product.

2) Tying multiple vocabularies to a base product may result in the creation of subproducts that don't really exist. For example say I have color and size vocabularies. I have red / small shirts but not red / large.

The easiest way to solve 2) is by deleting the non-applicable subproducts after they are automatically generated. Perhaps a checkbox of all subproducts so you can easily click of the non-applicable ones.

I'm still at odds with the vocabularies-as-differentiators approach. What I'm get at is that these differentiating attributes are name=value pairs and I feel that it is unscalable to try and create lots and lots of names (terms) to express this. I can see how this would work, but I can also see how it would get hairy.

In my HDD example, you'd have to keep creating terms for every possible size, and you'd have to keep terms hanging around for 540MB drives even up to the time you're selling 540TB drives. Now, how do I do a search for all drives larger than 20GB and smaller than 80GB? With terms, I can't do it cleanly.

So product attributes need to be represented as name=value data. If *only* there was some way of attaching user-defined types and extended attributes to nodes...

I have no need for this function anymore because I finally decided to buy a real E-com engine who do the job I need, but I think this might be a solution :

http://drupaldocs.org/api/head/file/contributions/docs/developer/example...

and quite ironically, i found it in the drupal handbook :)

I wanted to thow in my 2 cents.
After having spent some time with the Survey module and how it uses the the FORMs module I thought this would apply to the area of attributes or product variations. From a user perspective we create a survey as a regular node. Then can add form elements to it like drop downs and radio buttons by using the Forms tab. I also noticed that the products tab is showing up on this survey. (And why not it is a node!).

So this led me to the thought that you can have products with attributes right now! Here is a screen shot of a survey node adding form elements and attaching via the product module. The smart ones may have already noticed a problem with my thinking. A survey gets submitted via the submit button but a product gets added via the "add to cart" link thus sending the data off in two different directions.

Anyway, I thought this might spark further conversation. What are the posibilities of hooking a product into the form api and linking the results of the form to a product purchase? Just like the survey module does?

....
Jim

Has the product variations for e-comm died?

It may be dead, but I would like to offer a small donation of $25 to the developer that works to implement basic product variation functionality in the commerce module. I realize this won't be enough on it's own but perhaps others will offer to pitch in. Just drop me a message or email.

I am also in search a bounty site or somthing where I can collect other users who would be interested in pooling our resource to offer more case for this project.

Jim

Update:

I have spoken to Matt, and we discussed how we are going to implement this into the current E-Commerce.

I am currently in the process of developing a spec/outline of what is required to be done to implement this. I am hoping to have this complete by the end of the weekend.

I do have basic functionality for this. Based on this conversation, the requirements were inclusive of the need to have:

a) products varied by taxonomy
b) products varied by attributes
c) products varied by quantity (bundles or volumetric pricing, e.g. popcorn, with inventory tracking)

There's substantial progress on this, but I didn't have the incentive to button it up. If there's still interest, I can work with gordon and/or post a reverse bounty.

I might have jumped the gun a little bit but...

I have created a bounty on the Donorge.org website.
http://donorge.org/d_items/view/324

I have also posted an announcement encourage donations to help with this patch.
http://drupal.org/node/33075

I am glad to forward any donations on to the end developer who accomplishes this task and still stand behind my intial commitment.
Also, if a develop takes up the task, i can transfer the created donorge bounty to that person if they prefer.

Jim

For whatever it's worth, I've banged together a solution that supports arbitrary product variations for the Drupal 4.6 e-commerce suite. I threw it together in a few hours in response to a request from a client, and so far it seems to be holding up pretty well.

Essentially, the hack involves creating a new "variation" node type that has little more than a title and a reference to a "parent product" node ID. You can then specify variation-specific SKUs, inventory, and other stuff as usual. I then modified product.module so that if a product has variation nodes, it generates "Buy me!" links for each variation node -- when the user clicks on a link, the variation node is added to the cart. The only bugbear is the editing/maintaining the variations requires a roundabout trip through the administrator's content menus, because all calls to hook_view() simply redirect users to the "parent" node instead.

As I said, I tossed it together in a few hours, so it isn't optimized and doesn't comply with Drupal coding standards, but I'm willing to share it with whoever is interested. My only problem is that I don't have a Drupal developer account (and I'm too lazy to get one ;-), so I might just upload the solution as a ZIP to this thread.

Anyone interested?

--R.J.
http://www.electric-escape.net/

i'm not against having a look at a working implementation of product variations, even if it's not fully using drupal standards :-)

is there any news on this ? specs ? updated bounties ?

I am just putting the final touchs on my implementation of sub products, for a civicspace project that I am working ok.

Once I have uploaded it there I will put up the patch with an explaination of my madness.

This will be a first release, and I am sure things will change.

Okay, for whoever cares, here's my implementation of product variations. Again, apologies for not doing this the right-n-proper Drupal way, but I'm just a code geek who wants to share the fun.

The .zip file contains my variation.module, a MySQL database definition, a text file indicating what changes need to be made to product.module, and instructions on how to use everything. It should be self-explainatory, but I haven't tested the installation on a virgin Drupal/ecommerce setting, so (a) use at your own risk, and (b) corrections/feedback are welcome.

(Note that this version is slightly different from the one I sent out to the folks who e-mailed me for a copy earlier this week. I'd recommend using this version instead.)

Anyway, here it is, feel free to play with it, and let me know what you think...

(No response... is no one interested?)

Fixed an access privileges bug in the module that prevented non-administrators (user/1) from creating variations. Embarassingly bad...

--R.J.
http://www.electric-escape.net/

see http://drupal.org/node/35071 for the functionality that will be commited to live.