Discussions

Understanding product attributes and options

First off, I'm a Ubercart user. My hats off to the developers and community for a great product. I know the developers have their reasons for reconfiguring elements the way they did.

However, I was playing with Drupal Commerce and was reading that for each attribute a product has, I will need to create a new product. This seems very counter-productive.

Let's say my client owns a pizza parlor and they want the user to be able to build their own pie. Just look at one aspect of that pizza builder: meat toppings. Toppings can either be on the left, whole or right side of the pie.

So now I have to create three products for one meat topping??? You're kidding...Then there are the cheese and vegetable toppings. It' going to take forever to build this one product...in UC, setting that up was a breeze.

I was doing the research and it seems like the above is the only way...tell me there's going to be a better implementation.

I looked at the bulk product module and installed but not still not sure how to add attributes.

nexus
Posted: Jan 11, 2011

Comments

Ryan Ryan Szrama on January 11, 2011

Well, the problem is you don't really want an attribute... you're looking for a configurable product. You'd sell the pizza as "Large pizza, 3 toppings" or "Medium pizza, All meat". You don't really track every possible combination of toppings as a unique product on the menu or register. Of course, at the time of purchase you would specify which toppings should be on the pizza if it was an "# toppings" type order.

The way this ought to work is through some sort of configurable product system. My hunch is this data should be associated with the line item. I don't know exactly what that would look like, but extra fields can be added onto the product line item type for example, and these fields could be populated with data as part of the Add to Cart or Checkout process.

What Ubercart did is allowed for either configurable products or product variation selection (i.e. a size of a shirt) through one system, but the confusion that created at the database / API level was counterproductive even if the UI was easier to grok.

nexus on January 17, 2011

Ryan, thank you for your response

yes, groking the product and it's attributes will have to be rethought on my end as products are no longer nodes...

In UC, you could use services module to list a node and it's attribute/options aid and oid, not sure how I would go about that in DC...

willem on January 20, 2011

G'day Ryan,

I have been reading on the Drupal website and this website about the development you guys have been doing with the Commerce module and I'm impressed and looking forward to using it.

Before I begin, I am a web designer, not a developer. I build Drupal websites mainly for my own use, though I will be doing a few others.

Currently I have Drupal 7 set up on my computer using Xampp as a server. I have the current 7.x-1.x-dev (19 Jan 2011) version of Commerce running.

Perhaps if I describe what I need it may be useful to you in developing DC.

I market an extensive range of self adhesive labels. There are about 200 die cut shapes and sizes of labels with a variety of label materials and colours, broken up in to 9 categories. Within those categories each of the label shapes/ sizes is repeated, with label material and size info, and a number of choices of label materials and pack sizes, with different prices. You can check it out at EveryLabel.com.au. (This is a Zen Cart site). My customers have told me that the website is intuitive and easy to navigate so the basic navigation system should remain the same.

As you can see, with 200 shapes and sizes and 9 categories, that is about 1800 products, with many variations. To make up individual products with individual SKUs for each of those variations is a daunting thought ...

What I want on each product is some basic info about each label material and printer suitability. This info remains constant for each category. I thought perhaps this would fit well into a panel on the left of the page.

On the right of the page I would like to see a medium size pic (say 250px x 400px)of the label shape. This would change with every product. Using Lightbox to show a larger version.

There would need to be a title at the top - perhaps in two parts. One to describe the category - say 'White Paper Labels', which would remain constant for that category, and one which showed the size and shape, which would change with each product.

Then there is the key part - listing each product variation and its price, and an 'Add to cart' button with a quantities box. Perhaps this list could be fitted between the the description and the pic.

On the Zen cart website this was achieved using 'Attributes'. I notice that Ubercart also uses attributes (I have a couple of Drupal 6 websites using Ubercart), but Commerce uses fields to achieve similar ends. I don't understand how, yet.

I would then also have a link to a table of size info, like you can see on the current website. This can be a simple text link at the bottom of the page.

It would be good if this could all be one one screen, without the customer having to scroll.

Updating things like prices and other info needs to be able to be done by category. I really do not want to have to update 1800 products plus multiple variations one at a time!

