Magento modules

Les modules et extensions Magento

Bestsellers list vs flat product catalog in Magento

Magento uses the EAV database model by default, but it's also possible to use a flat product catalog in your shop. Enabling this option can result in improved performance, but it also may cause some of the sites to display unproperly. A best selling products list could be an example of that.

A best-seller list can be built using collections:

$collection = Mage::getResourceModel('reports/product_collection');

$collection->setVisibility(Mage::getSingleton('catalog/product_visibility')->getVisibleInCatalogIds());

$collection = $this->_addProductAttributesAndPrices($collection)
    ->addOrderedQty()
    ->addStoreFilter()
    ->setOrder('ordered_qty', 'desc')
    ->setPageSize(5)
    ->setCurPage(1);

$this->setProductCollection($collection);

This way we create a collection of products ordered by the quantity of orders. However - when diplaying the collection in the template you may find that some of the data (product name, image) was not properly fetched and are not displayed. This is a result of the addOrderedQty method performing a wrong query. Here's the solution.

The addOrderedQty method is a part of the Mage/Reports module - you can find it in Magento's app/code/core/Mage/Reports/Model/Mysql4/Product/Collection.php. The interesting part lies at the very bottom of this function:

$this->getSelect()
    ->joinInner(
        array('e' => $this->getProductEntityTableName()),
        "e.entity_id = order_items.{$productIdFieldName} AND e.entity_type_id = {$this->getProductEntityTypeId()}{$productTypes}"
    )
    ->group('e.entity_id')
    ->having('ordered_qty > 0');

To resolve the problem with the flat catalog, simply rewrite the model and modify this function by replacing the last part with:

if ($this->isEnabledFlat()) {
    $this->getSelect()->joinInner(
        array('e' => $this->getResource()->getFlatTableName()),
        "e.entity_id = order_items.{$productIdFieldName}{$productTypes}"
    );
}
else {
    $this->getSelect()
        ->joinInner(
            array('e' => $this->getProductEntityTableName()),
            "e.entity_id = order_items.{$productIdFieldName} AND e.entity_type_id = {$this->getProductEntityTypeId()}{$productTypes}"
        );
}

$this->getSelect()
    ->group('e.entity_id')
    ->having('ordered_qty > 0');

That should fix the problem.

Increase your sales! - Promotions rules in your Magento

Magento system, offers users an excellent tool for creating rules of special prices for multiply products at the same time. We have 2 types of rules: the first refers to a catalog of products, while the other to the contents of customers shopping cart. Let's look little bit closer at this first one.

In this example, we'll create a rule of reducing 50% of the price of each product in a specific category in our catalog.

Go to Promotions -> Catalog Price Rules -> Add New Rule

At the beginning we give the name of the rule, then we mark stores to take effect in (obviously, if we have more than 1) and select group of clients. Remember to include the start date and end date of promotion period, You can also enter a From/To Time to be more specific.

On the Conditions Tab, set a condition to define the category of products: if the product is equal category id 44 (Sacs enfants) then...

..then perform the action: apply a percentage discount of the original price by 50 (50%).
Accept a new rule by click on "Save & Apply"

From now on, prices of all products from category 'Sacs enfants' ( category_id = 44) will be reduced by 50%. Products will display the original price (crossed out) and promotion one (as a rule).

Please note, prices usually refer to the standard price of the product. So if the product is set to individual special price it will be superior, depending on how we set the condition in price rule.

Enjoy your sales!:)

Magento: reload color images for configurable product

Let's talk about one situation. We are in shop made in Magento.

We are on configurable product page. One of configurable attributes is color. Wouldn't it be good idea, after color is chosen show only images of this color? It can be... and it's not hard to achieve.

First we must do some preparations:

Create attribute "image_storing" type boolean and add it to your attribute sets. Can be limited only to simple products.

For each color of superproduct (configurable+simples) choose one simple product and set value to yes, also to this product upload images of this color.

Now create new module called "imageswitch" (or whatever you want, just remember to change it in the following code).

In it you must have a controller looking like this:

