Browsing articles in "Magento"
Mar 28, 2015

Magento bug – Checkout cart 500 error – Redirect loops

Magento checkout cart gives 500 error and redirect loops when there is a shopping cart rule with Category condition.

I found a bug in Magento which redirects shopping cart indefinitely causing it 500 internal server error. This can be a serious bug as customer will not able to shop if this happens. I noticed this happens when there is a shopping cart rule which have Category in conditions of the rule.

If total quantity equals or greater than 1 for a subselection of items in cart matching ALL of these conditions:
Category is 125

So for example you have a shopping cart rule where you want to give some discount or free product if at least one product is chosen from specific Category, this triggers the error in frontend shopping cart. Main reason here is Category condition. If you remove category condition then the error should go away. But if you want to keep the category condition and still want Magento to handle the shopping cart promotion rule, check the code changes below:

To solve this I copied below file to my local

and edited the function validate:

     * Validate a condition with the checking of the child value
     * @param Varien_Object $object
     * @return bool
    public function validate(Varien_Object $object)
        /** @var Mage_Catalog_Model_Product $product */
        $product = $object->getProduct();
        if (!($product instanceof Mage_Catalog_Model_Product)) {
            $product = Mage::getModel('catalog/product')->load($object->getProductId());

        $valid = parent::validate($object);

        /* Kalpesh commented whole block, as it causes redirect loop and Segmentation fault in apache
        if (!$valid && $product->getTypeId() == Mage_Catalog_Model_Product_Type_Configurable::TYPE_CODE) {
            $children = $object->getChildren();
            //$valid = $children && $this->validate($children[0]); //Kalpesh commented, issue....

        return $valid;

Hope this helps to some troubled souls!

Mar 28, 2015

Magento EE 1.14 – Broken category & product sitemap URLs

Magento EE 1.14 introduces a bug fix which apparently becomes a bug in our website. Magento EE Release Notes and Magento CE Release Notes lists this in it’s Bug Fixes:
Google Sitemap files now include the .html suffix for category and product URLs.

We don’t have .html suffix in our category and product URLs, so we were good before this fix. But after upgrading it to latest version all the category and product URLs were having “.” (dot) at the end in XML sitemap. This is because Magento allows admin to give a custom suffix for category and product URLs for sitemap, but hardcodes “.” regardless of there are values in the above config fields or not. This allows unnecessary dots in all the URLs which can lead to 404 pages.

Magento Category Product URL config

Magento team have used observer to observe the events sitemap_categories_generating_before and sitemap_products_generating_before to add the suffix in the following file and functions (Notice I have commented all lines in the functions):
(copy this file to app/code/local/Enterprise/Catalog/Model/Observer.php, you may have to create directories)

     * Add Seo suffix to category's URL if doesn't exists.
     * @param Varien_Event_Observer $observer
    public function addSeoSuffixToCategoryUrl(Varien_Event_Observer $observer)
        /*$seoSuffix = (string) Mage::app()->getStore()->getConfig(
        $this->_addSuffixToUrl($observer->getCollection()->getItems(), $seoSuffix);*/

     * Add Seo suffix to product's URL if doesn't exists.
     * @param Varien_Event_Observer $observer
    public function addSeoSuffixToProductUrl(Varien_Event_Observer $observer)
        /*$seoSuffix = (string) Mage::app()->getStore()->getConfig(
        $this->_addSuffixToUrl($observer->getCollection()->getItems(), $seoSuffix);*/

After commenting above function’s logic and generating the Google Sitemap again (Admin > Catalog > Google Sitemap) everything was normal (no dot and suffix in URLs)

Mar 23, 2015

Magento: Change canonical URL for particular category only

In Magento, if you want to change canonical URL for just one category or quite a few categories, and don’t want to affect rest of the canonical URLs then do the following.

Note that this is helpful when you already have canonical URL in the page and want to REPLACE it with new url. If you don’t have canonical URL at all then you might want to ignore the first action tag in the below code.

– Go to the category page you want to change canonical URL in Magento Admin
– Click the tab “Custom Design”
– In the Custom Layout Update textbox, paste this:

<reference name="head">
    <action method="removeItem" block="head">
    <action method="addLinkRel" translate="title">

Change and with your desired URLs and save the category.

Basically first action tag in the code removes old canonical URL and second action tag adds the canonical URL with the new value you specify.

You may also need to clear cache.


Mar 20, 2015

Magento bug: Incorrect sales order report during DST

Before 6 months I found a bug in Magento CE 1.9 and EE 1.13 (latest versions at that time) in Sales Order report calculation during Daylight Savings Time period. I reported it to Magento through their Bug Tracking ticket but after 6 months also there is no reply no progress on that issue. I provided all the details on how to reproduce it and also provided solution to fix the issue. The issue is not yet resolved in latest Magento versions (I have checked Enterprise Edition which is latest stable version now) so I decided to post it online so that other developers/clients who are experiencing same issue during DST (which have started) period can fix it and fetch correct numbers.

Ticket in Magento bug tracker (you would need to login to see):

Overview of issue:
Sales order grid data (Admin->Sales->Orders) for certain date range is not matching with the report sales order data (Admin->Reports->Sales->Orders). There is some difference in numbers which made me drill into the Magento source code. Upon further investigation I saw Zend_Date’s set method was used without 2nd argument which took the date in wrong format messing with the totals.

Steps to reproduce:
1. Login in Admin panel
2. Go to Reports->Sales->Orders screen
3. Filter orders for some date range which should fall in Daylight savings time.
4. Notice the totals which are shown are not 100% correct.

Expected Result:
The totals in Reports->Sales->Orders screen should match totals in Sales->Orders grid screen when downloading CSV from there. I have attached the issue in detail along with solution in the attached file.

Actual Result:
The totals in Reports->Sales->Orders screen is not coming correct when date range filter falls in daylight savings time.

Magento version affected:
It seems all CE and EE versions, I only checked CE 1.8, 1.9 and EE 1.13, 1.14

Files Affected:
app/code/core/Mage/Reports/Model/Mysql4/Report/Abstract.php (In older magento versions using Mysql4 instead of Resource)

Technical Details:
In the file app/code/core/Mage/Reports/Model/Resource/Report/Abstract.php
function: _getTZOffsetTransitions
line 418, $dateTimeObject->set($tr[‘time’]);

$dateTimeObject is object of Zend_Date() and expects parameter 2 for the date/time format

After changing this line:



$dateTimeObject->set($tr['time'], Varien_Date::DATETIME_INTERNAL_FORMAT);

the issue was fixed and the order totals were shown correctly in Reports->Sales->Order screen.

Important Note: After the above change it is required to re-build lifetime statistics of Orders to update database table sales_order_aggregated_created.

Make the change by copying the core file to your local so that future upgrade will not overwrite your fix.

Nov 7, 2014

Magento: Get real IP address behind a proxy

Get real IP address if your server or customer is behind a proxy network. Magento have function Mage::helper(‘core/http’)->getRemoteAddr(); to get client IP address, but it gives proxy IP address instead of real IP if there is proxy network in between. Below code checks and returns both real IP and proxy IP address if it founds any.

if (!empty($_SERVER['HTTP_CLIENT_IP'])) {
    echo $_SERVER['HTTP_CLIENT_IP'];
} else if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $ips = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    echo trim($ips[count($ips) - 1]); //real IP address behind proxy IP
    // echo $_SERVER['REMOTE_ADDR']; //proxy IP address
} else {
    echo $_SERVER['REMOTE_ADDR']; //no proxy found

Welcome to my Blog

Kalpesh MehtaHelping Magento developers in their day-to-day development problems since 2011. Most of the problems and solutions here are my own experiences while working on different projects. Enjoy the blog and don't forget to throw comments and likes/+1's/tweets on posts you like. Thanks for visiting!




Magento top 50 contributors

Magento top 50 contributors