Product SKU's/Variations/Sub-Products.

Thanks for digging into this!

I'm also working this week on completing the subproducts integration into 4.7/HEAD. Let's coordinate so we can take on distinct parts. There are a few changes we need to make to Gordon's patch (rename parent field to pparent to avoid conflict with book module, drop children field and instead dynamically load the ->children array, etc.)

Maybe I should take on Gordon's patch from where you've taken it, and you could focus on an upgrade to subproducts.module. Does that make sense?

Thanks recidive. I've moved the (not yet finalized, but getting there) subproducts module to the main ecommerce directory. I'll test and report back on this latest patch.

One question is, should we be moving everything we can to subproducts.module? I.e., should we be limiting the changes to product.module to the absolute minimum, and do everything else in subproducts.module?

I'm working on stripping down this patch to the absolute minimum and doing everything else in subproducts.module. Recidive and I have been updating subproducts.module to 4.7 (it was initially written for 4.6, sponsored by GoodStorm). It's not done yet, but can be used for basic testing. We've also added HEAD/4.7 versions of two GoodStorm-sponsored modules to the /contrib directory that use subproducts: apparel.module and custom.module.

Attached is an interim version of the enabling patch. It's not ready to apply yet as we need to do more testing.

Note re changes from the previous patch draft:

I've removed the proposed subproduct-specific cart call, and instead changed cart_get_items() to use $node->nid rather than $nid. The idea is that, when needed, subproducts.module can reset the object reference from the parent to the child product.

I've drafted a documentation page on subproducts, http://drupal.org/node/52743, and will add a developer version as soon as I get a chance.

Is this the full patch, It doesn't look like much. If it is please commit it.

I want to have a fully tested and working version of subproducts module before applying this patch, as likely completing the subproducts module updates will require more adjustments to the patch.

The update function should go in product module rather than store. Probably we should we remove the pparent field from the CREATE TABLE call in product.install and instead put the _update function.

The update function should go in product module rather than store. Probably we should we remove the pparent field from the CREATE TABLE call in product.install and instead put the _update function.

This should be there for new installations, but there also needs to be a product_update_{n}() which includes the creation of the pparent field for existing ecommerce installations.

Are there plans to add subproduct functionality to other product types as well? I'm setting up a site that sells retreats and has different accommodation options (ie a non-shippable product) -- it would be great to be able to be able to set this up within the e-commerce framework, and it's hard to shoe-horn it in currently.

If I can help with the coding, I'd be happy to -- I'm not that familiar with the Drupal codebase yet, but I'm a fairly decent PHP programmer.

I was just about to commit this patch, and I found that the call to the product_invoke_productapi() in the cart_add_item() is actually returning an array of falses, because product_invoke_productapi() calls all hook_productapi() and merges all the results togethers.

What is meant to happen is that the invoke should just return 1 value which is false to stop the addition to the cart or anything else which is treated as true, and it can be added to the cart.

Is there a reason for the change, or can I just turn this back to the original module_invoke().

Once I have this sorted I will be commiting this.

forgot to change the status's

I do not like this idea, Lets change the cart_add_item() so that it calls the productapi direct without using the module_invoke(), this will be a lot cleaner and be easier to maintain.

Thanks for this I have commited it to cvs.

Thanks for the good work!

This handbook page may need to be updated now:
http://drupal.org/node/52743

I've been testing the new changes. It seems to work well until I try to edit a product that has variations. When I edit the item and click submit, I get the following errors:

Warning: Duplicate entry '386' for key 2 query: INSERT INTO ec_product (nid, vid, pparent, sku, price, is_recurring, price_interval, price_unit, price_cycle, auto_charge, ptype, hide_cart_link) VALUES('386', '573', '0', '6', '15.00', '0', '0', '', '0', '0', 'apparel', '0') in /httpdocs/includes/database.mysql.inc on line 120

Warning: Cannot modify header information - headers already sent by (output started at /httpdocs/includes/database.mysql.inc:120) in /httpdocs/includes/common.inc on line 233

Once this happens, the page gets "lost" and is dramatically changed. The only way I can get it back is to recreate the node from scratch.

After some more testing, this only happens when "Create New Revision" is selected. As long as you're not making a new revision, it seems to work fine to edit product nodes.

I'm using 4.7 rc2 and cvs (current as of today) ecommerce.module.

You most likely had a problem with the upgrade and the index on nid has not been removed. This has nothing to do with the subproducts.

this is fixed again.