I recently upgraded a magento store and installed the Sage Pay Suite CE module from EbizMarks.

The following error came up twice during the testing of the module, once in the frontend and once in the admin.

Payment has failed, please reload checkout page and try again. Your card has not been charged

The error itself is triggered from the saveAfter method in the Ebizmarts_SagePaySuite_Model_Observer_Sales class and is called every time an order is saved.

The error on the frontend was caused by a javascript error. Adding the following to the top of the sagePaySuite_Checkout.js file corrected it

if(typeof sagePayIsMobile == 'undefined') {
    var sagePayIsMobile = function() {
        return (navigator.userAgent.match(/BlackBerry/i) ||
            navigator.userAgent.match(/webOS/i) ||
            navigator.userAgent.match(/Android/i) ||
            navigator.userAgent.match(/iPhone/i) ||
            navigator.userAgent.match(/iPod/i) ||
            navigator.userAgent.match(/iPad/i));
    }
}

The error in the admin was caused by a different extension being called when the order was saved. Normally the extension ensures that the method is not called when it is not needed and this is done by checking the route and the registry. If an extension saves the order these checks are not triggered so you will need to add in your own. To do that you will need add the following code to the action that is saving the error

Mage::register('skipSagePay', TRUE);

and then change the following line in the Ebizmarts/SagePaySuite/Model/Observer/Sales.php file

