So like pretty much every web developer, I offer a service whereby the websites I build are hosted on my preferred webhost, on my VDS. A plethora or benefits are gained from this.
It’s quick – I don’t need to bugger around finding logins, calling support lines in other countries and other time wasting tasks. I know all the details I need to to create a new site and can get a new domain up and running in minutes, rather than hours sometimes.
The preferred host is reliable and compatible with the code I write. As I use the amazing Laravel 4 PHP Framework whenever possible I like to use PHP 5.4 as a minimum now. I know my chosen host offers this. The need to call up a host to plead them to make the leap of faith from PHP 4.0 to 5.4, or give me “elevated” access to upload files outside the web root (which is exactly what modern frameworks enforce, for good reason too, ahem).
I can also easily stage sites on a sub domain in a few seconds, again, great for letting clients preview sites before going live.
A big one now – if I host a website I know only myself (or a colleague) has direct access to the website. The amount of people from IT support teams who think they are web developers, breaking sites simply because they too look at computer screen is silly – I seem to be unlucky and always come across “IT managers” (said in the loosest sense possible …) who have an intimate knowledge of web development. So, when the latter type of plebs say deletes a htaccess file (because it looks suspicious) and then promptly informs my client that the “site has failed”, who then in turn moans at me (I’ll write a book one day about this type of thing) – is avoided. From my painful experience, the less people with direct access to a site, the better.
There is easy and instant access to make changes if needed. No silly FTP locks, clients not wanting to give out account login details, calling support lines to gain access to an externally hosted website at a later day, just changes made without any fuss – exactly what I prefer.
There are a few others, but for myself, as a developer anything to avoid any more pain in doing simple things like uploading a website is most welcome.
Whilst I don’t object to clients hosting their own website, hell, it’s their choice (even if they do opt. for the infamous cheapo type hosting that always fails at some point), hosting the sites I build is most preferred.
So, onto my reason for posting and finally updating this blog I never seen to use. Almost a month ago today I finished a website for a photographer. It was written using the excellent Laravel 4, all nicely namespaced etc. Everything working perfectly, as it should. The client had previously seen the site on my own hosting and was chuffed to pieces with the result. All good so far!
The only issue was that the client had their mind set on using their own web host, who were not really a host anyway, in the traditional sense of the term anyway. In fact, they were an IT company that sold managed IT services to companies. From what I gauged about their setup, they essentially had a VDS with one of the bigger well know webhosts. My client was not aware of this of course and assumed they hosted his site directly.
The site in questions was very large due to my client having hundreds of very high resolution images and the fact that Laravel 4 has lots of files anyway, the final file size came to ~2.2 GB. The correct way to upload sites like this (read: any website) is via SSH and uploading a single archive. So I went about my normal business, create a compressed tar file on my local computer, upload it via SCP to remote sever …. wait, no SSH access …. anywhere!?!?!?!?! So, a call to the “hosting company” was in order. The customer also wanted a backup of their current website, again, ~1.5GB in size. SSH is required here, just as it is required when deploying something like Magento Ecommerce.
The first call, after holding for 15 minutes I spoke to chap who said he couldn’t discuss the account with me as I wasn’t the account holder. Fair enough, a quick email to my client. A good week and a half passes before I get a response out my client, at least I know have permission to speak to them about the account. Another 10 minutes on hold this time and am speaking to a support person about the account. It turned out the company is question had completely disabled SSH. As I was getting no where with the current person I asked to speak to manager, who interestingly couldn’t call me back for a couple of days??? When I did finally receive a callback they said they were subjected to a denial of service attack and will not be enabling SSH again.
After explaining my situation I was shocked by the response I received. Apparently they had an “Ajax web based file manager” (posh eh?) for me to use. Yep, that will be tons of fun uploading gigabytes of data directly through a web browser. Personally I don’t even regard that suggestion as a solution at all.
After several more days of buggering around and finally giving up I requested FTP access – note there was no access to a control panel here, everything needed to go through the company in question. Mint!
Even though it will take an age to upload so many files via FTP, at least the site could go live. Everything started awfully – the details they provided kicked me out immediately. It turned out I had to get my IP address (which happened to be dynamic) white listed on their firewall. Yes, no FTP access unless I raised a support ticket.
As this was taking a lot longer than usual I had to schedule the job in for a week down the line as other jobs were backing up unfortunately. I had now had to raise yet another ticket to whitelist my IP. I told them this was frankly silly – I’ve never come across a host that does this. Their response you ask? “We offer professional level hosting that is very secure. We do not see customers with dynamic IP addresses as suitable for using the service …”. Wtf! So now I apparently need a fixed IP before I can use FTP. Insane, yet annoying.
So, after even more buggering around I finally get access and can see the client’s old website. I quickly check the PHP version and exactly what is enabled on the server, as Laravel 4 requires PHP 5.3.7 or above and MCrypt . I actually laughed out loud when the output of phpinfo() appeared. I had PHP 4.4 to work with on the server. Seriously!?!?!!? 4.4 is very old according to Wikipedia and was originally released on 11/07/2005.
So, another call and long drawn out conversation with the host, who knew me by name now. I asked a very simple question – “the site I have build requires PHP 5.3.7 or above, can you please upgrade this for me” (hell, if they gave me access I could upgrade it myself pretty quickly). Of course I couldn’t get a response there and then, as a manager needed to call me back. This time I received a email reply, 3 days later. “An upgrade to PHP affect all other customers on the same server and so is not possible. We can help with moving the site if this does not suit you”. Well, firstly they are completely correct – that doesn’t suit me. PHP 4.4 != PHP 5.3.7. At this point I decided to pass all information onto my client and let them make the decision, as I wasn’t getting anywhere unfortunately. The site remains in my staging area, not yet live 🙂
Sagas like this really do highlight how much time can be wasted. The fact I didn’t have control of the website hosting led to many wasted hours. In the future I’m thinking about adding a flat fee on for clients who insist on using their own hosts – to guard against situations like the one I experienced.