This is the second part of our discussion on Magento Bundle product type. In the first part we concentrated on the back-end management of bundle products and on the front-end display specifics. In this post we will discuss the functionality implemented by the Bundle product type class; but first, let’s look at bundle options and selection classes.

Bundle Option and Selection Classes

Bundle options are represented by model class Mage_Bundle_Model_Option and a resource model Mage_Bundle_Model_Resource_Option. The option data is saved in two tables: catalog_product_bundle_option and catalog_product_bundle_option_value. The first table contains the general option data such as:

• option_id – a unique option identifier;
• parent_id – ID of the bundle product to which the option belongs to;
• required – a flag indicating that a bundle can’t be added to cart without this option being configured;
• position – parameter used to sort lists of bundle options in an ascending order;
• type – one of four allowed option types: drop-down, radio buttons, multiselect, and checkbox. The string constants corresponding to each type are defined in the Mage_Catalog_Model_Product_Option class:

  class Mage_Catalog_Model_Product_Option extends Mage_Core_Model_Abstract
  {
          /**code omitted for brevity **/
          const OPTION_TYPE_DROP_DOWN = 'drop_down';
          const OPTION_TYPE_RADIO     = 'radio';
          const OPTION_TYPE_CHECKBOX  = 'checkbox';
          const OPTION_TYPE_MULTIPLE  = 'multiple';
          /**code omitted for brevity **/
  }
  

  Listing 5. Option type constants, /app/code/core/Mage/Catalog/Model/Product/Option.php, line 65

Continue reading →

Bundle is a composite Magento product type with many useful properties, most prominent of which, in my opinion, is its flexibility. Bundles are usually understood as two or more products sold together. Magento’s Bundle product type does that and more. It has features similar to that of other composite types, Grouped and Configurable, but also differs from them significantly.

For example, product grouping is achievable in a simple form with the Grouped product type. Bundle type, however, allows more complex product combinations. There is a two-tier grouping in Bundles. The first tier is comprised of options. Options are grouping entities that have one or several selections (second tier), and each selection is tied to one product. Also, unlike Grouped products, whose children are added to cart and ordered as single products, Bundles behavior in this regard is more like that of Configurable: in quotes and orders Bundles are represented by parent and child items.

When buying a Bundle a customer must configure it but in a different way than a Configurable. Configurable products have one or more attributes whose values can be selected and each selection option is linked to one child product (Simple, Virtual, or Downloadable). Bundles, on the other hand, have no configurable attributes, and their options can offer more than one product to select from. Also, an option can be configured to accept more than one selected product.

Continue reading →

The Grouped product type is one of the three composite product type available in the standard Magento installation. Being composite means that products of this type are comprised of one or more child items. Grouped products make it possible to bring together several single products under one roof without them having to share any specific feature, like associated products of a configurable being essentially the same product with one or several variable attributes, or to be inseparable parts of one greater offer, like elements of a bundle product.

Thus the defining feature of a grouped product is a loose relationship between its elements. It is customer who decides what grouped items and in what quantity to buy. To illustrate this let’s consider a grouped product that is available in Magento sample shop data, which you can download from the Magento website (here).

The example product is called “Magento Red Furniture Set” and has the SKU 1114. Its detail page looks like this:

Continue reading →

In this post we will look into the functionality of Mage_Catalog_Model_Product_Type_Configurable, in what way it differs from that of the parent class Mage_Catalog_Model_Product_Type_Abstract and will see what unique features does Configurable type have. This is the second part of the discussion started in post Magento Configurable Product Type (Part 1).

We have already reviewed the role played by product type models and talked about functions implemented in the base product type class Mage_Catalog_Model_Product_Type_Abstract, and you can read about it in my post Product Type Logic Implementation in Magento. I am going to follow the structure laid out previously and describe the functionality provided by the configurable product type class in groups.

Continue reading →

If the merchandise you sell in your shop has options, which customers can select from before adding products to the shopping cart, then Magento’s configurable product type is an obvious choice. Configurable products are rather common: shoes (sizes), apparel (colors, sizes), jewelry (material, gems), and many others. The configurable type is quite complex and must be approached carefully because it can add a considerable penalty to the shop performance. In this post we will discuss the architecture of the configurable product type and get an insight into its internal mechanics so that you can employ it correctly and efficiently.

Before diving into the technical details, let’s make an overview of the management of configurable products in the back-end as well as follow a customer browsing such a product in the front-end. In this exercise we will use the sample data you can download from the Magento website (here).

Continue reading →

Depending on what merchandise your shop specializes in, you may need different product types. The basic, simple product type logic is straightforward: a product has a price, it has product information like pictures and descriptions, it has inventory that can be linked to a warehouse management system. Products of this type can be placed into a shopping cart, paid, packed and sent. But it is not always that simple. You may need products that are not physical, but are files that can be downloaded by customers who bought them. Your products may be still physical, but consist of several options, which customers must choose from before adding their chosen combination to the shopping cart. Several simple products could be grouped together and sold as a single one. Or a product may be just an entry in your catalog whose details page has a link redirecting to the shop of your partner. We are talking about product types that have certain behaviour and require functionality sometimes similar and sometimes distinctly different from each other.

Magento stores product data in database tables and uses complex EAV models to retrieve and manipulate that data. The product functionality mentioned above is not a part of the EAV system. It is implemented in a set of classes that all extend one abstract class, Mage_Catalog_Model_Product_Type_Abstract. These classes are regular Magento models inheriting all the way up from Varien_Object. If necessary, these models can be connected to resource models and through them to database data. Magento core offers the following product types:
Continue reading →