Customizing Magento by overwriting core-classes
There are several possibilities of overwriting single magento-methods or whole classes. Of course you could be just altering the core-classes themselves in a quick and dirty approach. however, you should avoid this practice under all circumstances, because it corrupts the update-facilities of your eCommerce-site. Once you are upgrading your magento-copy to a newer version, all your changes would get lost.
Luckily, overwriting native magento-classes is pretty straight-forward, and therefore there is no reason not to do it the right way.
In this example, we are overwriting the core method of the block-class “Onepage_Billing” of the Mage_Checkout-core module to add another default address. This is just an example to show how you actually add new functionality by inheriting from a Magento-coreclass and overwriting particular methods.
Extend Magento Core-Class
app/code/local/Test/Checkout/Block/Onepage/Billing.php
First we derive from the class that we actually want to overrule. In our example, we are simply overwriting the core Onepage_Billing-class of the Mage_Checkout-core-module with an inherited class called
Test_Checkout_Block_Onepage_Billing
, which declares and therfore overrules the method
getAddressesHtmlSelect
. In this method we can add and/or alter all the functionality that we actually need.
<?php
class Test_Checkout_Block_Onepage_Billing extends Mage_Checkout_Block_Onepage_Billing
{
public function getAddressesHtmlSelect($type)
{
if ($this->isCustomerLoggedIn()) {
$options = array();
foreach ($this->getCustomer()->getAddresses() as $address) {
$options[] = array(
'value' => $address->getId(),
'label' => $address->format('oneline')
);
}
$addressId = $this->getAddress()->getCustomerAddressId();
if (empty($addressId)) {
if ($type=='billing') {
$address = $this->getCustomer()->getPrimaryBillingAddress();
} else {
$address = $this->getCustomer()->getPrimaryShippingAddress();
}
if ($address) {
$addressId = $address->getId();
}
}
$select = $this->getLayout()->createBlock('core/html_select')
->setName($type.'_address_id')
->setId($type.'-address-select')
->setClass('address-select')
->setExtraParams('onchange="'.$type.'.newAddress(!this.value)"')
->setValue($addressId)
->setOptions($options);
return $select->getHtml();
}
return '';
}
}
Activate Module
app/etc/modules/Test_All.xml
Now it’s time to tell Magento that there is a module (in our example we have named it “Test”) which adds customized functionality to the Magento-core-functionality.
<?xml version="1.0"?>
<config>
<!-- Please add items in alphabetic order. -->
<modules>
<Test_Checkout>
<active>true</active>
<codePool>local</codePool>
</Test_Checkout>
</modules>
</config>
Actual Overwrite
app/code/local/Test/Checkout/etc/config.xml
Now this is where the Magento-rewrite-magic pops in. By providing a rewrite-directive in the Test_Checkout-config.xml, Magento’s default behaviour can be overruled for certain pages, and we can make sure that our derived class is being loaded instead of the core Checkout-module from Magento.
<?xml version="1.0"?>
<config>
<modules>
<Test_Checkout>
<version>0.1.0</version>
</Test_Checkout>
</modules>
<global>
<blocks>
<checkout>
<rewrite>
<onepage_billing>Test_Checkout_Block_Onepage_Billing</onepage_billing>
</rewrite>
</checkout>
</blocks>
</global>
</config>
Clear Cache
Whenever we are changing Magento-settings by adding or modifying the underlying xml-configuration-files, we have to empty the cache (residing at app/var/cache) in order to have the changes come into effect. So before going wild because your changes don’t show, rather empty Magento’s file-cache.
Popularity: 83% [?]
