Products and variants documentation #2437
Conversation
| --> | ||
|
|
||
| If none of a product's `Spree::Variant`s have a price value for the site's | ||
| configured currency, that product is not be visible in the store frontend. |
| ## Product properties | ||
|
|
||
| You can also configure products to have [product | ||
| properties](product-properties.md) Product properties allow you to add custom |
There was a problem hiding this comment.
Should these be two sentences?
benjaminwil
force-pushed
the
products_and_variants_documentation
branch
from
02e08e1 to
061265a
Compare
| You can see a product's price in the store's configured currency by calling the | ||
| `price` method on that instance: | ||
|
|
||
| ```shell |
There was a problem hiding this comment.
This should be ruby rather than shell.
| If none of a product's `Spree::Variant`s have a price value for the site's | ||
| configured currency, that product is not visible in the store frontend. | ||
|
|
||
| You can see a product's price in the store's configured currency by calling the |
There was a problem hiding this comment.
We're talking about variant's above, but products here. How does this work?
| `Spree::Variant` models depend on each other, it is important to understand how | ||
| they are different: | ||
|
|
||
| - `Spree::Product`s track the general information about a product. This includes |
There was a problem hiding this comment.
We're talking about products and variants here using the same terms. I think it would be best to start with examples of cases where a product has variants, and what the product is and what the variant is.
There was a problem hiding this comment.
You are very right. I've extended the products and variants bullet points here.
| product. The variant stores the product price, dimensions, and weight. The | ||
| variant provides the information required by orders and shipments. | ||
|
|
||
| The `Spree::Variant` model provides the price for each line item in an order. |
| a t-shirt, you would set up a product for each of them. | ||
|
|
||
| If you have a number of items that are similar (like t-shirts that come in | ||
| small, medium, and large sizes), you can create [variants](#variants) for a |
There was a problem hiding this comment.
This information should come first to provide context about the information listed above.
| dimensions, and other properties. | ||
|
|
||
| Line items use a `variant_id` to associate a variant with an order. So, every | ||
| product has at least one `Spree::Variant`. |
There was a problem hiding this comment.
This would be a good point to bring up master variants.
| a variant. | ||
| - `cost_currency`: Set an alternative currency for your variant. | ||
| - `cost_price`: Sets the price for the variant if it uses an alternative | ||
| currency (`cost_currency`). |
There was a problem hiding this comment.
It sets the cost price even if it's not in an alternative currency.
| can set positions by drag-and-dropping any variant in the list of variants on | ||
| a product's **Variants** tab.) | ||
| - `track_inventory`: Set whether inventory should or should not be tracked for | ||
| this variant. |
| a product's **Variants** tab.) | ||
| - `track_inventory`: Set whether inventory should or should not be tracked for | ||
| this variant. | ||
| - `tax_category_id`: Overrides the product's tax category for this variant. |
| item. | ||
| - If a product has more than one variant, then the master variant does *not* | ||
| provide the price and other properties to the line item. Instead, it is used | ||
| as a template for other variants. |
There was a problem hiding this comment.
If I have a red shirt, and a green shirt in small, medium, and large. What should my master variant be?
There was a problem hiding this comment.
I am not sure I know the correct answer to this. If the red shirt only comes in one size, then it should be one of the green shirts. Right?
Would it be best practice to assign the master variant to the "lowest common denominator" between the shirts?
I started working on an example with mugs:
The master variant should be the "lowest common denominator" between all of your
variants. For example, if you have five variants on your mug product that have
option types of "Color" and "Size", as well as different prices, it would be
advantageous to set the master variant to the variant that has the most common
color, size, and price.
| "Mug" variant | Color | Size | Price |
|---------------|-------|---------|-------|
| 1 | Green | Regular | $12 |
| 2 | Green | Large | $14 |
| 3 | Red | Regular | $12 |
| 4 | Red | Large | $14 |
| 5 | White | Regular | $12 |
In the table above, the "Mug" variant 1 or 3 would be appropriate master
variants. This is because the majority of the variants share values with them
("Green" or "Red", "Regular", and "$12").
There was a problem hiding this comment.
But beyond what the master variant "should" be, I also added this information to the "Master variants" section:
By default, the master variant is the first variant created for a product.
There was a problem hiding this comment.
Update: Gregor and I chatted privately and sorted this out. Silly me, generic master variants are the way to go.
Thanks to gmacdougall for his review.
benjaminwil
force-pushed
the
products_and_variants_documentation
branch
from
061265a to
a581055
Compare
|
@gmacdougall Thank you for your review. I've addressed all your comments. Next time you have a chance, could you re-review my changes? |
I've rewritten the existing products and variants guide. It's been split up into multiple articles. Some of them, especially the "Multi-currency support" article, are stubs anticipating growth.
Summary:
Spree::Modelthat is essential to setting up Solidus products and variants.#gallerytoVariantandProduct#2337.) It'll make for easier docs maintenance later on.This is part a larger project to improve Solidus's documentation. See this gist with the high-level table of contents. Where and how this documentation will exist is still up for discussion.