if( (Mage::app()->getRequest()->getControllerModule() == 'Mage_Api') || Mage::registry('current_shipment') || Mage::registry('sales_order') || Mage::registry('current_creditmemo') || Mage::registry('current_invoice') || ($order->getPayment()->getMethod() == 'sagepayrepeat') ){

to

if( (Mage::app()->getRequest()->getControllerModule() == 'Mage_Api') || Mage::registry('current_shipment') || Mage::registry('sales_order') || Mage::registry('current_creditmemo') || Mage::registry('current_invoice') || ($order->getPayment()->getMethod() == 'sagepayrepeat') || Mage::registry('skipSagePay')){

Often when working on a Magento site, there is a requirement to build custom functionality or implement new themes etc but to finish the job, the final step will be to perform some admin configuration.

This manual step can introduce the possiblity of human error if a step is missed or not performed exactly correctly.

Also if the configuration is to be applied multiple times across staging, pre production and final production then these risks increase.

The only sure way to make sure that the correct configuration is applied and also to provide a proper audit trail for configuration changes is to use Magento’s database migrations – install and upgrade scripts – to update the database programmatically with the required configuration changes.

To assist with this, there is a nice simple module you can find on Git Hub:

https://github.com/danslo/MigrationHelper

This module will automatically create the migration files for you which can be a real time saver.

I would always suggest you create your own custom namespaced configuration migration module that is purely to track these configuration changes.

Magento’s Template Path Hints feature can be super handy for working out which templates are in use, but logging into the Admin, navigating to System, Configuration, Developer, Debug, Change Store Scope, Change to Yes, Press Save, Reload is an arduous process. So much so that often it’s easier to just suss it out from the folder structure.

No more! Magicento has an entry in its menu to enable these at the click of a menu item.

There’s a couple of settings which need to be enabled (see below) but once set up, it works great.

Often you’ll have your site in maintenance mode, but obviously before you show your changes to the world you’ll want to check the site over.

The best way to set Magento into Maintenance Mode is to add a maintenance.flag file to the web root, and there’s a snippet of code in Magento’s index.php which handles this:

$maintenanceFile = 'maintenance.flag';

...

if (file_exists($maintenanceFile)) {
    include_once dirname(__FILE__) . '/errors/503.php';
    exit;
}

You’ll want to set this to also take your IP address into consideration, so just make the following amends and you’ll have added conditional maintenance mode:

$maintenanceFile = 'maintenance.flag';

...

if (file_exists($maintenanceFile) && $_SERVER['REMOTE_ADDR'] != "123.123.123.123") {
    if($_SERVER['REMOTE_ADDR'] == "123.123.123.123") {
        //Do nothing, but it's safer to check if it *is* your IP than *isn't*
    }
    else {
        include_once dirname(__FILE__) . '/errors/503.php';
        exit;
   }
}

Here at Edmonds Commerce when we are working on Magento design projects we use MyBalsamiq on-line mockup tool which We’ve found as one of the greatest in terms of support provided and especially for – live linking, which allows you to create live mockups in order to deliver the overall feel of navigation and User Experience to client more effectively. It has awesome sharing function as well – really easy to work and communicate ideas with clients, especially important in e-commerce projects where we like to test different approaches and see which could generate highest conversion rates.

However, nobody’s perfect as well as Balsamiq. They don’t have grid system integrated which makes mockup process messy as well as lacking some other essential forms and elements. The good news are that it’s possible to Upload existing grid templates and add them to your mockup, whether they are created by Balsamiq, other users or you! I was lucky enough to find well designed Twitter Bootstrap Grid Template mockup on Balsamiq on-line resource database so I could really save time and concentrate on more important tasks.

After mockup is downloaded in .bmml format – it can be easily uploaded on the system here:

Might be useful to create your own collection of most used elements and share with others! So Go ahead and create your own collection of most used elements to speed up your mock-up process and share with others. I will definitely create my own. See for updates from time to time.

Magento developers are no doubt familiar with the concept of defining a server environment variable MAGE_IS_DEVELOPER_MODE so that when running Magento locally it is always in developer mode but there is no chance of accidently deploying a live site in developer mode.

This little trick will allow you to use the same environment variable to also have the same effect when working with PrestaShop.

To explain – developer mode generally means that things like error messages and debugging information are displayed clearly in the browser which makes things much easier when you are developing, to see what is going wrong.

On a live site you want to keep error information hidden and generally display to the customer a more friendly error message screen that perhaps helps them find their way back to a functional section of the site or gives them information to contact the site owner directly for assistance.

Anyway, to put PrestaShop in debug mode locally but have no risk of deployign this to live you can alter the file: config/defines.inc.php

from

define('_PS_MODE_DEV_', false);

to

define('_PS_MODE_DEV_', isset($_SERVER['MAGE_IS_DEVELOPER_MODE']));

If you are having issues with mod rewrite apparently abandoning sections of variables after encoded hashes then this could be your solution.

The use case is particularly clear when using mod_rewrite in front of a search engine (such as Solr which I am really enjoying working with at the moment).

Imagine someone search for a partcode ABC#123

This gets encoded to search/abc%23123

Your rewritten search term will then be mangled by Apache and your search script will only actually see ABC. That is of course a problem and the solution is not really clear.

After a bit of searching around I found the solution is to add a B flag to your mod_rewrite rule so that mod_rewrite will escape these characters so that they are cleanly passed through.

For example:

RewriteRule ^(.*)search/(.*)$ advanced_search_result.php?keywords=$2 [L,B]

As part of our Magento SEO service, the first thing we do is to make sure there are no issues with the crawlability and general health of the clients web site.

Whilst working on the Google Webmaster Tools crawl errors for a client I noticed one specific and intruiging problem for which I couldn’t immediately see the reason, everything looked to be set up perfectly.

Certain URLs were getting 404 responses. The URL was being parsed by mod_rewrite but everything looked fine so why was apache giving a 404?

The problem turns out to be that the URLs contain escaped slashes (eg search/KTA-mb667k2%2F2g),

The problem is that Apache actually handles the escaped slash and helpfully converts it to a real slash. That then means that it is trying to look in a sub folder that does not exist and hence the 404.

Chances are you don’t want escaped slashes to really be thought of as real directory separating slashes, especially if you are using mod_rewrite.

The answer is a simple one liner to be added to your vhost.conf or httpd.conf.

AllowEncodedSlashes On

There is a problem in Magento that when you try to move a category by dragging it in the admin, it can cause the above error, whilst causing the rest of the site to slow down.

This is caused by the system trying to re-index every product within the space of a transaction.

An easy way to get round this is to switch the indexing mode from auto to manual and then move the categories.

You will still need to re-index the site, but this can be run on a cron when the site is quite.

If you have switched to Gnome Shell or Gnome 3 then you are no doubt making a lot of use of the overview and alt tab functionality to switch between your windows.

To make this easier (if you have a mouse with extra buttons) you can map your extra buttons to do these actions with a few simple tools.

Firstly you need to install xbindkeys and xdotool

sudo apt-get install xbindkeys xdotool

If you need to know your mouse buttons, try running this command:

xev | grep button

This will give you a window you can click on with your mouse and it will tell you which button you clicked.

Then finally you need to edit your xbindkeys configuration. This is my xbindkeys config:

#gnome shell button 8 to alt tab
"xdotool keydown alt key Tab; sleep 2; xdotool keyup alt"
release + b:8

#gnome shell button 9 to overview
"xdotool key Super_L"
release + b:9