class Baobaz_Imageswitch_IndexController extends Mage_Core_Controller_Front_Action
{
    public function indexAction()
    {
        $prod_id  = (int) $this->getRequest()->getParam('prod_id');
        $color_value  = (int) $this->getRequest()->getParam('color_id');
        $product=Mage::getModel('catalog/product')->load($prod_id);
        if($color_value) {
            $allProducts = $product->getTypeInstance(true)->getUsedProducts(null, $product);      
            foreach ($allProducts as $prod) {
                if ($prod->getData('image_storing') && $prod->getColor()==$color_value) { // && $prod->isSaleable()
                    break;
                }
            }          
            $prod_full=Mage::getModel('catalog/product')->load($prod->getId());
            Mage::register('product', $prod_full);
        }
        else {
            Mage::register('product', $product);
        }
        $this->loadLayout();    
        $this->renderLayout();
    }
}

This controller will reload the whole media block, but for that we also need proper layout xml file

imageswitch.xml

<?xml version="1.0"?>
<layout version="0.1.0">
    <imageswitch_index_index>
        <reference name="root">
            <action method="setTemplate"><template>page/empty.phtml</template></action>
        </reference>
        <reference name="content">
            <block type="catalog/product_view_media" name="product.info.media" as="media" template="catalog/product/view/media.phtml" />
        </reference>
    </imageswitch_index_index>
</layout>

and a layout html file - page/empty.phtml

<!-- start content -->
    <?php echo $this->getChildHtml('content') ?>
<!-- end content -->

Then we need to add some observer to catalog/product/view.phtml so we can reload it when the value of color is changed (attribute76 is the id of select for attribute color, it's default id if we use standard Magento attribute, if changed, may need adjusting)

<script>
function runajax() {
    product_id=$('product_id').value
    color_id=$('attribute76').value;
   
    new Ajax.Updater('product_media_content', '<?php echo Mage::getBaseUrl(); ?>imageswitch/index/index/prod_id/'+product_id+'/color_id/'+color_id, { method: 'get', evalScripts: true });
}

if ($('attribute76')) {
    Event.observe('attribute76', 'change', runajax);  
}
</script>

and add in the same file id of block to be added by changing :

<div class="product-img-box">
    <?php echo $this->getChildHtml('media') ?>
</div>

<div class="product-img-box" id="product_media_content">
    <?php echo $this->getChildHtml('media') ?>
</div>

and if all is done properly, now you should be able to see the effect. enjoy!

Custom JavaScript form validators

Magento, thanks to Prototype framework, has nice set of JavaScript validators - so we can validate user input without reloading site. Of course, we cannot rely only on it, but it is good starting point - and for majority of users, it will have good look'n'feel.

But sometimes bulit-in validators are just not enough - for example, we can add custom fields for customer account, address etc. and we need some custom validation there. Magento together with Prototype gives us quick and easy way.

Little bit of theory - Prototype gives us Validation class. To check if form is valid, we have to call validate() method, which checks validation classes. I say classes, cause those are defined by css classes for input, for example:

<input name="someinput" class="required-entry" />  

will require to be not-empty. It would be nice to add our own classes to keep this process so simple as it is. So...

Step 1.

Create your own file, for example /skin/frontend/default/your_skin/js/myvalidation.js and add it to page.xml layout file.
Important note: it must be somewhere below adding script prototype/validation.js - usually, end of head block is good and safe place.
 

Step 2.

Editing myvalidation.js. Take a look on following code:

if(Validation) {        //   1.
    Validation.addAllThese([      //    2.
        [
            'validation-myown',       //     3.
            'Please insert proper word',     //    4.
            function(v,r){ return v.indexOf('valid')==-1?false:true }   //  5.
        ],
       [ ]    // 6.
    ])
}

Little explanations.

  1. We don't want to make any JavaScript error if for some reason validation script is not enabled, so we ensure it exists
  2. Adding a validators. Argument is array, each value of it is also array - so you can add multiple validators at once.
  3. This is css class that validator will be searching for, note that it must begin with validation-  ('-' sign at end) - otherwise it may not work as desired.
  4. This is error message displayed when validation is not passed.
  5. Finally, our most important function - validator itself.
  6. Next validators...

In this example validator function takes two arguments, but in fact usually first one is enough.
So first - called v here - is value of input at moment of validation
Second - called r here - can be useful in very custom validators - it is reference to validated object.
When validator function returns true, validation for field is passed, if false - opposite.

That's it. Quite simple if you will understand process ;)
 

Step 3. (optional)

We have nice error message - but what about case we need to translate it? Well, we can use Magento JavaScript class - Translate. Adding translations is quite simple, but has to be done from template level. We can use Jakub's module (blog.baobaz.com/en/blog/magento-translations-module):

<script type="text/javascript">
    Translator.add('Please insert proper word','<?php echo Mage::helper('translations')->__('Please insert proper word')?>');
</script>

Add this to template where you use your custom validators or create special block for it, so they can be easily reused.

Anything more on validators is just plain JavaScript and your needs :)

