Solving Magento

Solutions for Magento E-Commerce Platform

by Oleg Ishenko

Magento OnePage Checkout Part 2: Model, Views, Controller

This is part 2 of the One Page checkout discussion. You can find more about this checkout type in the Magento OnePage Checkout Part 1 and Magento OnePage Checkout Part 3: JavaScript.

Checkout Components

The checkout process described above requires a rather complex system to validate and save data, resolve step dependencies, render and update step forms. Magento implements it in an MVC pattern. First, there is a checkout model containing business logic to process steps (Mage_Checkout_Model_Type_Onepage). Then, there are views – blocks and templates to render steps. Finally, there is a controller (Mage_Checkout_OnepageController) to deal with requests posting and fetching step data. Keeping this design pattern in mind, I will describe the components of One Page checkout in the following sections:

  • Checkout session model
  • One Page checkout model and controller.
  • Checkout layout and templates
  • JavaScript layer

Continue reading

Magento OnePage Checkout Part 1

It is hard to overstate the importance of the checkout. You can’t have a web shop without a checkout – it is where customers exchange money for goods and services, which is, basically, the whole purpose of a shop. Checkout is the most sensitive stage of online shopping because there customers have to trust the merchant with their money and personal data. At the same time checkout is often a very frustrating experience: to submit an order customers must provide detailed address and payment information using long forms with many fields to fill out. Add to that dependencies between fields and validation rules, and there is no wonder that some people may become annoyed and quit in the process.

The most common way to solve the problem with the checkout data collection is to break it into steps – in each step a customer provides only a portion of the required data. Dealing with one part of data at a time is also beneficial for the checkout software – validation rules and dependencies between data (e.g. some shipping carriers are available only for certain destinations) can be better defined and made transparent to customers. Customers progressing through the checkout step by step get a feeing of being in control which results in a better shopping experience.

Online retailers strive to make the checkout as unobtrusive and intuitive to customers as possible. This quest for the perfect checkout had produced the following approaches:

  • Step-by-Step Checkout – the checkout stages (addresses, shipping methods, payment information, order review) are separated. Each step has its own form that the customer must fill out and submit before moving to the next stage. The advantage of this method is that it can be implemented without JavaScript and can be used in cases where JavaScript is not available.
  • One Page Checkout – steps are accommodated in a single page under one URL where they are put into individual tabs. The navigation between tabs and the updating of the tabs’ content happen without reloading the page – Ajax requests handle the data exchange in the background. The biggest advantage of this method is that customers get a feeling that all their data are there in one place, and in the same time there is no endless list of input fields – generally, only the active step is shown while others remain hidden in the closed tabs.
  • One Step Checkout – all steps are in one page, their input fields grouped in fieldsets but, unlike the one page checkout, all forms are visible. This approach is most advantageous when the number of fields to fill isn’t that great and breaking the process into steps makes little sense, for example, when your shop doesn’t need a shipping address and shipping method (selling downloads).
  • One Click Checkout – this approach made famous by Amazon enables customers to buy goods with a single click. This method is possible only for customers who have an account in the shop with valid address and payment information that they let the merchant use as the default checkout data. The variations of the One Click checkout may have different names (e.g., “Express Checkout” or “Express Lane”) but they have one thing in common – using existing customer account data and skipping one or more steps. This way they relieve customers from a burden of typing it all in and reduce chances of them jumping off in the process.

Core Magento implements two of these types: One Page and Step-by-Step. One Page checkout is enabled right after Magento is installed and can be used for any product type. I will describe the One Page checkout process and its components in details in this chapter.

Multishipping checkout is a Step-by-Step type and allows customers to send orders to multiple addresses. The properties and limitations of this checkout are discussed in a separate chapter: Magento Multishipping Checkout.
Continue reading

Magento Multishipping Checkout

Multishipping checkout, as its name suggests, offers a possibility to order products to different shipping addresses. To use Multishipping checkout you must enable it in the back-end configuration at System > Configuration > Sales > Shipping Settings > Options > Allow Shipping to Multiple Addresses.

multishipping_enable

Figure 1. Enabling Multishipping checkout.

Multishipping checkout availability may also depend on some other factors:

  • Minimum order amount. You can control the minimum order amount using options found at System > Configuration > Sales > Minimum Order Amount. If you set Validate Each Address Separately in Multi-address Checkout to yes the system will check each address for minimum amount separately, which means that the total for each address must be greater than or equal to the pre-set minimum order amount.
  • Physical products. Multshipping checkout is about delivery to real addresses and requires at least one valid physical item. Downloadable or virtual products need no shipping addresses and are irrelevant for Multishipping. Note that if there is a composite product whose children can be shipped separately, they are counted separately as well.
  • No nominal items. Nominal items are related to recurring profiles and are irrelevant for Multishipping, therefore a multishipping quote must not contain non-virtual nominal items.

Multishipping checkout is not available to guests. Also, new customers must register (and provide an address) before using Multishipping, which is different from Onepage checkout where new customers can choose to create an account after going through the checkout and submitting an order.

Continue reading

Taxes in Magento: Module Mage_Tax

