Before we get to the next step—adding products to our store—it's worth taking some time to discuss how Ubercart treats products within the system.
Products in Ubercart are nodes, which means that you can do anything with products that we've done with nodes in the rest of this book: you can add comments or ratings, tag them, add CCK fields to hold additional properties, display products in listings with
Views module, and so on. This seamless integration of store products with the rest of the content that Drupal can manage is a "killer" feature of Ubercart.
Ubercart's Product module defines a single "Product" node type, which comes prebuilt with fields such as SKU and sale price, as pictured in Figure 10-13. These fields interact directly with other parts of the system, such as sales reports and shipping calculations.
A single-product node type is sufficient if you are only selling one style of product in your store, such as a club membership. Many online stores are more complex, however. Amazon.com sells books, movies, and, as we saw in Chapter 4, kitchen utensils. Books have properties like "author" and "ISBN number," and movies might have properties like "rating" and "movie studio." Can you imagine how long the product node form would be if it needed to provide a field for every single one of these properties for all possible types of products? No thanks.
Luckily, the Ubercart developers have a solution to this predicament: special node types called product classes. Product classes are slightly different than standard content types, as they need to inherit the base product fields. However, once a product class is created,
Spotlight: Products, Product Classes, and Attributes | 355
it will then look and behave like a normal Drupal content type—there will be an entry form for it under "Create content" (node/add), and we can edit fields and properties via AdministersContent managements-Content types (admin/content/types). Each product class may be customized without affecting other products. You can create a product class for "Book" and a product class for "Movie" and use CCK to give each its own specific properties. We'll make use of product classes later on for creating our T-shirt and sticker products.
In order for Ubercart to recognize a node type as a product, it must be either the "Product" node type supplied by Product module, or created as a "product class" node type. Without this, the various product properties won't appear to enter required fields such as SKU and sale price.
But what about products like T-shirts, which are fundamentally the same product type, but for which there are multiple variations of the same product, such as different colors and sizes? These variations, though important distinctions for order fulfillment and sometimes price, aren't really separate products, but rather different options for a single product. It would surely be tedious to create one product for "Red, Small Drupal logo T-shirt" and another for "Red, Large Drupal logo T-shirt" and yet another for "White, Small, Drupal logo T-shirt," and so on.
Ubercart refers to these sorts of minor variations as attributes, which are supplied by the Attribute module. Each attribute, such as "Color," is given a series of options, such as "Red," "Blue," and "Plaid," which a customer may select when adding the product to his shopping cart. Attributes may be shared across different product classes (both stickers and T-shirts might have a color), or specific to one type of product. You can even set different pricing for different attribute options, as that Plaid T-shirt requires hand-sewing from the local tailor. Figure 10-14 shows an example of a "Media format" attribute, which might be applied to albums. CDs are physical entities, and therefore have an associated cost and weight. MP3s, on the other hand, are digital and have neither of these properties.
Was this article helpful?