Kalpesh Mehta

Blog

  • Magento: Zipcode + 4 tax calculation bug fix

    Magento bug fix for zipcode + 4 in tax calculation

    Tax Calculation in Magento has a bug where customer can escape paying tax if they enter zipcode + 4 digit in USA. This is because you import 5 digit zipcodes with their tax rates in Magento admin, so if customer inputs their zipcode in zipcode+4 format their zipcode will not match with the imported one. Importing 5-digit zipcode ending in wildcard (*) does not solve this issue either.

    Before this fix: If zipcode 90036 collects tax, 90036-1234 does NOT collect tax.

    You can fix this bug by adding below code in your custom module:

    config.xml
    {code}…




    Namespace_Module_Model_Tax_Resource_Calculation




    …{/code}

    Note that we are rewriting core logic of Tax Calculation. Now create folder structure in your custom module: app/code/local/Namespace/Module/Model/Tax/Resource/Calculation.php and copy below code:

    {code}getCountryId();
    $regionId = $request->getRegionId();
    $postcode = $request->getPostcode();

    //12 = california, 25 = iowa
    if($countryId == ‘US’ && in_array($regionId,array(12,25))) {
    $postcode = substr(trim($request->getPostcode()),0,5);
    $request->setPostcode($postcode);
    }
    return parent::_getRates($request);

    }

    }{/code}

    Above code will only take first 5 digits from the zipcode if the country is USA and state selected is either California or Iowa. You can change the states as per your requirement, to know what ID relates to different states you can look at the State/Province dropdown source code in checkout page.

  • 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:
    {code type=php}/**
    * 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;
    }{/code}

    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 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):
    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)
    {code type=php}/**
    * 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);*/
    }{/code}

    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:

    {code type=xml}

    link_rel
    http://loca.lho.st/old-canonical-url


    canonical
    http://loca.lho.st/new-canonical-url
    {/code}

    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:
    {code}$dateTimeObject->set($tr[‘time’]);{/code}
    with
    {code}$dateTimeObject->set($tr[‘time’], Varien_Date::DATETIME_INTERNAL_FORMAT);{/code}

    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.

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

    {code type=php}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
    }{/code}

  • Magento error: SCP 404: GET /spp/ajax/?___SID=Uco/?id=460&pid=123

    If you are using Magento extension Simple Configurable Product (SCP http://www.magentocommerce.com/magento-connect/simple-configurable-products.html), it gets dangerous sometimes when you have configured Special Prices or Tiered Pricing. It requests for prices via ajax after page is loaded. For some customers having old system and browser, this results in sending ___SID (session ID) along with GET request parameter, which causes double question mark in the URL.

    Ideally, the ajax URL should be:
    {code}http://ma.gen.to/spp/ajax/co?id=460&pid=123{/code}

    where it requests to module’s AjaxController and coAction() method, with parameters id (product ID) and pid (parent ID). This should go good without any issue.

    {code}http://ma.gen.to/spp/ajax/?___SID=Uco/?id=460&pid=123{/code}

    But, ___SID=U, which is used in the cache as a placeorder, also goes along with the parameters it creates a problem. As there are two “?” in the URL, Magento will try to see for AjaxController’s indexAction() because when you don’t have anything for action part in URL, it by defaults to indexAction of the controller.

    The problem doesn’t end in just a 404 error in error log, this also DISPLAYS whole 404 page just below the product price in product page. So, customer will get confused as there is a big 404 page inside the product page and configurable attributes like size, color and quantity box are pushed down. This may result in low sales when it appears frequently.

    The easiest way to fix this is to create an action indexAction() and check if you have ___SID as a parameter, then just ignore it.

    Add the following code in your module’s AjaxController.php file, just above the coAction():

    {code type=php}public function indexAction() {
    $p = $this->getRequest()->getParam(‘___SID’);
    if($p) { return ”; }
    }{/code}

    This will solve the weird 404 page that gets displayed in product page, but not the 404 error coming up in the logs. You need to remove ?___SID=U from the URL when it appears in the request to completely resolve the issue.

  • Magento: Get all attribute values (colors, sizes, etc..)

    Magento get all the attribute values you have in the store. Get all the colors and sizes values in Magento. Change the attribute name to whatever you want values for, in the below script.

    {code type=php}require_once(‘app/Mage.php’);
    umask(0);
    Mage::app(‘admin’);
    //set_time_limit(0);
    $attribute = Mage::getModel(‘eav/config’)->getAttribute(‘catalog_product’, ‘color’);
    $colors = array();
    foreach ($attribute->getSource()->getAllOptions(true) as $option) {
    $colors[] = $option[‘label’];
    }
    sort($colors);
    foreach($colors as $lbl) {
    echo ““.$lbl . ““;
    echo “
    “;
    }{/code}

    Replace color with any attribute you want to get values for. Above script also sorts the result set in alphabetic order to make it easy to view all values. If you don’t want to sort the values, just comment out the line which sorts it.

  • Magento: Get all category and subcategory products

    Magento get all category and subcategory products which are assigned to categories at different levels. Below script will show you all the categories, and all the associated product names under each of those categories.

    {code type=php}getTreeModel();
    $tree->load();

    $ids = $tree->getCollection()->getAllIds();

    if ($ids)
    {
    foreach ($ids as $id)
    {
    $cat = Mage::getModel(‘catalog/category’);
    $cat->load($id);
    if($cat->getLevel()==3 && $cat->getIsActive()==1)
    {
    $category1 = Mage::getModel(‘catalog/category’)->load($cat->getId());
    $products = Mage::getResourceModel(‘catalog/product_collection’)
    ->addAttributeToSelect(‘name’)
    ->addCategoryFilter($category1);
    echo ““.$cat->getName().”
    “;
    foreach ($products as $product) { //print_r($product->getData());exit;
    echo ”       ” . $product->getName() . ” – “. $product->getSku() . “
    “;
    }
    }
    }
    }
    ?>{/code}

    Note the line which checks category getLevel()==3, you can change this line to get different subcategory levels by adjusting it.
    For root category, getLevel() should be 1.
    For all the main/primary categories, getLevel() should be 2.
    For all the subcategories, getLevel() should be 3.
    For all the subsubcategories, getLevel() should be 4.
    and so on…

    Above script will get you all the category and subcategories products, products assigned to each and every categories of your store.