Albert Einstein once said: “The hardest thing in the world to understand is the income tax.” It is sales tax you have to deal with in Magento, but these words can be just as true. Magento implements sales tax (or value-added tax – VAT – in some countries) with a purpose to cover maximum possible cases in different countries and locations; and the result is as complex as one can expect. This complexity is encapsulated in one module Mage_Tax that provides helpers and tax calculator models to the rest of the system.

When setting up a shop, you typically have one or several tax rates that have to be applied to products. Depending on the tax code, some products may have different tax rates than others. Also, some customers can be eligible for different rates, such as reduced sales tax for non-profit organizations. Some tax codes may require you to apply taxes based not on the location of your store but on the customer’s address – and all those locations can have different tax rates! To tackle these problems Magento operates a system comprising customer and product tax classes, zones and rates, and tax rules that must be matched to each other to produce the right tax rate.

Continue reading

Creating a Custom Product Type in Magento

The standard product types in Magento cover a wide range of possible merchandise: physical and virtual, configurable and downloadable, grouped and bundled. Yet, the e-commerce world is so diverse that often these types are not enough. There is always a chance that your product has some unique features that standard types do not cover. Fortunately, you can always extend an existing type, and I’ve shown you in my previous tutorials how to do that. Although extensions allow a high level of customization, sometimes business rules require a totally new product type. In this tutorial I am going to present such a case: a product type that requires a distinct functionality not available in core Magento. This may sound grand, but, in fact, this functionality is quite simple – it is an affiliate product.

Affiliate products are quite common. The idea behind them is that your shop is affiliated with some other retailer that allows you to display its products in your catalog. These affiliate products are not sold in your shop, they can’t be added to cart. Instead, customers are redirected to the partner shop where the actual transaction happens. The redirect link allows the partner shop to identify you as a referrer which entitles you to a commission from each sale. There are hundreds of thousands (or more like millions) websites that work like that: from humble blogs with a handful of Amazon links to e-commerce giants that “outsource” parts of their catalog to partners.

Continue reading

Magento Downloadable Product Type Tutorial

In this tutorial I am going to demonstrate some of the functions I’ve talked about in my overview of the Downloadable product type. I will develop a simple module that will add a new feature to the Downloadable type and while doing so I will be using some of the unique functions available to downloadable products.

The new feature is this: I want file size displayed next to product and sample links on the downloadable product detail page. For that I will have to do the following:

  • extend Link and Sample models with attributes to store file sizes,
  • obtain file sizes from files uploaded locally or from external URLs,
  • save file sizes to the respective attributes of Link and Sample models,
  • modify downloadable product templates to display the new attributes.

Continue reading

Magento Downloadable Product Type (Part 2)

In this post I will describe models and processes specific to Magento downloadable products. To find out about creating downloads and managing their front-end display see the first part of the Downloadable product type overview.

Downloadable product type configuration

Every product type must be configured in the Magento’s global configuration in node global/catalog/product/type. The Mage_Downloadable module’s config.xml extends this configuration with a downloadable node:

Continue reading

Magento Downloadable Product Type (Part 1)

Magento’s Downloadable product type is meant to sell files. Software, e-books, images, music or video – any type of content that can be packaged into files and downloaded can be sold using this product type. Since it is all about files, a large part of functionality implemented in module Mage_Downloadable is dedicated to deal with them: uploading and storing files, managing customer access and processing file downloads. Downloadable purchases need no physical shipping: once the order is cleared, its delivery is handled by links that the customer either gets by email or accesses by logging into his store account. In this post I will describe how to create and manage downloadable products, how are they displayed in the front-end, what specific procedures are necessary to process downloadable purchases, and how does delivery of downloads work. But before going there, let’s take a look at the configuration options of the Mage_Downloadable module.

Continue reading

Magento Bundle Product Type Tutorial

An overview of Magento’s Bundle product type would not be complete without an exercise providing a practical insight to the functionality of bundles. In this tutorial I will guide you through development of a relatively simple module that slightly alters the standard bundle implementation. If you read the first part of the discussion on the Bundle product type, specifically the description of the option and selection settings, you’d recall that some option types can be configured to allow customers to enter their own quantity when selecting an option. This property is called User Defined Quantity and is defined per selection item. Bundle selections store this flag in table catalog_product_bundle_selection in field selection_can_change_qty. By default, this functionality is available for options of type “Drop-down” and “Radio buttons” only. You can’t set this property for options of type “Checkbox” and “Multiselect”. Consider the following example from a test shop which uses sample data available here. Let’s look at a bundle with SKU mycomputer. This how the options management looks like in the back-end:

Continue reading

Adding Custom Options to Products in Magento

In my post A Magento File Custom Option Type Primer I’ve talked about how file custom product options are handled in Magento. One of the readers posted a comment there asking if there was an alternative to manually adding custom options to existing products. For such a task I can recommend MAGMI, Magento Mass Importer, which was used in one of my projects to import product data including custom options. Another solution would be writing a script which could dynamically add custom options to a set of existing products. In this post I will show you how to create such script.

First, let’s see how custom option data are written to database when a product is saved. The product model class Mage_Catalog_Model_Product has a protected method _afterSave which is called, as the name suggests, after a product model is saved.

Continue reading

Theme: Esquire by Matthew Buchanan.