Appreciating Your Chosen Web Host

Sometimes, you have small experiences that really make you appreciate your chosen web host. They leave you glad you spent the time doing your homework, testing out their support, features and generally ensuring everything is easy as possible with them. If it isn’t easy, then your job will be made all that much harder, unnecessarily.

I experienced such a feeling last week with a client who wanted to use their own web hosting. I had updated a small website to include a blog and gallery, both updateable by the client. This wouldn’t usually be an issue at all if using my own hosting – simply upload the files, add in my custom htaccess file for some mod rewriting goodness and away we go.

However, the host in question was 1and1.co.uk. Now, I’ve read some absolute horror stories about this company in the past – all such experiences seem very typical of a very large company, with their support teams based offshore.

So, back onto uploading the updated site in question. I had expressed initial concerns about the clients current 1and1 hosting package, noting that they’d most likely need to upgrade with 1and1, even though they were on an intermediate hosting package entitled the “1and1 Standard package”. I had also personally been forced to use their support about a year ago, which was hard work to say the least. Moving forward, I carried on and uploaded the site to 1and1’s servers and then visited site. Instant internal server error 500. Straight away I knew this was the hosting as I had previously given the client a link to a staging area on my preferred web host, that worked flawlessly. I’m aware 1and1 have some restrictive hosting on their basic packages (which seems to be inherant of such a large company, with thousands of customers in my experience), so I immediately headed towards to the .htaccess file (it’s essentially a variation of the HTML5 Bolierplate template with some of my own magic included, nothing out of the ordinary though) and renamed the htaccess file. Whallah – the site loaded, thus isolating the issue straight away. Great, I can inform 1and1 and find out what htaccess directives are allowed, it should be a run of the mill support request for any support department.

However, such a request to 1and1’s support department wasn’t easy in the least, in fact it was very challenging. After being on hold for roughly 10 minutes I was answered by one of their offshore support staff, who was quite difficult to understand, yet very polite. All I wanted to know was what, if any, features they support on custom htaccess files, on the clients current hosting package. Simple right?

This is the point things got a little messy unfortunately (yes, so early on in the telephone call). After putting me on hold for a further 5 minutes, the lady came back to telephone to tell me to “check my htaccess file for misconfigurations”. I  reiterated my previous statement (as there are no errors) and she told me to “please hold so she could check more things”, after saying it is easy to leave typos in htaccess access files (I guess that’s true, but it wasn’t the case here). After a further 5 minutes was told to go to a PHP script she had uploaded on the site, that displayed the output of a phpinfo call, that I should “check”.

Let’s take a step back here. I have isolated the error down to a server restriction on the 1and1 end. Their response has been to check my perfectly working htaccess file and to look at the output of a phpinfo call. It should be obvious to a person working on a technical support line that if I’m not getting an internal server error after removing a htaccess file, then the issue lies with the custom  htaccess file – it’s error isolation 101, surely? I explained this yet again to the operator who then suggested I “remove the htaccess file to prevent misconfigurations”. At this point I was getting a little impatient, decided to make my excuses and end the call – as we were getting no where. Granted, the lady was very polite on the phone, but my issue was not getting dealt with at all.

So after a 35 minute phone call, I was still left with a site, through no fault of my own, that wasn’t working. Not good for me, the client or my general sanity. I decided to call again, in order to get this resolved. I sometimes do this in the hope of speaking to a different, more informed member of staff. Sometimes I get lucky, others I don’t.

The second time I called I believe I spoke to someone a little more experienced, still in an offshore location though. I had to re explain my issue again (there were no recent calls logged, quite annoying …), I got equally as illogical replies as before. I was told one “solution” (said in the loosest sense here) was to go through each line of the htaccess one by one and keep commenting out lines until I tracked down the issue. The file is over 250 lines long – no thanks! That is not a solution at all in my books. At this point I gave up and decided to report back to client.

What was a little odd related to the emails that got sent the my client, about 20 minutes after my first call – my client forwarded these onto me. Here is a copy of paste (the gramatical errors are definately not mine!!!) of the email:

This is an update regarding your previous call, abou your site “**********” that is showing error 500. When there is an error with a .htaccess file, all pages of the website will display a 500 error indefinitely until the .htaccess file is corrected or removed. As little as a simple spelling mistake or syntax error will cause a 500 error. If the .htaccess file has been edited recently, replace the file with a backup. If no backup is available, try to undo the changes to the file if you can remember what has been altered. If those options are not feasible, you can try commenting lines one by one by placing a pound sign(#) at the beginning of the line to comment it out. Then try to access a page of the site. Continue to add the pound sign to more lines until the 500 error stops which should help you pinpoint which line needs to be corrected.

(email sent 14 October 2011 15:51:36 GMT, from support@1and1.co.uk)

I then got the following email from them re the second call:

This is an update regarding your call awhile ago, please refer to our FAQ link below for you to check the php settings on the server. You will need to create a phpinfo.php file using notepad and copy the code then paste it in your phpinfo.php file: How can I check the PHP settings on the server? http://faq.oneandone.co.uk/server/managed/8.html

(email sent 14 October 2011 16:42:00 GMT, from support@1and1.co.uk)

A little later, the following email came through, again a copy and paste:

Please upload the phpinfo file for you to get hold of the list of all settings allowed on our servers. With regard to the .htaccess file, sometimes the problem is with the syntax you encoded. In this regard, we highly advise that you make sure you key in the correct directives in order to prevent further issues.

(email sent 15 October 2011 06:23:00 GMT, from support@1and1.co.uk)

Great, yet more generic statements that don’t help. We have established several times now that the htaccess file was working correctly on the 1and1 hosting, that the issue was due to the 1and1 servers and that all I wanted to know was what, if any, htaccess directives are allowed/disallowed.

These emails are not helpful to anyone and needless to say, I won’t be chasing 1and1 up any further about this – it’s far too time consuming. Instead (and for the sake of my own sanity) I advised my client to transfer her site.

What is most concerning, apart from the fact 1and1 support have drastically failed to understand my rather basic issue, is that the replies are clearly written without appreciation for none technical people – everyone doesn’t know (read: probably doesn’t want to know) about the technical aspects of PHP settings and htaccess files.

I digres, all that is done now and the site has been uploaded to some quality web hosting where I can use a htaccess file. When I compare the poor level of customer service, the poor technical knowledge they demonstrated and the fact that a simple issue went on for much longer than it should have, to my current web host, the difference is night and day. With my preferred host, everything is so easy, if I need support I can get answered within a few minutes maximum.

At times like these and as a web developer, you really appreciate a good web host and things “just working”. However, the major difference between webhosts in my opinion, is flexibility and basic reason in my experience. Support teams/staff who take the time to understand your issue and have flexibility in solving your issue are easier to deal with. For instance, on my preferred hosts I was having a small issue with a php hashing framework, casuing my site to not work correctly. All that was required was quick email stating the problem and a response saying that they have added in a few commands to a custom php.ini file – the issue was essentially turned into a none issue – all sorted within 10 minutes (even though this issue was potentially more complicated than my little htaccess problem).

No drama, no drawn out telephone conversations to offshore locations – just my issue being solved within good time (thanks to Darren from tsohost for this by the way!). Another big benefit highlighted here is having knowledgeable people – when I stated my issue, they clearly know what they are talking about and clearly are not reading from prompt sheets – this alone, speeds up support requests significantly. I have personally come to the conclusion that the staff I was speaking to were using prompt sheets – purely due to the level of answer (or lack of answer) I was provided with.

Honestly, before you ever choose a webhost do yourself a huge favour. Do not look for the cheapest price. Do your research and test out your potential host first. Pay particular attention to quality and speed of support you receive. I couldn’t go through the above every time I needed a basic support question answering.

The above represent’s my own, personal opinion and is in accordance with my blog disclaimer. It does not represent any company I have ever or currently work for.

 

LATE NIGHT UPDATE! I was just about to go to bed and the following email came through, very unhelpful (although very polite) – I’m not sure why this issue is such a huge deal? How is a server error out of the scope of a technical support department????? Anyway: the email (copy and pasted again):

We deeply apologize for this inconvenience. Error 500 is misconfiguration of script in the .htaccess file. Please check it and we are no longer able to extend our help as this is already out of our scope of support. Again, we understand your frustration and we deeply apologize for the inconvenience.

(email sent 15 October 2011 21:14:00 GMT, from support@1and1.co.uk)

If anyone is interested, I can post by email response to the latter email. But as you’d imagine, I was less than pleased at the exceptionally poor level of service from 1and1 🙂