Tuesday 13 December 2011

Traumatic experience with Hostgator support

Wow, I just have spent a week trying to get favicons working on my wordpress multisite installation! Getting them working in my dev environment was quite easy (after getting apache set up okay), just had to read up about rewrite maps in apache and nginx. The problem was with my webhost, Hostgator.

First problem was after I had got favicons working correctly in dev site, I messaged Hostgator and asked them to set up a rewrite map. I had read here: Question regarding rewritemaps and shared hosting (I can modrewrite) that Hostgator said they did support rewrite maps. However, when I sent my request to them, they said they didn't support rewrite maps.

Not too much of a problem, I just re-wrote the map using SetEnvIf. A bit more work for the server on every request though. This worked, but I found that requests for favicon.ico were being replied to with no content. After doing some debugging, I could only conclude that this was a problem with Hostgator's server setup.

So I contacted them again, they said there was no problem or configuration issue with their server, the problem must be with my .htaccess. They don't offer a service of customising .htaccess files, so I'd have to find out what the problem was myself.

So I made a test case and sent the info to them. The rewrite rule I was using was

RewriteRule ^/files/ wp-content/favicon.ico [L]

They replied to say

I believe you'll need to rework the rule to direct files to wp-content and not a full path.

So, according to Hostgator it is only possible to rewrite to a directory, not a file?!?

I rewrote the rule as follows:

RewriteRule ^files/(.*) wp-content/$1 [L]

It's still a full path, but this time they seemed to see sense and actually investigated the issue. It turns out that they have a rewrite rule that rewrites any request for a non-existent favicon.ico file to an empty one. Since their rewrite rule is evaluated before mine, it sees that /files/favicon.ico does not exist, and rewrites it to the blank file.

Hostgator then said that they could solve this using symlinks. I replied that I didn't think that was possible due to the way the site was structured (and gave them the details). They said they could do it anyway, so I asked them to go ahead. Then, of course, they replied to say actually they can't do it due to the structure of the site.

Eventually I managed to get from them the directive they are using to rewrite the favicon.ico requests. It took me two requests though. It seems that the Hostgator support team is full of Linux sysadmins rather than anyone who's ever used apache before. With the details of the directive they were using it was immediately obvious what a simple work-around would be.

However, I first tried to add their favicon rewriting directive to my own apache config. I spent quite a bit of this morning trying to get it work, but just couldn't. It seems that either I am doing something wrong, or my apache is buggy / misconfigured so that rewrites are always relative to the document root, even when using an absolute path. So I posted on the Ubuntu forums to try and get some help with that.

Despite not getting Hostgator's favicon rewrite rule working on my dev site, I made the quick fix on the live server, and the favicons are now working properly there. The simple fix was just to create files/favicon.ico. Hostgator's rule will see the file exists, and so not rewrite it. Then my rewrite rule will see that the url matches ^/files/ and rewrite it to the correct location for that blog - the actual files/favicon.ico is never served.

Also today I made a cake, played with making custom apertures, and wrote a bit of a photo tips article.

No comments: