6 Common Issues Magento 1.9 You May Find

6 Common Issues, Magento Problem

Even with the newest version of Magento 2 appears in the market, there are still so many people out there who keep using their Magento 1.9. Those people have their own reasons for that. Some of them may do not want to bother to migrate their website to Magento 2. The others may start from the lower Magento version and decided to upgrade their Magento to Magento 1.9 first before trying their hand on Magento 2. Some people don’t want to upgrade because extensions for Magento 2 are still quite limited.
However, even with all the benefits, you can get from Magento 1.9, it is not without any problem. In fact, there are several common problems that you can get from Magento 1.9. In this article, we tried to collect all the common problems in Magento 1.9 and write down solutions for each of them.
 
White Screen of Death
Like its name, all you can see is just a blank, white screen in this problem. This problem commonly happens when you upgrade your Magento from the lower version to Magento 1.9. Most of the time, the back end would be the only one affected. The front end or the store view will work correctly.

Magento white screen of death

There are several methods in which you can try to fix this problem. Most of the time, it is caused by an error in the Google checkout mode. To fix it, you need to go to /app/code/core/Mage/GoogleCheckout/etc. and then delete all the files except config.xml. Clear your cache and reload the page.
If that did not work, try the second method. Check if the app/design/adminhtml/ still has all its files or not. There is a case when people upgrade their Magento 1.8 to Magento 1.9.2.1, and some files were missing in the skin and template directories. To fix this problem, download Magento 1.9.2.1 package, unpack it, and copy everything in the app/design/adminhtml/default/default/..over your app/design/adminhtml/default/default/.. . Do not forget to do the same for skin/adminhtml too.
You may want to check the compatibility of your existing themes and plugins too. If they are not compatible, replace them with more compatible ones.
The last method is to do a complete installation or complete upgrade if all of them do not work. This is not really a solution, but still worth to try.
 
Order Confirmation E-mail not Send
This also one of the most common problems people got after they upgraded their Magento to Magento 1.9. Unlike the previous version of Magento, in Magento 1.9, the order confirmation email is not sent during check-out time anymore. It is sent with the cron instead.

To fix this problem, you must check whether your cron job is running properly or not. You can check the cron log at /var/log/cron. You also have to make sure your cron runs every 5 minutes. You can check it in your Crontab (server). If you find something like this (*/5 * * * * /public_html/cron.sh), that is mean your cron is already running for every 5 minutes.
If you do not want to use cron, then there is another method which you can try. With this method, all of your transactional E-mails would be sent directly.

//app/code/core/Mage/Sales/Model/Order.php Line#1356,1450
//$mailer->setQueue($emailQueue)->send(); Change To
$mailer->send();
app/design/frontend/base/default/template/checkout/success.phtml
//add following line Top success page for sending mail direct
// Start Send Emai Here……
$order = Mage::getModel(‘sales/order’);
$incrementId = Mage::getSingleton(‘checkout/session’)->getLastRealOrderId();
$order->loadByIncrementId($incrementId);
try{ $order->sendNewOrderEmail();}
catch (Exception $ex) { echo “Email Not Sent…”; }
$customer = Mage::getSingleton(‘customer/session’)->getCustomer();
$email = $customer->getEmail();//End Email Sending

If those are still not working for you, try to use the AOE Scheduler extension by Fabrizio Branca. This neat extension can help to monitor all your server’s scheduled tasks. You can either install this extension via Github or Magento connect.
AOE Scheduler can do more than just monitoring your server. You also can disable a job or make it run now. That is means you can manage the situation in a better way. There is no need for you to tinker with your terminal anymore or a developer to do it.
 
Customer Login Does not Work.

This probably one of the very first bugs which you will meet in Magento 1.9. This bug usually happens because the theme installed does not support variable form_key. To fix this problem, you must add a script :

<input type=”hidden” name=”form_key” value=”<?php echo Mage::getSingleton(‘core/session’)->getFormKey(); ?>” />

right after :

<ul class=”form-list”>

So, why form_key? Since the start, Magento’s backend always has this form key to protect itself from the XSS attack. Start from Magento 1.8, the key has entered the front end too. For the same reason, of course: to protect your website from submission from another website via your browser. That means it will prevent the attacker from adding other items in your shopping cart without permission while you browse other stuff with a different browser tab or complete your order in your place.
If that method still does not work for you, probably the problem lies in your Cookie path and Cookie domain. You can check it via Admin>System>configuration>General>Web>Session Cookie Management.
 
Update Cart is not Working.
In this error, the amount of item will not change even when your customer clicks the add item button or update cart button to add an item to their shopping cart.

The first thing you need to check to fix this issue is the file contained within your update cart button. You can find the file in the folder app/design/frontend/rwd/THEME NAME/template/checkout/cart.php
When you successfully opened it, search for script :

<button type=”submit” name=”update_cart_action” value=”update_qty” title=”<?php echo $this->__(‘Update Shopping Cart’); ?>” class=”button btn-update”><span><span><?php echo $this->__(‘Update Shopping Cart’); ?></span></span></button>

If the script looks exactly like that, your update cart button is already set up properly. Now your update cart is not a problem; the next place you need to check is your checkout form. It probably has an incorrect key. Now, look in your template for string ‘form key’. If it is there, it should look like this :

<?php echo $this->getBlockHtml(‘formkey’); ?>

You can either edit it or remove all of them and replace it with :

<input type=”hidden” name=”form_key” value=”<?php echo Mage::getSingleton(‘core/session’)->getFormKey(); ?>”/>

 
Static Block Display Issue
This problem may appear when you create multiple static blocks in Magento 1.9.2.0. The blocks will appear sporadically and show the wrong blocks instead of the correct ones. In some cases, the same blocks will appear twice. This problem happens because Magento uses names as its caching key info for CMS static blocks, where it suppose to use block ID instead. That is why those caches get mixed up.

There are few steps which you can try to fix this bug. First, you need to create a root path: /app/etc/modules/NameSpace_Modulename.xml.

xml version=”1.0″?>
<config>
<modules>
<NameSpace_Modulename>
<active>true</active>
<codePool>local</codePool>
<depends>
<Mage_Cms/>
</depends>
</NameSpace_Modulename>
</modules>
</config>

Next, create /app/code/local/NameSpace/Modulename/etc/config.xml

xml version=”1.0″?>
<config>
<modules>
<NameSpace_Modulename>
<version>1.0.0</version>
</NameSpace_Modulename>
</modules>
<global>
<blocks>
<cms>
<rewrite>
<block>NameSpace_Modulename_Block_Block</block>
<widget_block>NameSpace_Modulename_Block_Widget_Block</widget_block>
</rewrite>
</cms>
</blocks>
</global>
</config>

Then, create /app/code/local/NameSpace/Modulename/Block/Block.php

class NameSpace_Modulename_Block_Block extends Mage_Cms_Block_Block {
public function getCacheKeyInfo() {
if ($this->getBlockId())
{
return array(
Mage_Cms_Model_Block::CACHE_TAG,
Mage::app()->getStore()->getId(),
$this->getBlockId(),
(int) Mage::app()->getStore()->isCurrentlySecure()
);
} else {
return parent::getCacheKeyInfo();
}
}
}

Last, create /app/code/local/NameSpace/Modulename/Block/Widget/Block.php

class NameSpace_Modulename_Block_Widget_Block extends Mage_Cms_Block_Widget_Block {
/** * Storage for used widgets * * @var array */
static protected $_widgetUsageMap = array();
/** * Prepare block text and determine whether block output enabled or not
* Prevent blocks recursion if needed * * @return Mage_Cms_Block_Widget_Block */
protected function _beforeToHtml() {
parent::_beforeToHtml();
$blockId = $this->getData(‘block_id’);
$blockHash = get_class($this) . $blockId;
if (isset(self::$_widgetUsageMap[$blockHash])) {
return $this;
}
self::$_widgetUsageMap[$blockHash] = true;
if ($blockId) {
$block = Mage::getModel(‘cms/block’)
->setStoreId(Mage::app()->getStore()->getId())
->load($blockId);
if ($block->getIsActive()) {
/* @var $helper Mage_Cms_Helper_Data */
$helper = Mage::helper(‘cms’);
$processor = $helper->getBlockTemplateProcessor();
$this->setText($processor->filter($block->getContent()));
$this->addModelTags($block);
}
}
unset(self::$_widgetUsageMap[$blockHash]);
return $this;
}
/**
* Retrieve values of properties that unambiguously identify unique content
*
* @return array
*/
public function getCacheKeyInfo()
{
$result = parent::getCacheKeyInfo();
$blockId = $this->getBlockId();
if ($blockId) {
$result[] = $blockId;
}
return $result;
}
}

Your static block issue should be fixed now. If that did not work, you could try to upgrade your Magento to the 1.9.2.1 version (if you still use Magento 1.9.2.0. They already fixed this bug in that version).
 
Can not Login into Admin Panel
There are some reasons which can cause this issue. However, in the end, all of them are usually caused because Magento is not able to read or set the session cookie. Magento usually uses sessions to pass error messages between each page.

The causes of this problem are :

• Incorrect permission from your var/session, which prevented the session files from being saved.
• A mismatch between server time and local computer time. That is why you need to check whether your server time is correct or not.
• If you have a module or two installed in your system, it is possible to initiate a session too early, which prevents the correct session from being set.
• There is another person who modified your core code. Make sure you did not give your admin panel access to anybody besides your developer team.
• You have multiple cookie domains. The correct treatment for this error would depend on what caused it. One of the quickest ways to fix this issue is by creating a new virtual host in your system and re-installed your Magento. This was surely far better than editing your Magento core code.

Those are some common issues you may find in Magento 1.9. Of course, there is no guarantee that all of those methods will work perfectly for you, even if you have the same problem. If you have any problem with your Magento and do not know how to fix it, please contact us anytime. We will help you.