Need to create options/attributes without needing new SKU for each combination

The idea behind Drupal Commerce is that you should not be able to do what you're requesting. Each of those different variations of the same product are in fact different products. When it came time to order more shirts, you wouldn't say "Just give me more shirts." You'd say "I need 5 small, 3 medium, 7 large, and no XL." This is why Commerce forces you to define each of these uniquely with a separate SKU.

Instead of trying to undo the data model, what you have instead are valid UI concerns. How can I create and manage many of these at once. The first issue, creating them in bulk, is being addressed by http://drupal.org/project/commerce_bpc. Questions about managing them need to be more thoroughly explored in core for 2.x and in contrib until then, either through product groups (think a product with a product reference field) or modules like my Inline Product Form module in development (http://drupal.org/node/1181862).

Another thing; when you define products this way, the Add to Cart form will always only show valid color / size combinations. That's in fact one of the very good reasons for defining individual product variations as separate products.

For more information on our product data model and why it's important, check out my discussion with Jeff on the Lullabot podcast: http://www.lullabot.com/podcasts/podcast-96-ryan-szrama-on-drupal-commer...

Ahh, ok. In that case, you might be interested to know that you can attach fields to your product line item types and expose them to the Add to Cart form. This is the way to have customizable products in Commerce (working similar to Ubercart style attributes that don't adjust SKUs). The only hitch is that if you don't need the same fields exposed to the form for all your product types, you'd need to define additional product line item types in code until I can get a contrib up to do that via the UI.

Creating the custom product line item type? You just need to implement hook_commerce_line_item_type_info(), define your line item type, and set its 'base' => 'commerce_product_line_item'.

GiorgosK! Thank you very much!

Your code helped me. I added size property for product.

1. Create a taxonomy vocabulary with sizes (available sizes)
2. Add a field named field_size to product (/admin/commerce/products/types/product/fields) - unlimited values
3. Add a field named field_size1 to product-line (/admin/commerce/config/line-items/product/fields) - 1 item value
4. Add a code to module or template.php file:
   

   <?php
   function [THEME_OR_MODULE_NAME]_form_alter(&$form, &$form_state, $form_id) {
       if (strstr($form_id, 'commerce_cart_add_to_cart_form') && isset($form_state['default_product'])) {
           product_available_attributes_in_add_to_cart($form, "field_size1", $form_state['default_product']->field_size);
       }
   }
   
   function product_available_attributes_in_add_to_cart(&$form, $attributes, $available_attributes) {
       $lang = $form["line_item_fields"][$attributes]["#language"];
       if (isset($available_attributes[$lang])) {        
           $ava_options = $form["line_item_fields"][$attributes][$lang]["#options"];        
           $new_options = array();
           foreach ($available_attributes[$lang] as $option) {         
               $new_options[$option['tid']] = $ava_options[$option['tid']];
           }
           $form["line_item_fields"][$attributes][$lang]["#options"] = $new_options;
       } else {
           unset($form["line_item_fields"][$attributes]);
       }
   }
   
   ?>
   

Now I can select several sizes during editing the product and shop's customer see only selected sizes, not all from taxonomy vocabulary.

I know this is an old thread, but having wrestled with Commerce for some time, there appears appears to be two schools of thought on how variations in specific products should be handled. The first, as seen in Ubercart, is to add attributes to the specific product (SKU). This is simple enough if you have relative simple, non priced attributes. The second is the approach taken by Commerce - simply create a new entity for each possible combination. This has the advantage of relatively straightforward inventory management and pricing. Here’s where it turns South.

Neither of these models address the issue of complex products - especially customizable products, but this problem is not limited to that. Here’s a simple example and the Ubercart vs. Commerce model of doing things. For this example I am going to be creating a customizable dress shirt shop. Fancy, fancy.

Okay, let’s start with the variables:

Smokin’ Suzy White.

Shirt type is determine by the fabric used in the main body, white in this case.

• Shirt Size (XXS, XS, S, M, L, XL, XLL, 1X, 2X, 3X, 4X, 5X) (12)
  • Ubercart - Create 1 node, 12 size attributes.
  • Commerce - Create 1 Display, 12 Entities.
  • So far, so good.
• Button Type (Gold, Silver, Bronze, Abalone, Pearl, Glass) (6)
  • Ubercart - Create 6 attributes.
  • Commerce - Create 66 additional entities.
  • Okay, Commerce, woa there.
• Collar Fabric (Red Rose, Blue Bagonia, Purple Petunia) (3)
  • Ubercart - Create 3 new attributes
  • Commerce, now we’re going to need 288 entities total.

And so forth.

Ubercart might look like the winner, but that’s only if:

• We’re allowing all attribute combinations on the product.
  • What happens if we want to limit combinations? Ubercart has a module to allow that, but we’re still looking at checking/unchecking combos.
  • What if we want to change the pricing, for example add $2 for gold buttons, $1.50 for Silver, and so forth?
  • Let’s just imagine we can also select cuff design and collar shape.

In both cases the truly customizable products become ridiculously unmanageable - so both fail at truly meeting the needs of more complex or custom products. Neither is the “better” option.

Modules like commerce_option and commerce_pricing_attributes have attempted to meet the needs of more complex stores, but with long queues of unanswered issues, broken features with no commits in over 2 years.

I’ve installed and used both Ubercart and Commerce for various customers. Both have their pros and cons. Ubercart is great if you know very little about Drupal, and don’t want to learn Rules. Rules makes Commerce very powerful, but, and this is a big but, the end user - the shop owner - will generally not be interested in performing programming style changes to their store. The UI for Commerce falls significantly short in this area - managing shipping, discounts and other pricing automation requires accessing rules style UI - a very unfriendly environment for a small shop selling canvasses.

But really, by far the biggest problem in both is the handling of complex products and pricing without the sacrifice of UI - both in the back end and customer facing environments.

It leaves me at a cross roads… where to from here?

Markdown support in the comment section would be nice...