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

If you pull down a Magento site to a local machine, and change the database core_config table to point to the local machine, and it appears to work fine until you try to login to the site admin, there can be many issues.

One of the most common ones though is not having a period (dot) in the host name – e.g. localhost/admin or martyn-desktop/admin – if you don’t have the period, the cookies don’t work properly and you end up in a login loop.

To fix it, make sure your machine is accessible via a domain with a period – e.g. martyn-desktop.local – by either editing your hosts file (/etc/hosts) or check your router – it possibly already adds a domain name like .config and set your path in core_config to the same.

Percona is a performance optimised fork of MySQL that has gained a lot of traction in the Magento-sphere as webmasters and sysadmins alike look to squeeze the most performance out of their hardware.

If you read the Magento performance whitepaper then you will see they mention Percona DB there.

To install Percona on a standard CentOS release 6.2 (Final) server you would need to run the following commands:

First set up the repo:

rpm -Uhv http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm

This should give you output like this:

Retrieving http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm
Preparing...                ########################################### [100%]
   1:percona-release        ########################################### [100%]

Then installing should be a simple case of running:

yum install Percona-Server-client-55 Percona-Server-server-55

However I found that this generated the following error:

Error: Percona-XtraDB-Cluster-client conflicts with Percona-Server-client-55

The problem is because MySQL is already installed and needs to be removed. You can do this with this command:

yum remove mysql*

At which point running the install should work smoothly.

If you are scratching your head trying to figure out why you keep getting MySQL server gone away error messages despite the fact you have bumped up all the timeout etc configurations to high values then this could be your solution.

MySQL will also give you this error if you try to send a packet that is larger than the packet size defined. We had an application that was using MariaDB which has a default max allowed packet of 16M by default.

The application in question was sending large amounts of data to be stored and so the solution to the gone away issues was simply to increase the max_allowed_packet configuration in my.cnf, restart the mysql daemon and the problems are sorted.

If you use Netbeans then you have no doubt seen the red wavy underline that pops under lines that have errors.

Unfortunatley if your errors relate to punctuation, eg concatenation full stops, then the red wavy line can actually obscure these making finding and fixing the error tricky.

An nice alternative is to set Netbeans to use a red strikethrough instead of the wavy line. This is just as visilble but does not obscure punctuation in any way making finding and fixing the error a lot easier.

To change this simply go to Tools-Options-Fonts & Colors

Then Set Language to All Languages

Then select Error in the category drop down

Simply change the Effects: drop down from Wave Underlined line to Strike Through

Found this great article on writing bash scripts defensively. Glad to say most of the advice we are already following with our bash scripts however there are a couple of new things I intend to roll in on Monday.

Recommended reading for anyone scripting in Bash.

http://www.davidpashley.com/articles/writing-robust-shell-scripts.html

If you are building something that is opening a terminal, perhaps a fancy URL handler or something similar but there are errors causing the terminal to instantly close, then this is the solution for you.

It’s actually really simple!

Create a new profile

Select the “Title and Command” tab

at the bottom there is an option “when command exits”

You can switch this to “Hold Terminal Open” which will keep the terminal open so you can see the error message and then fix it

You need to add the following flag to your gnome-terminal launcher:

gnome_terminal --window-with-profile={profile_name}

Beautiful!

When migrating one server to another you often hit bumps in the road. Todays was transferring a database from one server to another.

During this standard procedure I found that the restored database was missing a few tables. Irritating as Magento doesn’t like missing tables.

Digging down into the backup and extracting the first missing table I was able to replicate the error which came out as
1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE

I eventually found out that some versions of mysql 5.1 export a dump file that contains mysql5.1 specific features and loading the file into mysql 5.0 will not work.

The solution is a little frustrating but if you run the command with the –compatible=mysql40 switch, the dump file extracts fine :-
mysqldump --compatible=mysql40
Don’t ask me why there’s no –compatible=mysql50 flag.

Today I was working on an oscommerce site and took a backup of their database, created the usual details from their config file on my local mysql and the above error came up (with admin@localhost for what it’s worth).

Upon investigation, a trigger had been created on the database whilst logged in via a different user than the user specified in the config file.

There’s actually a few solutions depending on your needs :-
Ensure the user (something@somewhere) is created on your new database installation
Delete the trigger (for instance if testing locally and you know it’s not needed)
Edit the DB dump file, find the definition of the trigger and change it to the configured user.

If you are struggling with a weird bug with DomPDF, something about it trying to connect to a postgres database..

well here is the solution that will get you up and running:

open the file and make the init method just return false

class Page_Cache {
    const DB_USER = "dompdf_page_cache";
    const DB_PASS = "some meaningful password";
    const DB_NAME = "dompdf_page_cache";

    static private $__connection = null;

    function init() {
        return false;
        if (is_null(self::$__connection)) {
            $con_str = "host=" . DB_HOST .
                    " dbname=" . self::DB_NAME .
                    " user=" . self::DB_USER .
                    " password=" . self::DB_PASS;

            if (!self::$__connection = pg_connect($con_str))
                throw new Exception("Database connection failed.");
        }
    }

Not sure really why this is trying to do this, obviously some kind of hard coded postgres caching system but anyway this fixed it.