I hope this info is useful to you in the design of the Commerce module. I am looking forward to developing the store. I am building the other parts of the website at present, but I would like to get started on the store.

Which raises the question ... when will DC be released? (I know, I know ... when it is ready! But could you be a bit more specific ... at least give us an idea when you will get to beta?)

Thanks

Willem

drupal_kid on January 25, 2011

One of the many challenges a developer (or development teams) face is 'how to make things flexible' because there are so many ways of 'selling' with so many different products / categories / services out there.

With that in mind, maybe a 'fast build / add' extra product fields - sitting as a part of the products table is something to consider. I'm thinking of things like price1, price2, price3, price4, account_id (if linking back to an accounts package), available_from date/time, available_until date/time... the list goes on.

Once the fields are in place, Views can be created to pull all of this together.

One thing is to get the data in there (into the system that is), another thing is to be able to view it and interact with it - that's where the Theme comes in. A fair bit of what you're outlining above are related to look and feel of the data from the database.

The Theme would also be able to interact with some business logic - for example, are the customer entitled to discounts, are there quantity breaks in place for this customer / product and other special cases.

Of course, having a successful ecommerce website where you receive a dozen or more orders pr day is what you're after (I would think).

So, in addition to the web site itself, a very important question is - how do you import your order(s) back into your POS system (RetailManager, MYOB Premier, Attache or any of the other ones out there).

In essence what I see is a frame-work for 70% of stores and the remaining 30% is the hard yakka....

To use an analogy; If you're building a highway between two major cities, you'd make it in a straight line (as far as possible). Once you know the straight line - then, and only then, should you (imho) consider scenic detours and tourist trips. In other words, let's get the framework in place and then add the extensions - not the other way around...

Regards,
Knut

Matt (not verified) on March 16, 2011

I have to disagree about the 70%/30% divide... I've built about 15 stores on top of UC so far, and every single one of them has used attributes and options. The markets they sell in runs the gamut from food, to dog toys, art, fly fishing equipment, and clothing. The current setup of Commerce is pretty much unusable for most of them, unfortunately. I have one site running on UC that has a total of 300 possible variants for one product, and there's just no way I can ask my client to manage those by hand when they've been using the "old" way that was so much easier.

There really, really, really needs to be a "core" way of dealing with bulk product creation based on attribute "rules", or I'm afraid that Commerce is going to have a difficult time delivering for a ton of retail sites that have products that require user choices, and the resulting "variants" associated with those choices.

I'm also concerned about what's going to happen to the UI for product management when you end up with 300 variants created based on one product. Previously all of that was hidden inside of the main product, but now the product list will include a line item for each possible variant, which on one site I manage could end up being thousands and thousands of individual variants that are really only based around a product catalog of 100 items with associated options.

-Matt

timodwhit on November 9, 2011

I am a total noob and I'm looking for a configurable product!

Here is my scenario: I am working for popcorn store and they have three different size tins 1, 2 Gal and 3.5 Gallon Tins. The 2 and 3.5 can be filled with up to three flavors (7 flavors exist).

My ideal option would be to have the customer able to use check boxes next to images to select the flavors to fill the tin but I need there to be a limit of only three flavors. (This would make sure there are no repeats).

Is there a way to do this?

Also, if there is, is there a way to then generate the price dynamically? Certain fillings change the price of the tins.

willem on February 15, 2011

I have come a long way in learning about D7 and Commerce in the last few weeks. I think I know how I would like things to look, and I am making these as suggestions that may be useful.

At present, if I understand it correctly, every variation of a product must have its own SKU. The effect of this is that every variation of a product becomes a product. For me, with about 15000 + product variations, that's a problem, especially when it comes to updating prices time!

Is it possible to have a standard set of variations - say variation 1, 2, 3, ..., each with its own SKU, which could be arranged in Views, and attached to any product (Which would have its own SKU)? Then that single set of variations could be used over and over for all the products they are relevant to.

For instance, we market about 200 different shapes and sizes of labels, all of which are cut into standard A4 sheets. The cost for any given label material remains the same regardless of the label shape cut into it. But within any one shape there are variations, such as pack size. In one of our categories, there are 8 variations. If I have to make up individual products for each of those variations, that makes 1600 products. And we have 10 categories!

But if we could make up the 8 variations into a view and reuse that 200 times, I would only have to make up 200 products. Still a daunting task, given there are 10 categories, but manageable.

But best of all, when the time comes to update prices I would only have to update the eight variations once and every product would be automatically updated.

Perhaps what I have suggested is already possible. I know I can make up the list of 8 variations by making 8 products with unique SKUs and arranging them with views. I know I can insert that list into a display using Panels. And I can put the correct label size in the display using a Title field. But when the customer hits the 'Buy' button, will the correct product be displayed on the order? As I understand it it will show just the generic variation, and not give info on the labels size.

I am appreciating all the work that has gone into this project and I hope my comments/ questions are of use.

Thanks

Willem

willem on February 21, 2011

I was reading in the documentation on how to display products, and have pasted the relevant section below. This suggested method works, but only if all the related products have the same price. What if you want to sell t-shirts singly, but also in packs of three? You don't want to have set up a separate display just for the three. You want that as an option on the same page.

Looking at the demo site it only offers variations of the product at the same price, so it is of no help.

Am I missing something obvious, or is this an actual limitation?

Thanks

Willem

