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 →

Mage_CatalogRule is a core module tasked to provide automated catalog price management, which can be controlled by a set of conditions. These conditions define a subset of the catalog to which price rules apply. For each rule a date range can be set, within which the rule is used. Also rules can be set to apply for certain customer groups. Catalog rules are defined on a website level, i.e. if a website has several store views, a website catalog price rule will apply to them all.

The catalog price rule management interface is found in the shop administration back-end under Promotions => Catalog Price Rules. If you are using a test installation with sample data (which you can obtain here), you can already see several catalog rules in the grid. We will discuss one of them as an example. If you don’t have the sample data – you can create sample catalog rules as we go over them.

Continue reading →

Loading module configuration is one of the most important stages of the application initialization. It takes place relatively early in the process soon after the basic configuration is loaded from the etc/config.xml and etc/local.xml files and before instantiating the front controller and the request dispatching.

Module initialization starts in the Mage_Core_Model_App::run function. in it you can find a call to the function _initModules():

protected function _initModules()
{
    if (!$this->_config->loadModulesCache()) {
        $this->_config->loadModules();
        if ($this->_config->isLocalConfigLoaded() && !$this->_shouldSkipProcessModulesUpdates()) {
            Varien_Profiler::start('mage::app::init::apply_db_schema_updates');
            Mage_Core_Model_Resource_Setup::applyAllUpdates();
            Varien_Profiler::stop('mage::app::init::apply_db_schema_updates');
        }
        $this->_config->loadDb();
        $this->_config->saveCache();
    }
    return $this;
}

This function uses an object of type Mage_Core_Model_Config to load the model configuration. The system checks if the configuration can be fetched from the cache, and if not, proceeds with loading it from module declaration and configuration files.

Continue reading →

Magento is a web application implementing a Front Controller pattern, and this means that most HTTP requests are routed to the index.php file in the root folder. In order to display a category, a product, or a non-catalog information page Magento parses the incoming URL to determine which modules and controllers must be engaged to process the request. When the URL rewriting is not enabled Magento URLs look like this: catalog/product/view/id/166 or catalog/category/view/id/10. These are valid URLs and they contain important information, which Magento uses to produce HTML output. Thus, catalog points to the module Mage_Catalog, product is translated into ProductControler, view – into viewAction, and the parameter id passes its value “10”. Altogether such URL generates a call to function Mage_Catalog_ProductContoller::viewAction(), which renders a details page for a product with ID 10.

Despite being logical and well fit for an MVC web application which is Magento, this URL pattern has two significant drawbacks. First, it is not human friendly. The IDs used in these URLs tell users nothing about the shop products or categories. Second, these URLs are not search engine optimized because they contain only generic terms (“catalog”, “product”, “category”) that have little effect in achieving high search engine positions. Ranking algorithms of the modern search engines (Google, above all) place high value into terms contained within URLs. For these two reasons, human and search engine compatibility, it is imperative to include product and category names into shop URLs. Descriptive URLs consisting of words meaningful for both humans and search engines improve user experience and place the links to your shop higher in the search results relevant to your business.

Magento uses a rewrite engine to match descriptive URLs to its resources. The rewrite engine is a part of Magento core system and is responsible for matching incoming descriptive URLs to controllers, actions, and entity IDs. It is also tasked with automated creation of descriptive URLs for Magento resources.

Continue reading →

Imagine a situation: you are developing a custom e-commerce framework and are about to put some finishing touches to your order model. The task is to program functionality, which creates an order at the end of the checkout and saves it to the database. You realize that a confirmation email has to be sent and you add the necessary code. Next morning a product manager asks you to send a copy of the e-mail to his address, and you extend your code accordingly. At a meeting in the afternoon the warehouse guy proposes to automate inventory management by sending a message to the warehouse software; and you implement it in your code. Exporting order as an XML file to feed into the shipping system – done. Notifying the purchasing department when the inventory is too low – done too.

After all this you take a look at your order model and its function placeOrder and see it has become an unmaintainable mess. All these diverse and complex tasks just do not fit into the order model. Yet they are essential for the your business and must be implemented. Situations like this are not uncommon. The growing complexity of enterprise applications often results in code that is inflexible and difficult to maintain, and prohibitively expensive to scale.

Event-driven software architecture has evolved to address such problems by decoupling services and service providers. It introduces events – notable milestones in business processes that invoke services, which observe and react to them. Events alert their subscribers about a problem, or an opportunity, or a threshold in the current process flow. An event broadcasted in the system usually consists of an event header and body. The event header contains an ID that is used to locate subscribers, while the body transports information required to process the event. In some systems event headers can also include information on the event type and creator, or a timestamp – whatever data the specifications mandates.

The service providers are independent entities and can be added or removed without affecting objects, whose events they listen to. Event creators have no knowledge of the subscribed service providers and do not depend on them. Similarly service providers are not interested in the internal mechanics of event creators. This allows for extremely flexible, loosely coupled and distributed systems. This advantages, however, come at a price – tracing events and their subscribers can be difficult.

Mage::dispatchEvent('event_code', array('myObject' => $myObject));

The basic experience of a web user is browsing web documents requested by URLs. In the beginning of the Internet most web documents were static HTML files stored on a server. Later, these documents started being dynamically generated, but in the essence almost every requested URL was processed by a separate file that it was matched to. Such approach is known as Page controller. Martin Fowler describes it as “one path leading to one file that handles the request”. He also adds, that this “is a simple model to understand”. However, its apparent simplicity becomes an issue in a complex web application such as an e-commerce site. There can be hundreds if not thousands of possible request types. Creating and maintaining a file for each of them is a laborious and inefficient task. And there are many subroutines which are shared among request processors. Initializing resources, establishing database connections, starting sessions and authenticating users – these and many other tasks are repeated every time a web application handles a request.

A solution to this problem is known as Front Controller. This design pattern channels every incoming request to a single point of entry – a front controller. This handler object performs all the common subroutines and then dispatches the request to a controller that handles specifics. The adoption of this approach is wide-spread owing to its flexibility and scalability.

Continue reading →