Adding a new product
There are two topics at play here.
- First, we have the simple "How do I add another product to my site?" question that is easy to answer (see below). Read More.
- Second, we have the much more common "How do I add a new type of product variation?" This is typically asked at the beginning of creating a site. And we have worked hard in Commerce Kickstart 2 to make the interface for creating your first Product Variation Type very simple.
How do I add another product to my site?
Add a Product
Mouseover the word "Products" in the menu and select "Add a Product." That will give you a nice listing of the available Products that you can add to your site. If you want to create a new kind of product, definitely checkout the next section, "How do I add a new type of product variation?"
Product Form
The Product Creation Form has three sections: Title/Description, Product Variations, and Catalog Management. The Title/Description area is the Product Display and should be filled out in a way that describes the entire product, not a specific variation. For products that have a price and other attributes, you can create variations. This could one product variation or many. Finally, at the end we have our Catalog Options. These are really just a set of taxonomy vocabularies that we use to create Facets and organize our Catalog on the Demo store.
How do I add a new type of product variation?
Navigate
Mouseover the word "Products" in the menu and select "Variation types."
Click Add Product Variation
First, you should read the disclaimer at the top of the page. Second, go ahead and click on the button titled "Add product variation type."
Variation Type Form
Just like any entity type creation form (think Content Types) you can name the type of product variation. Additionally, there are three checkboxes here that will save you gobs of time: Revisions, Automatic SKU, and Create matching product display type. That third option will save you an amazing amount of time that you can quickly get up and running.
Now, we will stop the screenshots here for a second to pause and think on what we have created here. When you click "Save product variation type" there will be a content type created as well named the exact same thing with a product reference field added to it and the inline entity reference settings set up for you.
But you now have two things: A Product Variation Type and a Content type that displays Products of the new variation. Put another way, you now have your Product Display and Product Variation set up for you. The trick is now determining whether you want your fields to be on the Product Variations (things that change the price) or if you want to add fields to the Product Display (things that singularly describe the group of products for each URL).
So this means you have a set of fields for both the Product Display (the node that keeps track of product variations and gives us a viewable path, among other things) and the Product Variation (the actual product entity that can have more than one added to each display).
Choosing between Page or Variation
Page or Variation?
This illustration explains the differences between product pages (nodes) and product variations (products).
There are lots of questions you might be asking yourself about how to put your store together. This article will be tackling the question of choosing whether you should put a field on your Product Data or your Product Node. The difference is simple, products are more there for inventory (sizes and colors of one kind of shirt) and product nodes are more there for display (here's all the Commerce Guys t-shirts).
This question comes in lots of forms:
- Should I add the picture to the product page (node) or the product variation?
- Should I add the product category to the node or the product variation?
- Why is there a difference between products and nodes?
- etc.
The fact is that there are two different places you can add categories and pictures:
1. Nodes or "Product Pages" - Product pages are great for images and/or categories that represent all of that one kind of product. For example, if we had an online shoe website, we would add an "athletic" category to the Nike Jordan product page, but we wouldn't want to add a "size" or "color" to the product page, because those belong in Product variations.
2. Product Variations - These are the specific product listings that include price and "variation categories" like size, color, weight, etc.
In the graphic above we have created a visual of the difference between product pages and product variations. Typically, Product variations include the photo, but if a product's photo won't change based on size or color, then it makes more sense to add that directly to a page.
The whole point of deciding between a product page and product variation is that every field on a product variation will be loaded in javascript every time a user selects a small variation. So product variations that have photos will be replaced if the user changes the size or the color.
Product Attributes & Variations
Product attributes are the descriptors we use to define kinds of products. For example, we could describe a tshirt by the color and size. These attributes mean that in the real physical world your store may only carry one red shirt, but you have three sizes or three "variations." Commerce software must deal with product variations in a flexible way. Here's how Drupal Commerce abstracts it:
- Product Types. A product type is a specific bundle based on a custom product entity. Each bundle can have fields attached to it, including pictures and other kinds of information.
- Product "Informational" Fields. Any field on a product can be a simple "informational" field. Typical informational fields include an image of that specific configuration of a product. For example, if you sell a tshirt with a cool print in multiple colors, each product with a different color could have an image field that, when displayed on the product display node, will change when you select different attributes (like color).
- Product "Attribute" Fields. Any field on a product type with a defined list of options (list of text options, list of taxonomy terms, list of colors). The attribute fields are special because of the way they turn into selection widgets on a product display. Often you will pair an attribute field (like a color dropdown) with an information field (like an image field) to let the user "select" the blue tshirt and the Drupal Commerce system will quickly load the picture associated with the blue product.
- Product Displays. If needed at all, these are groupings of products. You can reference any type and number of products on a product display. In order to make use of product displays, we recommend only showing one type of product per product display. The product display is where you typically see the product with drop downs to "configure" or "order" the right kind of product.
Example attribute configuration
Lets walk through setting up an attribute field on a product type and see how it interacts with the product fields injected on the product display. For this example, we are using Commerce Kickstart 1.x
Product Types
Navigate to your Store page and click on "Products" and then "Product Types" and then "Manage Fields." This is the standard way to find, create, and edit different types of product. You can add as many types of products as you want, but make sure you understand the difference between product types and product displays.
*Add Product Field
When you navigate to the manage field screen, if you are a Drupal native, you'll notice that the field screen is just like a manage field screen for content types. We'll need a List (text) using a select list. This could also be a taxonomy term reference, or any kind of simple list field.
Add Field Choices
This can be any simple list, one for each new line. Let your imagination run wild!
Click "Save."
Enable Attribute Field
This is the most important step as it is what turns a normal field into an attribute field that can change the Add to Cart form on update.
Modify Products
Here is the edit screen of PROD-01 that comes with the standard Commerce Kickstart 1.x. Notice we have a new "Color" field that you have just added to the Product Type.
Repeat this for all three products. Add a picture and choose a color.
Add Product Display
Navigate to the Content List screen and click "Add Content." This will then list all of the content types on your site. Our Product Display content type is the third one after a Commerce Kickstart install. Select it to create a new Product Display to attach our three products on.
Attach Products
This is the Product Reference Field that is included on Commerce Kickstart's Product Display Content Type. Any content type that has this kind of field is able to connect products and display an "Add to Cart" button.
This field will take the three products that we have updated with our new information and create an interactive drop down list of our color field options.
Final Result
The color drop down now updates the price and picture.
Product Displays
Think of nodes as a way of grouping like products together. The most obvious grouping is one product that has variations in size, color, etc. In Drupal Commerce every variation is a product and to group them properly, we use Product Displays.
"Product Display" is the default content type that Commerce Kickstart 1.x creates and it has a product reference field. Technically, any entity that has a product reference field could be considered a product display. Nodes are the obvious product display entity type, and they're privileged because they're the default and standard entity type to use for the front-end display of content. But you could use taxonomy vocabularies, or even users as product displays.
Page or Variation?
This illustration explains the differences between product pages (nodes) and product variations (products).
Advantages of Separating Product & Product Display
A product in Drupal Commerce can represent one of several things:
- A single item for sale on the site
- A variation in a group of items for sale on the site (e.g. one size of a t-shirt)
- A non-tangible product reserved through the site (e.g. event registration)
- An item that is not purchased but which represents the purpose of payment for a particular order (e.g. donation account or campaign)
Depending on the product and the site’s needs, products may be displayed on unique pages, on pages grouping multiple products together (e.g. all the sizes of a t-shirt), on multiple different pages or Views, or not at all. For this reason, Drupal Commerce enforces a separation between the definition of a product and the product display.
This separation allows you to:
- Track stock for a single product regardless of what display it’s purchased through (especially important for multilingual / multi-domain sites).
- Use a different display strategy to fit the site (e.g. a node per product, a single View listing all available products, etc.).
- Easily manage the import and update of particular product data without worrying about updating related display settings.
Attribute Fields
Attribute Fields
Fields attached to products can be exposed on Add to Cart forms as attribute fields. These are common fields among a group of products whose allowed values may be used to select a particular product from the group to add to the cart.
The settings for attribute fields are built into the field edit form. These are typically List fields and Taxonomy term reference fields, because they have a discreet number of options. Attribute fields can use select list or radio button widgets on the Add to Cart form.
Administering Products
There are only about 20 administrative screens that come with Drupal Commerce. Most of those screens are either Views or Settings Forms. Of particular interest to store managers are the screens available for Product management.
Store Admin Screen
This is the screen you will see when you click on "Store" up in the top toolbar.
Product Listing
The Product Listing is pretty bare-bones to start with. Below we've made a simple exercise to add a few more filters and an image field. Since this is built with Views, the possibilities are literally endless.
Product Types
Manage Fields
If you click on "Manage Fields" from the standard Product Type this is what you will see. You will note that it is very similar to editing a content type, using the same interface to add fields to product types.See Product Attributes & Variations for more information.
Manage Product Display
This is where you manage how product fields will display in a variety of contexts, such as in the different view modes for product display nodes.
Product Edit Screen
We've included the product edit screen for your benefit to see the Product Entity form in all of it's glory. Pretty simple, we've got the Product SKU and Product Title that are required. Additionally, Commerce Kickstart has added the Image field. The Price can be changed to allow for multiple currencies.
Customizing On-site Product Administration
Because all the back-end interfaces in Drupal Commerce are default Views, you have the ability to tailor each page to your needs. The product list includes a simple SKU filter by default but can do much more for you through customization. Below we include a simple exercise where we add an image field, hide the "type" field, and extend a product title keyword filter.
Edit Product View
To start with we are going to use a shortcut to edit the product listing view. This is a very simple way to tweak nearly all of the Drupal Commerce administrative screens.
Remove Product Type
Our first step is to remove the product type. This will be replaced later on with an exposed filter.
Remove Product Type
This is a great way to remove and re-order the fields on the product listing table. It's got a nice drag and drop feature as well as a very simple "Remove" capability.
Add Image Field
Go ahead and click "Add" next to the fields list and select "Commerce Product: Image" which is about halfway down in the list. Imagine for a second how many fields are available here for your use. The most useful are probably the "Commerce Product" fields, but there are many more to choose from.
Edit Field Image
We want to remove the default colon and change the image to display as a thumbnail. You may want to go back and re-arrange the fields so that the image field appears closer to the front of the table. See Remove Product Type up above.
Add Exposed Filters
Exposed filters are one of the coolest features of Views. They create a simple form at the top of the administrative interface and let you setup simple keyword searches and drop downs that are automatically generated.
Add Filter Criteria
Here we're adding two exposed filters. We're going to enable keyword search for Titles and drop down selection for Product Types.
Configure Title Filter
For the title, we will expose the filter and change the operator to "Contains any word."
Configure Type Filter
The Product Type Exposed Filter automatically knows it can be a drop down of all available product types.
Submit Button Change
Lets change the exposed filter submit button from "Apply" to "Search."
Change Submit Text
It's really that simple. Next we will view our product administration screen. Don't forget to save your View!
Product Admin Screen
Final Customized Drupal Commerce Product Administration Screen.
Contrib Product Administration
If you don't want to tweak Views on your own, we recommend using one or more of the modules listed below to tweak your Drupal Commerce Product Administration experience:
- Editable Fields - http://drupal.org/project/editablefields
- Commerce VBO Views - http://drupal.org/project/commerce_vbo_views
- Admin VBO Views - http://drupal.org/project/admin_vbo_views
On the drupalcommerce.org community site, there is a community-fueled list of all available Drupal Commerce Administrative Modules.
Bulk Product Management with VBO
Using Views Bulk Operations will let you perform batch processes across your whole product list or a subset of the list using specific operations or Rules based operations. The Commerce VBO Views module provides a replacement default product View with a VBO version you can use as an example. Note that it does not overwrite the existing View but disables the default View and enables the VBO View at the same URL.
Further integrating Editable Fields with the VBO powered View will also let you edit individual field values within the View itself even without a batch process.