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
app/code/core/Mage/SalesRule/Model/Rule/Condition/Product/Combine.php

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!

Magento 2 – Security Bug in Customer Address section (Resolved)

Magento 2 had a serious security bug where a website user can view and edit any customer’s address very easily. I reported this issue to Magento 2 team and they quickly fixed it and rolled it out in new beta version. All the beta versions up to 0.42.0-beta11 were affected, and from 0.74.0-beta1 it is fixed (I have not tested it yet).

Details about the bug and progress: https://github.com/magento/magento2/issues/1107

If you are using the affected Magento 2 versions for online demo or development please upgrade it. Though people use fake address in Demo stores, it is likely that some of them could have used their real address and details which can be accessible by anyone who knows about this bug.

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 1.14.0.0 Release Notes and Magento CE 1.9.0.0 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 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):
app/code/core/Enterprise/Catalog/Model/Observer.php
(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(

            Mage_Catalog_Helper_Category::XML_PATH_CATEGORY_URL_SUFFIX

        );

        $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(

            Mage_Catalog_Helper_Product::XML_PATH_PRODUCT_URL_SUFFIX

        );

        $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)

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">

        <item>link_rel</item>

        <name>http://loca.lho.st/old-canonical-url</name>

    </action>

    <action method="addLinkRel" translate="title">

        <rel>canonical</rel>

        <href>http://loca.lho.st/new-canonical-url</href>

    </action>

</reference>

Change http://loca.lho.st/old-canonical-url and http://loca.lho.st/new-canonical-url 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.

HTH!

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 1.14.1.0 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):
http://www.magentocommerce.com/bug-tracking/issue/index/id/254

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/Resource/Report/Abstract.php
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
http://framework.zend.com/manual/1.11/en/zend.date.basic.html#zend.date.simple.functions.set

After changing this line:

$dateTimeObject->set($tr['time']);

with

$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.