0

This is probably an embarrassingly basic question, but I haven't been able to find a definitive answer after a fair bit of searching.

If you're setting up a store with Drupal Commerce (2.x, in Drupal 8), and each of your products come in a variety of colours, but the range of colours is different for each product - should Colour be a single attribute, added to a single product variation type, and then assigned to a single product type (assuming no other significant variations in product structure)?

Or should each specific set of colours be a different attribute and/or a different product variation type, which I suppose would mean each individual product would need a unique product type?

To clarify, we're talking several dozen products, each of which might come in anywhere from 10-30 unique colours that are only used for that one product, so the total possible number of colours would be well into the hundreds, if that makes a difference.

I'd like to set this up in the most efficient and user-friendly way possible, since the staff who will be maintaining the site and adding items in the future may not be very technical... So the less configuration they have to do for new products, the better. But on the other hand, having hundreds or thousands of colours showing up in a single dropdown when they're trying to create product variations might be overwhelming.

0

I'll preface this by saying that every situation is different so it's hard to say what the "best" option is. This tutorial seems to go the route of having different product variation types, with a specific color attribute created per variation type. Having a separate variation type for every item feels a bit awkward, but it might make sense in your scenario.

Two other solutions that I can think of are:

1. Multiple Attributes (only):

You could do this without creating unique product types for every product, or even multiple product variation types. You could have 5, 10, 2000, however many different color attributes, all of which are made available to your single product variation type.

The main drawback that I foresee with having separate attributes for each color set is that, after the fact, any grouping/reporting that needs to be done on colors may need to accommodate all of these disparate attributes in a single place. One way to help mitigate this might be to create an "attribute categories" (or similar) taxonomy vocabulary to group related attributes together, and tag that on a taxonomy ref field on each attribute. If you anticipate this only ever being an issue for "colors" then you could probably also get away with adding a boolean field to do something similar.

That said, having the color sets as separate attributes might be preferred for reporting as well. Hard to say.

2. One Attribute

Another option is to have a single Color attribute containing every single color, but add a Product Entity Reference field onto it. In this case, every color would inherently be treated the same, but you could relate them directly to their associated Products. This avoids the issue of needing to relate the different attributes after the fact. This would give you the option to do a form_alter on the product_variation creation form to limit the options on the color attribute field to those which reference the Product that you're creating a variation of.

This option could end up with a pretty big list of options when editing the attribute, though, so it might be worth populating it with a bunch of dummy data to see how it fares. Devel_generate (included with Devel module) might be helpful, here.

EDIT: I should note that I initially failed to say that option 2 was my preferred option, for the same reason that Ryan notes in his answer. That is to say, all colors are colors and should be present on the same attribute. If Select2 is viable for attributes fields then that's probably the simplest way to make the list more manageable when authoring new product variations.

Alternatively, as mentioned in 2, using a reference field on each color to its related products (or alternatively a reference field on the product to its given colors) would maintain the "correct" single attribute while also allowing you to limit the options to those appropriate for the current product. IMO this probably leads to a less overwhelming interface in the event that the list of available colors is sufficiently large, and could also be paired with something like Select2 to further improve the authoring UI/UX.

2
  • Thank you. It sounds like your solution #1 would probably result in the greatest ease of use for staff entering products, which is a priority with this site, so I think that is probably the best choice.
    – DCCweb
    Sep 16 '20 at 18:25
  • 1
    @DCCweb Please see my answer below; just trying to make sure you take the right approach here (as the creator of the software). Sep 17 '20 at 2:47
1

Absent any other details, this question actually has a single definitive answer. I hate to contradict an accepted answer, but the only way I would build the site to address your use case would be:

  1. One "Color" attribute with...
  2. Values for every possible color...
  3. Variations on your product type only for the colors the product needs.

Each product contains one or more variations differentiated (usually) by having one or more attribute value differing from the others. In your case, it would be one variation per unique color. Nothing requires you to use every available attribute value in a product. For example, there's no reason you can't have one "Color" attribute with values for "Red", "Green", and "Blue" and have a product on your site whose only color variations are "Red" and "Blue."

(I see from Mrweiner's comment that the selected answer was trying to solve the UX problem via existing architectural components. I'd recommend setting the proper architecture first and solving the UX challenge separately, e.g. via a front-end library like Select2 or other that makes large select lists more manageable.)

6
  • good to have you in, happy to have my answer corrected by you.
    – Mrweiner
    Sep 17 '20 at 2:49
  • 1
    This doesn't actually address the issue of not wanting a colors attribute with "hundreds or thousands" of options when a content manager goes to add product variations. I was trying to offer solutions that would minimize the size/length of that list.
    – Mrweiner
    Sep 17 '20 at 2:58
  • 1
    @Mrweiner Good point; I just wouldn't use a traditional select list, to be honest. I should've added that we've made good use of libraries like Select2 to simplify select list UX - it basically turns a select list into an autocomplete + tagging type solution. I'll have to see what it'd take to add that to an attribute selection form. Sep 17 '20 at 13:32
  • In other words - I'd solve the UX as a separate problem but make sure I had the right architecture first. Sep 17 '20 at 13:33
  • 1
    yeah that makes sense. Select2 came to mind for me last night as well. Wish I'd remembered it the other day!
    – Mrweiner
    Sep 17 '20 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.