Customizing Magento Dataflow - import of custom data.

The flexibility of Magento Dataflow module lies in fact you can easily create your own adapters, parsers, mappers and apply them to your specific dataflow needs.

The basic case you may wonder how to do, is import of data for your custom module. Let's do this by example. Imagine you need to display on you e-shop list of stores, you have created custom module, table in database and datamodel part, all you need now is to populate this table with data you have within csv file.

Read the file

First you have to read the file. As you already know (if you read Magento Dataflow - Default Adapters [Part 2]) you can use dataflow/convert_adapter_io adapter for this.

<action type="dataflow/convert_adapter_io" method="load">
    <var name="type">file</var>
    <var name="path">var/import</var>
    <var name="filename"><![CDATA[stores.csv]]></var>
    <var name="format"><![CDATA[csv]]></var>
</action>

Parse the file content

Now that you have read the file content, you should parse it using dataflow/convert_parser_csv.

<action type="dataflow/convert_parser_csv" method="parse">
    <var name="delimiter"><![CDATA[,]]></var>
    <var name="enclose"><![CDATA["]]></var>
    <var name="fieldnames">true</var>
    <var name="store"><![CDATA[0]]></var>
    <var name="number_of_records">1</var>
    <var name="decimal_separator"><![CDATA[.]]></var>
</action>

Process rows of data

Now the custom part of this process. Within your custom module you have to create custom adapter that will create row in database for each processed row of parsed file. Within your module root directory create file ./Model/Convert/Adapter/Store.php of this content:

class Baobaz_Offer_Model_Convert_Adapter_Offer
    extends Mage_Dataflow_Model_Convert_Adapter_Abstract
{
    protected $_storeModel;

    public function load() {
      // you have to create this method, enforced by Mage_Dataflow_Model_Convert_Adapter_Interface
    }

    public function save() {
      // you have to create this method, enforced by Mage_Dataflow_Model_Convert_Adapter_Interface      
    }

    public function getStoreModel()
    {
        if (is_null($this->_storeModel)) {
            $storeModel = Mage::getModel('baobaz_store/store');
            $this->_storeModel = Mage::objects()->save($storeModel);
        }
        return Mage::objects()->load($this->_storeModel);
    }

    public function saveRow(array $importData)
    {
      $store = $this->getStoreModel();

      if (empty($importData['code'])) {
          $message = Mage::helper('catalog')->__('Skip import row, required field "%s" not defined', 'code');
          Mage::throwException($message);
      }
      else
      {
        $store->load($importData['code'],'code');
      }

      $store->setCode($importData['code']);
      $store->setName($importData['name']);

      $store->save();

      return true;

    }
}

Now when you have this file created you can modify a little bit the declaration of parser adding adapter and method variables: 

<action type="dataflow/convert_parser_csv" method="parse">
    <var name="delimiter"><![CDATA[,]]></var>
    <var name="enclose"><![CDATA["]]></var>
    <var name="fieldnames">true</var>
    <var name="store"><![CDATA[0]]></var>
    <var name="number_of_records">1</var>
    <var name="decimal_separator"><![CDATA[.]]></var>
    <var name="adapter">baobaz_store/convert_adapter_store</var>
    <var name="method">saveRow</var>
</action>

Having this done you should have your xml definition of custom dataflow profile looking like that:

<action type="dataflow/convert_adapter_io" method="load">
    <var name="type">file</var>
    <var name="path">var/import</var>
    <var name="filename"><![CDATA[stores.csv]]></var>
    <var name="format"><![CDATA[csv]]></var>
</action>
<action type="dataflow/convert_parser_csv" method="parse">
    <var name="delimiter"><![CDATA[,]]></var>
    <var name="enclose"><![CDATA["]]></var>
    <var name="fieldnames">true</var>
    <var name="store"><![CDATA[0]]></var>
    <var name="number_of_records">1</var>
    <var name="decimal_separator"><![CDATA[.]]></var>
    <var name="adapter">baobaz_store/convert_adapter_store</var>
    <var name="method">saveRow</var>
</action>

You can now enjoy your custom dataflow

Magento Backoffice (Admin Panel) Options - [Part 3]

In the previous part (Magento Backoffice (Admin Panel) Options - [Part 2]) we created a module and added some code to manage the module from "Admin Panel". A new menu entry is now responsible for modifications of the module settings. But Magento allows us to use a different approach.

Every module can contain a configuration file named system.xml. In this file we can define tabs and sections which will be later placed in System->Configuration, we define their content also. Data entered in the sections is stored in core_config_data table. Handling the data between the sections and the database in done by Magento, so it's a quite handy solution if we just need to put the data inside the database.

First, we need to create system.xml in module etc directory. The file should contain following definitions: what will be the tab for our module management, what sections it will contain and what is the content of each section. Our file is quite simple. First, the tabs:

<tabs>
    <settime>
        <label>Set Time</label>
        <sort_order>100</sort_order>
    </settime>
</tabs>

Every tab has its name, label which will be displayed, and number corresponding to the order of all tabs collection. Next we define sections, which can be compared to submenus of the tab:

<sections>
    <setit>
    </setit>
</sections>

And then we put inside sections their content:

<class>separator-top</class>

Section label:

<label>Set It!</label>

Name of the tab containing the section:

<tab>settime</tab>

Data type:

<frontend_type>text</frontend_type>

Sort order - important if there is more than one section within a tab:

<sort_order>40</sort_order>

Should the section be visible when we define default configuration:

<show_in_default>1</show_in_default>

Should the section be visible when we define configuration for a website:

<show_in_website>1</show_in_website>

Should the section be visible when we define configuration for a store:

<show_in_store>1</show_in_store>

Time for section content. Groups are containers for similar data fields:

<groups>
    <settingtime>
        <label>Set Time</label>
        <frontend_type>text</frontend_type>
        <sort_order>100</sort_order>
        <show_in_default>1</show_in_default>
        <show_in_website>1</show_in_website>
        <show_in_store>1</show_in_store>
        <fields>
            <time_format>
                <label>Time Format</label>
                <comment>string according to PHP date() argument</comment>
                <frontend_type>text</frontend_type>
                <sort_order>1</sort_order>
                <show_in_default>1</show_in_default>
                <show_in_website>1</show_in_website>
                <show_in_store>1</show_in_store>
            </time_format>                        
        </fields>
    </settingtime>
</groups>

So now system.xml looks like that:

<config>
    <tabs>
        <settime>
            <label>Set Time</label>
            <sort_order>100</sort_order>
        </settime>
    </tabs>
    <sections>
        <setit>
            <class>separator-top</class>
            <label>Set It!</label>
            <tab>settime</tab>
            <frontend_type>text</frontend_type>
            <sort_order>40</sort_order>
            <show_in_default>1</show_in_default>
            <show_in_website>1</show_in_website>
            <show_in_store>0</show_in_store>
            <groups>
                <settingtime>
                    <label>Set Time</label>
                    <frontend_type>text</frontend_type>
                    <sort_order>100</sort_order>
                    <show_in_default>1</show_in_default>
                    <show_in_website>1</show_in_website>
                    <show_in_store>1</show_in_store>
                    <fields>
                        <time_format>
                            <label>Time Format</label>
                            <comment>string according to PHP date() argument</comment>
                            <frontend_type>text</frontend_type>
                            <sort_order>1</sort_order>
                            <show_in_default>1</show_in_default>
                            <show_in_website>1</show_in_website>
                            <show_in_store>1</show_in_store>
                        </time_format>                        
                    </fields>
                </settingtime>
            </groups>
        </setit>
    </sections>
</config>

But we need something more to make it work - modification in config.xml. We need to add to it information about configuration resources that are related to our module.

<acl>
    <resources>
        <admin>
            <children>
                <system>
                    <children>
                        <config>
                            <children>
                                <setit>
                                    <title>Setit Section</title>
                                </setit>
                            </children>
                        </config>
                    </children>
                </system>
            </children>
        </admin>
    </resources>
</acl>

As you can see, we define path to our section. The path will be also relevant for saving or loading data from database, because it is used as an identifier. In our case data entered in field time_format wil have identifier setit/settingtime/time_format.

Magento will add the sections to permissions management in System->Permissions->Roles->Role Resources. Check this tab, our new sections should be listed there when you choose 'Custom'. If you see 'Access Denied' error when you click on 'Set It!' section, then go to System->Permissions->Roles, select Administrators and Role Resources. Change All to Custom, mark all checkboxes - be careful, because mistake in this step may cause inability to login to Admin Panel. Save, then go back and change Custom back to All and save again. Now you should have fully functional module management.

Here is a screenshot of final result in Magento back office:

Set it screenshot

Magento Dataflow - standard parsers and mapping values [part 4]

As promised in Magento Dataflow - Default Adapters [Part 2] today I will write about standard parsers in Magento DataFlow module and mapping values with mappers.

  1. Parser definition

    Parsers are responsible for transforming data from. Parser's interface Mage_Dataflow_Model_Convert_Parser_Interface defines two methods required in each parser: parse() and unparse(). Definition of parser within profile's xml can be as simple as:

    <action type="dataflow/convert_parser_serialize" method="parse" />

    Similar to adapter we define action tag with two attributes: type, which tells which class we want to use and this class's method we want to call. We can also call parser passing variables within action tag body as you will see below.

  2. Standard parsers

    Magento DataFlow includes few standard parsers which you can find in app/code/core/Dataflow/Model/Convert/Parser.

    The simplest of standard parsers is dataflow/convert_parser_serialize (Mage_Dataflow_Model_Convert_Parser_Serialize) which doesn't require any variables passed. It requires though that any of previous actions set data within profile's container. Method parse() unserialize data stored within profile's container and replace it with the result. Method unparse() do the opposite, so it serializes data stored within profile's container and replace it with the result.

    One of most often used standard parsers is dataflow/convert_parser_csv which allows transforming from (with method parse()) or to (with method unparse()) CSV file. Example of definition:

    <action type="dataflow/convert_parser_csv" method="parse">
        <var name="delimiter"><![CDATA[,]]></var>
        <var name="enclose"><![CDATA["]]></var>
        <var name="fieldnames">true</var>
        <var name="store"><![CDATA[0]]></var>
        <var name="decimal_separator"><![CDATA[.]]></var>
        <var name="adapter">catalog/convert_adapter_product</var>
        <var name="method">parse</var>
    </action>

    This parser requires that you call some io adapter prior to its execution (using for example dataflow/convert_adapter_io to read some csv file) if you want to call method parse. If you want to store data into CSV file you have to do both - call any action that will set data within profile's container prior to parser execution and call io adapter after parser execution to store data within file.

    Following variables will allow you to customize csv file parsing:

    • delimiter - defines delimiter used in csv file; defaults to comma (,) character
    • enclose - defines what character is used to enclose data values; defaults to empty character
    • escape - defines escape character for csv file; defaults to \\
    • decimal_separator - defines decimal separator sign
    • fieldnames - if set to true, it is assumed first row of csv file contains field names; if set to false map variable is used
    • map - defines fieldnames for files where first row doesn't contain fieldnames; to see how to define a map take a look at section of this article related to mapping values
    • adapter - tells which adapters method should be called on each row
    • method - tells which method of adapter should be called on each row; defaults to saveRow

    All variables defined within parser's action body are passed to the defined adapter, so if you need to pass something to it, you can simply set required variable within parser's action body.

    Last of standard parsers included within DataFlow module is dataflow/convert_parser_xml_excel (Mage_Dataflow_Model_Convert_Parser_Xml_Excel), which converts data from and to Excel xml file. Example of definition:

    <action type="dataflow/convert_parser_xml_excel" method="unparse">
        <var name="single_sheet"><![CDATA[products]]></var>
        <var name="fieldnames">true</var>
    </action>

    Use requirements are the same as for dataflow/convert_parser_csv.

    Following variables will allow you to customize csv file parsing:

    • fieldnames - if set to true, it is assumed first row of csv file contains field names; if set to false map variable is used
    • map - defines fieldnames for files where first row doesn't contain fieldnames
    • single_sheet - tells if parsed should be one sheet or all; should contain name of the sheet to be parsed
    • adapter - tells which adapters method should be called on each row
    • method - tells which method of adapter should be called on each row; defaults to saveRow
  3. Standard customer and product entity parsers

    For most commonly exchanged entities - customer and product - Magento provides also standard parsers: customer/convert_parser_customer (Mage_Customer_Model_Convert_Parser_Customer) and catalog/convert_parser_product (Mage_Catalog_Model_Convert_Parser_Product). Both inherit from Mage_Eav_Model_Convert_Adapter_Entity.

    Since standard adapter's load() methods calls result with array of solely entities' id values it is required to call parser's unparse method, if we want to get more related data. Both parsers take this arrays and for each entity parse its data variable content, ignore system fields, objects, non-attribute fields and create an associative array from the rest. Additionally product parser add to the array result of parsing product related stock item object, and customer parser - result of parsing shipping and billing addresses and information about newsletter subscription.

    Both entities parsers have deprecated parse() methods, since their function is now mostly done by parser actions with standard adapter methods called within parser's context. Example of product parser definition, parsing only products from selected store:

    <action type="catalog/convert_parser_product" method="unparse">
        <var name="store"><![CDATA[1]]></var>
    </action>

  4. Mapping values

    DataFlow module provides also a mapper concept - class with map() method that is responsible for mapping processed fields from one to another. The definition of mapper looks like that for example:

    <action type="dataflow/convert_mapper_column" method="map">
        <var name="map">
            <map name="category_ids"><![CDATA[categorie]]></map>
            <map name="sku"><![CDATA[reference]]></map>
            <map name="name"><![CDATA[titre]]></map>
            <map name="description"><![CDATA[description]]></map>
            <map name="price"><![CDATA[prix]]></map>
            <map name="special_price"><![CDATA[special_price]]></map>
            <map name="manufacturer"><![CDATA[marque]]></map>
        </var>
        <var name="_only_specified">true</var>
    </action>

    Again we have action tag with two attributes: type set as mapper class alias and method that is called to do the mapping. Mapper dataflow/convert_mapper_column is a standard mapper you can find in Magento DataFlow module within app/code/core/Dataflow/Model/Mapper/ folder, and its purpose is to map one array into another with changing the name and posibility to limit fields in result. Map's tag attribute name tells which field name should be replaced in new array by field named like the content of map's tag. If named field doesn't exist in source array, value for target's array field is set to null. Variable _only_specified tells if only fields specified in map definition should be in the resulting array.

This article would be the one that close standard features of DataFlow module and basics of its usage.

Magento orders: states and statuses

Magento orders have different states for following their process (billed, shipped, refunded...) in the order Workflow. These states are not visible in Magento back office. In fact, it is orders statuses that are displayed in back office and not their states.

Each state can have one or several statuses and a status can have only one state. By default, statuses and states have often the same name, that is why it is a little confusing. Here is the list of statuses and states available by default.

State code State name Status code Status name
new New pending Pending
pending_payment Pending Payment pending_paypal
pending_amazon_asp
Pending PayPal
Pending Amazon Simple Pay
processing Processing processing Processing
complete Complete complete Complete
closed Closed closed Closed
canceled Canceled canceled Canceled
holded On Hold holded On Hold

For adding new status to a state, you just need to declare it in config.xml file

<config>
    ...
    <global>
        <sales>
            <order>
                <!-- Statuses declaration -->
                <statuses>
                    <my_processing_status translate="label"><label>My Processing Status</label></my_processing_status>
                </statuses>
                <!-- Linking Status to a state -->
                <states>
                    <processing>
                        <statuses>
                            <my_processing_status />
                        </statuses>
                    </processing>
                </states>
            </order>
        </sales>  
    </global>
</config>

When we want to modify order status in some code, we have to be sure that current order state allows status wanted. It is possible to change both state and status with setState method

$order = Mage::getModel('sales/order')->loadByIncrementId('100000001');
$state = 'processing';
$status = 'my_processing_status';
$comment = 'Changing state to Processing and status to My Processing Status';
$isCustomerNotified = false;
$order->setState($state, $status, $comment, $isCustomerNotified);
$order->save();

$status can also take false value in order to only set order state, or true value for setting status by taking first status associated to this state.

You can now adjust as you wish your order workflow in Magento.

Magento Events

When it comes to extending Magento core functionality you have two options - override core classes or use event-driven architecture. The major disadvantage of first is that you can override class only once, so if you want to override it in multiple modules you are soon going to find yourself in dependency hell. Event-driven architecture allows you to keep loose coupling without losing the flexibility of extending Magento modules.

When you want to use Magento event-driven architecture you must know basically two things - how to dispatch an event and how to catch it.

Dispatching events

Within Magento you can dispatch an event as simple as by calling Mage::dispatchEvent(...) method, for example:

 Mage::dispatchEvent('custom_event', array('object'=>$this));

This methods accepts two parameters - event unique identifier and associative array of data that is set as Varien_Event_Observer object data, so in fact passed to event observers.

Catching events

Catching events is a little bit more complex than dispatching. You have to use existing custom module or create a new one. In the minimal case the module file tree should look like this:

  

Within config.xml you have to add a definition of event observer. Which of the main config.xml file sections (frontend, adminhtml) should contain this definition depends on the scope you want your observer to work on. Here is the example of definition:

<events>
      <custom_event> <!-- identifier of the event we want to catch -->
        <observers>
          <custom_event_handler> <!-- identifier of the event handler -->
            <type>model</type> <!-- class method call type; valid are model, object and singleton -->
            <class>baobazacustommodule/observer</class> <!-- observers class alias -->
            <method>customObserverAction</method>  <!-- observer's method to be called -->
            <args></args> <!-- additional arguments passed to observer -->
          </custom_event_handler>
        </observers>
      </custom_event>
</events>

Xml above should be self-explanatory. I will just explain that for type model and object are equal in behavior and mean that object of a class will be instantiated using Mage::getModel(...) method, and singleton means it will be instantiated using Mage::getSingleton(...) method.

Observer.php file should contain relevant observer class. There is no interface nor need to extend any class for observer classes. The method though should accept one parameter which is the object of Varien_Event_Observer class. This object is the link between dispatcher and event handler. It inherits from Varien_Object so has all required getters handled magically. For example:

class Baobaz_ACustomModule_Model_Observer
{
  public function customObserverAction(Varien_Event_Observer $observer)
  {
    $object = $observer->getEvent()->getObject(); // we are taking the item with 'object' key from array passed to dispatcher
    $object->doSomething();

    return $this;
}

Default events

Magento implements lot of events. You can find list of them here. What you may miss reading this list, and what was spotted on MageDev blog, Mage_Core_Model_Abstract by default dispatch some special events. Those are:
 

event identifier event parameters
model_save_before 'object'=>$this
{_eventPrefix}_save_before {_eventObject}=>$this
model_save_after 'object'=>$this
{_eventPrefix}_save_after {_eventObject}=>$this
model_delete_before 'object'=>$this
{_eventPrefix}_delete_before {_eventObject}=>$this
model_delete_after 'object'=>$this
{_eventPrefix}_delete_after {_eventObject}=>$this
model_load_after 'object'=>$this
{_eventPrefix}_load_after {_eventObject}=>$this

 

{_eventPrefix} means the value of $_eventPrefix variable and {_eventObject} means the value of $_eventObject variable. All classes inheriting from Mage_Core_Model_Abstract should override these variables to create specific events being dispatched. For example for catalog cagetory these variables take following values: $_eventPrefix = 'catalog_category';  $_eventObject = 'category';

How to use Magento Shipping Table Rates

With Magento you can set few kinds of shipping methods: flat rate, table rates or even real-time carrier rates from UPS, FedEx and DHL. You can also use free shipping discounts, that can be created for order amounts, or as part of specific marketing promotions.

To set shipping methods in backoffice go to System -> Configuration and choose from the left navigation "Shipping methods". When you want to use Table rates you can choose one of three conditions avalaible:

  • Weight vs. Destination
  • Price vs. Destination
  • Number of Items vs. Destination

You also need to create csv file for your table rates. You can first export one from magento to have a template. To do that you will need to change scope for your website in "Current Configuration Scope" (top left select box). Choose "Main website" for example. Then in Table rates you will be able to see "Export CSV" button.

Export table rates

Export and save tablerates.csv on your computer. The CSV file should looks like:

"Country","Region/State","Zip/Postal Code","Weight (and above)","Shipping Price"
"FRA","*","*","0.0000","11.0000
"FRA","*","*","10.0000","13.000"
"FRA","*","*","20.0000","15.0000"

Above lines define shipping rates for all regions in France. As you see weight condition is set as "from and above". So when order wieght is 0 and above (0-10 kg) shipping wil cost 11 euros, when its 10 and above (10 - 20 kg) shipping is 13 euros. When order weight is above 20 kg you will pay 15 euros for shipping. Even when it's 100 kg or 1000 kg you will still pay 15 euros! The problem with condition "from and above" is that you are unable to set maximum weight. So lets make these conditions work in "up to" way.
In "up to" way tablerates.csv like:

"Country","Region/State","Zip/Postal Code","Weight (and above)","Shipping Price"
"FRA","*","*","10.0000","13.000"
"FRA","*","*","20.0000","15.0000"

will define that for order which weight is up to 10 kg (0-10 kg) shipping cost is 13 euros. For orders up to 20 kg (10 - 20 kg) it's 15 euros. So the maximum weight for table rate is 20kg. Above 20kg you will have no table rate available.

To make table rates work that way function getRate() from Mage_Shipping_Model_Mysql4_Carrier_Tablerate needs to be overwriten. First we need to create new module under /code/local directory and configure it:

Magento module

<?xml version="1.0"?>
<config>
    <global>
        <models>
            <shipping_mysql4>
                <rewrite>
                    <carrier_tablerate>Baobaz_Shipping_Model_Mysql4_Carrier_Tablerate</carrier_tablerate>
                </rewrite>
            </shipping_mysql4>
        </models>
    </global>
</config>

 

Our module needs to be activated by creating file Boabaz_Shipping.xml in app/etc/modules directory:

<?xml version="1.0"?>
<config>
    <modules>
        <Baobaz_Shipping>
            <active>true</active>
            <codePool>local</codePool>
        </Baobaz_Shipping>
    </modules>
</config>

In new module create class Baobaz_Shipping_Model_Mysql4_Carrier_Tablerate that will extend core magento class Mage_Shipping_Model_Mysql4_Carrier_Tablerate.

class Baobaz_Shipping_Model_Mysql4_Carrier_Tablerate extends Mage_Shipping_Model_Mysql4_Carrier_Tablerate
{}

Then lets copy/paste getRate(Mage_Shipping_Model_Rate_Request $request) function from core class and change few last lines at the end of the function:

$select->where('condition_value<=?', $request->getData($conditionName));

$select->order('condition_value DESC');

to:

$select->where('condition_value>=?', $request->getData($conditionName));

$select->order('condition_value ASC');

That will make table rates conditions work in "up to" way.