Fieldable Products and the Add to Cart Field
One of the most exciting changes planned for Ubercore for both site builders and developers is the near total re-implementation of products thanks to Drupal 7's Fields API. The following represents a summary of conversations, midnight brainstorming, and sprint discussion that should be refined into a solid spec. for the first round of Ubercore development.
Right now, Ubercart confuses "what a product is" with "how a product is displayed." When you start out, a product is a node. However, thanks to SKU adjustments, a node might represent multiple products. This then causes problems with reporting, stock tracking, selling some non-tangible goods / accepting donations, and importing / exporting the product database. Furthermore, it makes it difficult to define a decent API for developers working with products and product attributes.
So, the primary thing we wanted to do was to separate a product from its display on the site. This means products will no longer be tied to nodes. The core product entity will be a separate, fieldable entity. It will consist of at least a SKU and a default price and title. Additional fields describing the products may be attached to product entities to form new product types. These fields will take the place of what attributes are now, the main difference being that attributes are being assigned to individual products, not used as selectors between multiple products displayed on a single product node. I imagine we'll work out a way to do things like attach a Filefield to a product so that when that product is purchased the user has access to that file, but that's hardly a core feature.
We're still concerned with how products will be displayed for purchase, though. To that end, we'll probably still either ship with (or create on installation) a product display node type that bundles an Add to Cart field. In edit mode, an Add to Cart field will let you select from among products you have already defined and described in your product database (or add a new one) through a modal dialog. You can just add one product to sell something much like you would through a product node now, or you might add multiple products and specify how they should be combined in the add to cart form for sale. So, if you selected three t-shirt products that each had a different value in their "Size" field, you could have them be displayed on a form that lets you specify the product through a "Size" select list in the same way you would now through attributes. The key difference here is that every variation of a product is stored in the product database, giving us a clear record of what was sold. Anyone familiar with the shortcomings of the product attributes system (both its UI and API) should see the benefits here. Additionally, we figured that the Add to Cart field shouldn't just be restricted to displaying a form but should be open to links, buttons, etc. So, through the field you're selecting what products are displayed on the node (or whatever entity you attach the field to), how the products should be associated, and how they will be added to the shopping cart.
Separating the product from the display gives the site builder or developer more freedom to decide how products get in the shopping cart. For example, sites taking donations or selling non-tangible goods might not want to fool with product nodes at all! They might just want a way to drop a product in the cart and go straight to checkout. With this system, they could do so, and the default title and price on the product let us have a way to represent the product in the cart even if it's not linked to any particular node on the site.
We had some wireframes and whiteboard brainstormings related to all this posted here: