How to handle bras

No, this isn't spam despite the title! :o)

Last year I started building a commerce site for lingerie but for various reasons, this got put on hold but is hopefully coming back to life shortly. However, I did get a reasonable distance but I was finding the data load rather taxing. Bras are very similar to T-shirts (honest!). They have sizes and colours but the combinations are enormous. They come in back sizes and cup sizes and different colours so, for example, you get back sizes 28, 30, 32, 34, all the way up to 48, and for each of these you get A, AA, B, BB, C all the way up to J. And every bra comes in, say, black, white and nude. I loaded up some sample data where I had a product for each unique combination: 28A black, 28A white, 28A nude, 28B black etc and each had its image. And remember you get this for each manufacturer and range.

So you can imagine how many different products I had. I tied all of the products in each manufacturer/range to a single product display and it worked well (the add to cart functioned beautifully when, say, a user selected a black bra, the image changed to the black bra). However, this seems overly complex. Despite all the combinations, there are in fact in the example above only three images, selected only by colour.

I recently started looking at OpenCart after a suggestion by a friend and it certainly has a slightly simpler mechanism, allowing images to be associated with options like colour. But again I'd have to have a different set of colour options for each manufacturer/range.

So my question is, is there a relatively easy way to handle this complexity?

Thanks in advance.

Posted: Jun 4, 2013


joshmiller Josh Miller on June 7, 2013

I admit I clicked on this because it looked spammy. :) So cheers for that.

This is a very common request. What you are looking for is something along the lines of "inheritance" or perhaps "Single attribution dependent fields." Unfortunately, this does not exist in any real tangible way in Drupal Commerce. Probably the closest thing that would get you there is to build a preprocess function for your product's image field that understands your particular defaults (first color option that matches this product's color and is attached to this product display would always have an image that you would want to display, return the value of that product's image field).

This might be helpful to you:

function templatename_preprocess_field(&$variables) {
$variables['element']['#field_name'] == 'the_field_name') {
$variables['items']['0']['#markup'] == 'thedefaultvalue') {
$variables['items']['0']['#markup'] = '';

Shamelessly pulled from a comment here: https://api.drupal.org/template_preprocess_field

PedroKTFC on June 18, 2013

Thanks for the suggestion. However, I'm having a look at Magento as an alternative approach. It seems to have more out of the box as standard. But I'll be back to Drupal eventually!

yerbamate on June 19, 2013

This is the single number one reason that as much as I love the flexibility of Drupal Commerce, I can't stand actually using it.

I sell a specialized jewelry product sold by the millimeter and there are as many as 50-70 sizes for each product. In my old system I simply had one product with 70 sizes. Now I have 70 products for each "product" I want to show the customer. We went from having ~300 products using osCommerce to nearly 20,000 "products" using DC and the store is an absolute nightmare to administrate. We offer some items in multiple materials and we ended up having to split those up into separate products altogether because it would have been over 200 "products" per display.

If I had not already been ripped off by a developer who charged me tens of thousands of dollars and left me with a half usable Drupal Commerce store, I would not be using this system simply due to the above attribute/product reason. My staff wastes a huge amount of time dealing with product creation and editing. If I was selling a different kind of product, it would be a great system.

iqxmk on July 3, 2013

Hi there,

a way to handle this complexity could be using external Excel / CSV files to edit products and then import them into drupal commerce with commerce feeds. I usually create separate CSV files for the product display nodes and the products itself. Importing works very smooth and reliable. Also the product reference fields in display nodes, product pictures and so own can be easily managed this way.

To get a smaller number of product variations you could also work with drupal customizable products module here, although this would bypass the way it's meant to work with product variations. To do this, you could attach some additional fields (e.g. list fields for colors) to a custom line item type assigned to the product variation type you're using.