<p>I'll go ahead and add this as an answer with a bit more detial....we have a large number of variants in total - about 50 different box sizes for about 110 types of product (each product has ~ 10 sizes associated with it).  In addition, we do services and there are about 50 variants there, for each of about 12 products.</p>

<p>In all, the simplest solution if things are relatively static is a bit of data entry...people, in my experience, worry far too much about programmatically generating things that then become hard to maintain (ecommerce tends to have al ot of exceptions and unusual scenarios and programmatic things soon get out of hand) - sometimes a tedious hour or two of data entry is actually a much more effective long term solution to the problem.  (And they invented student/interns for this right?!).</p>

<p>That said, Craft's excellent relations system can help <em>a lot</em> here - if your variation sizes are standard things, you can create a section to store your 'standard boxes' or 'standard variants' or whatever, and then relate these to your variants using an entries field on your variants for that product type.  </p>

<p>Then, in your templates and/or shipping plugin etc, you simply refer to these standardised entries - rather than the variant itself - to get the data you need for your width, height, depth, and weight.  This can dramatically reduce your data entry work and keep things MUCH more DRY - there's one standardised place to add/change/remove data for your variants.  It's very effective...but it does mean you do need to have your own shipping plugin as you're sort of over-ruling Commerce's default behaviour here.</p>

<p>(One great thing Commerce could do to help and avoid the need for a plugin here would be to make it an option to specify a bit of twig for these standard fields so you could do things like specify a default value for height of  <code>{standardBox.first().height}</code> -  where <code>standardBox</code> is a field on the variant and that would then be parsed into the product when it is saved...)</p>

CC BY-SA 3.0
2016-11-23T23:12:54.130Z
2016-11-23T23:12:54.130Z
Jeremy Daalder
<p>I'm currently building a site for a client who's products vary in price depending on the width / height selected. Essentially what this means is each product has around 70 possible variations, each with it's own price.</p>

<p>My initial idea was to inject some JS that would allow the client to manage the variants in a table that would automatically generate / update the variants based on the contents of the table. Unfortunately, as far as I can tell, there is no way to access the JS that manages the variants as it's all done in a self contained, anonymous class.</p>

<p>I also tried creating a custom <code>Purchasable</code> entry type that would let me dynamically set the price of the of the line item based off the selected width &amp; height. The keyword there being <em>tried</em>. I'm still trying to get to grips with custom Entry Types, and trying to get it to work with Commerce on top of trying to get it to work at all has made me, well, somewhat less than successful.</p>

<p>Has anyone had any success with managing large numbers of variants, or does anyone know of a simpler way to achieve what I'm after?</p>

CC BY-SA 3.0
2016-05-15T23:54:42.850Z
Are the widths/heights consistent between products?  If so you can set up a channel of entries for the width height combinations and then related these to your variants.  We do this with our products, we've set us 'standard boxes' for shipping classes for items basically, as we haev endless SKUs that are all basically the same thing.  Then when building out the variations you just relate the standard box to it and set the price basically.
Jeremy Daalder
<entry-type><plugin-craftcommerce>
Managing a large number of Variants in Craft Commerce
# Managing a large number of Variants in Craft Commerce

(Asked by: username_0 on 2015-12-01)

I'm currently building a site for a client who's products vary in price depending on the width / height selected. Essentially what this means is each product has around 70 possible variations, each with it's own price.

My initial idea was to inject some JS that would allow the client to manage the variants in a table that would automatically generate / update the variants based on the contents of the table. Unfortunately, as far as I can tell, there is no way to access the JS that manages the variants as it's all done in a self contained, anonymous class.

I also tried creating a custom `Purchasable` entry type that would let me dynamically set the price of the of the line item based off the selected width & height. The keyword there being *tried*. I'm still trying to get to grips with custom Entry Types, and trying to get it to work with Commerce on top of trying to get it to work at all has made me, well, somewhat less than successful.

Has anyone had any success with managing large numbers of variants, or does anyone know of a simpler way to achieve what I'm after?

**Tags:** entry-type, plugin-craftcommerce

> **Comments:**
> **username_1**: Are the widths/heights consistent between products?  If so you can set up a channel of entries for the width height combinations and then related these to your variants.  We do this with our products, we've set us 'standard boxes' for shipping classes for items basically, as we haev endless SKUs that are all basically the same thing.  Then when building out the variations you just relate the standard box to it and set the price basically.  

---

## 1 answers

### Answer by username_1 on 2016-11-23. Score: 3

I'll go ahead and add this as an answer with a bit more detial....we have a large number of variants in total - about 50 different box sizes for about 110 types of product (each product has ~ 10 sizes associated with it). In addition, we do services and there are about 50 variants there, for each of about 12 products.

In all, the simplest solution if things are relatively static is a bit of data entry...people, in my experience, worry far too much about programmatically generating things that then become hard to maintain (ecommerce tends to have al ot of exceptions and unusual scenarios and programmatic things soon get out of hand) - sometimes a tedious hour or two of data entry is actually a much more effective long term solution to the problem. (And they invented student/interns for this right?!).

That said, Craft's excellent relations system can help *a lot* here - if your variation sizes are standard things, you can create a section to store your 'standard boxes' or 'standard variants' or whatever, and then relate these to your variants using an entries field on your variants for that product type.

Then, in your templates and/or shipping plugin etc, you simply refer to these standardised entries - rather than the variant itself - to get the data you need for your width, height, depth, and weight. This can dramatically reduce your data entry work and keep things MUCH more DRY - there's one standardised place to add/change/remove data for your variants. It's very effective...but it does mean you do need to have your own shipping plugin as you're sort of over-ruling Commerce's default behaviour here.

(One great thing Commerce could do to help and avoid the need for a plugin here would be to make it an option to specify a bit of twig for these standard fields so you could do things like specify a default value for height of `{standardBox.first().height}` - where `standardBox` is a field on the variant and that would then be parsed into the product when it is saved...)


---