* * * *
Second we should now add a content node to display a product. Navigate to the Add content page for the content type that you created for your products (Content > Add content > Create [Your Content Type], or http://example.com/node/add/[YourContentType]). Here you should associate one or more products via the "Product Reference" field. You need to reference all the various sizes and colours of this product, so that all options can be displayed by this one node.
* * * *

Ryan Ryan Szrama on February 22, 2011

Thanks for all the thought you've put into examining the current system, Willem. Regarding your first inquiry here, you'd basically have to use an additional attribute field governing the bundled product... i.e. add a "Bundle" field with options "Buy 1" or "Buy 3". Then it would show up on the Add to Cart form alongside the other attributes. I'm not sure how else you could elegantly handle this... you could alter the quantity widget to support values of 1 or 3 and use a product pricing rule to discount line items w/ 3 or more... but you'd still have people able to alter the quantity on the cart form.

I'll have to give your other feedback more consideration. We definitely need a solution for managing large catalogs of SKUs. Perhaps there is something to look for using a different sort of admin View with a group by approach. I do want to have support for bulk product creation / update based on SKU patterns and such, it's just something that needs to mature on top of the base system. http://drupal.org/project/commerce_bpc from last year's Google Summer of Code was a start, but it hasn't been kept up to date w/ Commerce itself.

willem on February 24, 2011

G'day Ryan,

Thanks for your response. I appreciate it.

I am not sure what you mean by 'bundled product'. I can't find a 'Bundle' field. and in any case I want to sell different packs of labels - a 'Box' of 100 sheets, and a 'HandiPak' of 20 sheets. So I am not selling 20 sheets, I am selling 1 HandiPak of 20 sheets.

Right now the problem I am facing is how to list products in views. Views seems to list just about every form of content except products. I'd like to list products in Views filtered by their SKU, but I cannot work out how to do it.

Any help greatly appreciated.

Thanks

Willem

Ryan Ryan Szrama on February 25, 2011

Ahh, sorry, I didn't mean to find a field called "Bundle" or something, just a custom integer field that you label as "Bundle" or "Package count" or whatever. You can give it whatever options you want and then add it to your product type so you can list different products as different counts. Of course, each count then has to have a unique SKU, and the quantity would be how many of the bundle you want to buy.

As for listing products, you either need to create the View on the Commerce Product table or on a Node View add a relationship to the referenced product through your product reference field. Then you can add the SKU from the referenced product to the View.

emosbaugh on February 27, 2011

I too am having problems understanding how I can use commerce as a solution for my store. I've been playing around with it and cannot seem to figure out how to achieve a solution for the scenario below.

I am setting up a skateboard shop. For instance, I have boards as well as a grip tape "attribute." I would like grip tape to be an optional attribute that can be added and would have a price associated. There may be multiple grip tapes, i.e. standard, premium, etc... Also, a user may choose to have the store apply the grip tape for an additional charge via a check box.

The way I see it grip tape is technically a separate product which would not alter the SKU of the board. I'm not sure what the application of grip tape is.

see:
http://shop.ccs.com/product/model:160377/sku:65-02898/girl-carroll-scram...

Is this configuration possible with commerce?

Thank you,
Ethan

willem on March 20, 2011

 

Perhaps it would be useful to separate the price field from the SKU. Have a generic price field - say 'White paper labels - box' into which any price can be entered. 

Then allow any number of products to be built, each with it's own SKU, which can include the field 'White paper labels - box' as it's price field. Also allow that product to attach more than one of these price fields. 

The advantage of doing it this way is that when the time comes to update prices you only have to update the original 'White paper labels - box'  field and each instance of that field will automatically be updated, regardless of the SKU it is attached to. 

This allows both multiple variations of a product and the easy updating of prices.

Willem

bryan (not verified) on April 21, 2011

This proposal may be a bit naive since I'm not a developer, but it seems to me that this problem could be solved by creating a new field display widget for product attributes (or whatever you want to call them). The only real difference between this and the existing product display widget would be that this one would add it's properties (i.e.- price, description, etc.) to the base product when selected. It should also allow for multiple selections. This would at least be a starting point to fix the 'pizza topping' problem without having to create a unique product for every possible product variation.

wjaspers on May 6, 2011

Are you suggesting the "attributes" be a part of the product itself (and you can reference as many "attribute" product types), or the Node which handles displaying the product (how do you filter out incompatibilities)?

The one side-effect I'm finding by making multiple references to other products on a single product is there's no easy way to handle pricing adjustments for attributes.

In theory, Bulk Product Creation is handy---but in my company, every product is "custom made", and there are only a handful of base sku's and a significant number of individual line items attached to each configured product. "Dude, you're getting a dell". If you remember playing with these builders online -- they don't have a bazillion SKU's. They have a handful--and configure from there.

If this is solved, how will we deal with incompatible attribute selections? The "Adjustments" tab works in Ubercart --- but heavily complex products are tedious and a huge pain to tune. The dependent attributes module for Ubercart was helpful--but so buggy--I wouldn't depend on it for much.

Sorry if anything here comes across as harsh--I still really like the newfound flexibility in DC and really do see a lot of upcoming potential.

checkerap on May 16, 2011

I think DC needs a product manager of sorts (maybe grouping the products by their product display or something else), that simple list under Store > Products becomes unusable after the first two products with multiple options.

I'm trying to add a clothing item with Size, Color and Material (Each of type List (text)). By adding products for each possible combination it easily went past 20 products just for one item.

And I can't tell why in the last drop-down I see the product titles and not the product sizes which should be the last drop-down. Maybe you guys have an idea. also is there a way to define the order of the selects from the interface? The fields in the content type are not in the order from the file attached here.

Can you use something else other than List (text) for the options? I would like to add custom colors for each product display, the colors are not exactly the standard "rainbow" types.

featherbelly on November 5, 2011

Hi everybody,

Did anyone reach any decent conclusions on this?

I have just posted a similar query: http://www.drupalcommerce.org/node/1089

Basically I need to create multiple products that have around 20 attributes each and probably around 20 options for each attribute. It seems the Commerce way of doing things would be to create 20*20=400 products. This is not a tenable solution - my client will tell me to "get lost"! I have already committed to Commerce and they are entering products with no options - however it's not too late to change tack if we really have to.

Is there a simple answer to this? Right now can Commerce handle this kind of thing in a straightforward way - or should I be looking at Ubercart for now?

Thanks

Kester

philsward on June 19, 2012

Myself, like many, have a really hard time wrapping anything, let alone my head, around the product structure of DC. Anyway I look at it, it's a daunting and hair pulling task.

What I'm wondering though, is if a compromise could be made by making actual products, the attributes themselves. What I mean by this, is instead of creating a pizza store with every possible combination of pizza dough and topping, you "build" that pizza, and everything that goes on that pizza is a product.

The base product would be the dough / style of the pizza, then each topping would be added, kind of like an attribute, but instead, it would be an add-on option. An upgrade if you will. What this would accomplish is setting each topping as it's own product with it's own price and depending on how you "build" the pizza, determines the price of the product. This would keep the respective components as products with SKU's, but give us the flexibility of not having to create hundreds of combinations. We also need a way to keep the components of a build together with the overall purchase. It's a way of combining multiple products into one big packaged product. The initial approach of DC could still be in place for the handful of people who need that type of shopping cart, and the proposed method would allow for... well the rest of us.

Let's take the skateboard site as another example. Each skateboard is a separate product. The grip tape is a separate product. Instead of offering 10 boards with 3 different colors of grip tape, plus offering each as a separate product to equal 43 total physical products, you would have 10 boards as physical products and 3 grip tape colors as physical products, totaling 13 products. This would also allow for the boards to be purchased separate from the grip tape and vice versa without having to then add all of the various combinations and keep up with price changes to them all. I think we need to get away from the mindset of "attributes" and move to a mindset of "options", "upgrades" or "add-ons". Am I wrong in saying "An attribute is a Product"? If that is the case, why not make each attribute it's own product? DC, out of the box, is flexible enough to do this. We just need that little piece that ties those various product combinations together.

I tried to do this approach a little while back on a mock up site and I was "somewhat" successful. What I ended up with, was the base product with an "add to cart" button, and each "option" or attribute with an "add to cart" button. The concept itself worked fine, but it wouldn't change the price based on the option and would have been extremely confusing to the customer. Also, each item added to the cart was a separate line item because there was nothing tying the base product and option together. The line item's would have to be grouped together somehow if this was going to work right.

To add to the mix, what I would love to see, (I know this would be a pain for the backend of things, and would probably have to be accomplished with rules) is a way of having two products, available for separate purchase, but when combined, offered at a slight discount.

Ryan
I understand your viewpoint on making each combination of product, a product. This model is designed to encompasses every possible scenario of a shopping cart. However, this approach is going to be a major show stopper for most people looking to create a shopping cart. You will find that many people will either hop over to UC or they will jump ship altogether and find a different platform. This is an issue that I believe, is hindering the growth of DC in a major way. There are countless discussions on the issue with the proposed workarounds always pointing to "make it easier to add products" because you have stated countless times that the model itself won't be changed. I'm not proposing that you "change the model", I am proposing that you approach it from a different angle. Add in a few things that will accommodate the "majority" of shopping carts. This also needs to be done at the core level, not as a contrib.

Thoughts?

MrPeanut on July 23, 2012

I agree 100%. I'd love to see attributes tied to a product. For the pizza example, it'd be nice to have attributes that are included by default (e.g. a BBQ chicken pizza might come with chicken and onion) but could be removed (e.g. no onion) or attributes could be added (e.g. add green peppers).

MM10 on August 19, 2012

I like it: "options", "upgrades" and "add-ons". What specific adjustments could be made to allow DC to be more intuitive?

mikeaja on November 13, 2013

I've spent the day trying to find a way to use DC, but it's not happening.

This discussion thread, like most others about this issue with DC has not come to a conclusion, and that is a shame.

I get the idea of not bloating the core system. But Product Variations are not attributes as most other e-commerce systems see them.

I would say, forgetting the terminology that is being used about DC, that it in fact does not support product attributes at all.

Product variations, yes. But a product attribute is what it say it is. It is not a separate product, but an attribute of an existing one.

EDIT:

Further research led me to the Commerce Product Option and Commerce Product Attributes modules (used together). They fulfill the requirements suggested in this thread (I believe).

I suspect these will become to DC what Views became to Drupal. With Views we were lucky, the maintainer continually developed it and now it is core for D8. But it could have been different if the module and not stayed maintained.

The major issue for DC here is that shop owners / developers who need a typical 'attribute' use case (where each attribute is not a separate product). will become dependent on a 3rd party module for the core of their shop. Surely this is not a good approach for DC?