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.

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

}

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:

http://ma.gen.to/spp/ajax/co?id=460&pid=123

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.

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

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():

public function indexAction() {

    $p = $this->getRequest()->getParam('___SID');

    if($p) { return ''; }

}

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.

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 "<span style='background-color:lightgrey'>".$lbl . "</span>";

        echo "<br>";

}

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.