I recently built a Drupal site for a small (individual) client who wanted to host the site on a Network Solutions basic Web hosting plan. This made sense for him, because he had registered several domains with them. He wanted to keep things simple, which is always my goal too. We weren’t anticipating tremendous traffic, etc., and ongoing costs were a consideration, so this conservative approach made sense.
Starting, and Ending, with Network Solutions
I had never used Network Solutions before, but thought I had heard generally good things about it. I double-checked what came with the basic hosting plan, and everything looked fine.
Then the day came when I actually tried to implement it…the blank home page with three ‘blocks’ took more than thirty seconds to load, and any admin screens simply timed out. After some time trying to make this work so I could accomodate my client, I came to the shocking realization that Network Solutions was running PHP code as CGI scripts!
I haven’t programmed CGI scripts since my days of programming Perl, circa 1997, and I have never encountered PHP running this way. And not only didn’t I recall any mention of this in Network Solutions’ sales material, but the way the server was set up seemed specifically designed to disguise this fact.
Given how bizarre this configuration was, I think that hiding this from customers borders on bait and switch. The hosting was fundamentally unusable, and I had lost all confidence forever in Network Solutions. Fortunately, Network Solutions did the right thing and gave my client a refund immediately.
Finding a New Host
It had been a while since I had evaluated commodity hosting plans, so I decided to take a fresh look at current offerings.
I was reminded that reading reviews of particular hosting companies is similar to reading reviews for anything on Amazon.com: opinions can vary widely, and there is a fair amount of review spam. For every hosting company, you will find people that swear by it, and people that swear at it. So, I tried to take it all with grain of salt and tried to get a general sense of the typical experience with each host.
Basically, I wasn’t looking for a company with a flawless customer service record–none exists. This type of business has low margins, and there is only so much you can reasonably expect from any of these plans, particularly when it comes to support. You will hear horror stories about any host, but ultimately, you don’t know the level of expertise of the people making the complaints or their level of patience.
Staring again with AN Hosting
So, when I completed my basic research, I decided to take a chance on a host I had never used before: AN Hosting. In a number of Drupal related forums, I had read consistently positive reviews extending back a number of years, and it looked like they basically had their act together.
I saw that AN Hosting was owned by Midphase, which I had some experience with through another client. That client had his own mixed opinions about Midphase, but when I had worked with them, I had no major problems. Also, my sense is that Midphase is one of the “big boys” so this gave me confidence in the overall stability of AN Hosting.
Now, as I mentioned, this is my first experience with AN Hosting, and I launched the site just a few weeks ago, but so far, so good. Basically, AN Hosting is everything that I think you can hope for in a commodity host. It has all the usual trappings, such as cPanel, Fantastico, etc., and the performance has been consistently good. (With ‘normal’ caching and all compression and optimization in Drupal turned on, the site is pretty snappy.)
I had a few questions about their configuration that I emailed to AN Hosting support and was quite surprised to get a response within a few hours, both times.
So for me, AN Hosting has made a very positive first impression.
A Few Quirks
Another commonality I have found with commodity hosts is that they all seem to have a few quirks that can cause a little confusion when you first encounter them. AN Hosting was no exception.
From my previous experience with Midphase, I knew to expect one quirk: the server environment is configured so that it won’t execute scripts with permissions set above 755. This is not really documented at Midphase (at least, not when I used them previously) and I don’t think it is well documented at AN Hosting either. And if you set your permissions too high, the symptoms are fairly cryptic.
If you are like me, and set permissions pretty liberally (775) during development, you may see the following in your Apache error logs:
SoftException in Application.cpp:252:
…which will indicate that your permissions are set too high.
More puzzling to me is that AN Hosting seems to ignore overrides to php.ini values within .htaccess files. It does allow .htaccess overrides in general, as the rewrite rules for ‘clean URLs’ work. But when I tried to include the following in my .htaccess file, it wouldn’t take:
<IfModule mod_php5.c> php_value max_execution_time 1000 php_value max_input_time 1000 php_value post_max_size 50M php_value upload_max_filesize 50M</IfModule>
I didn’t want to mess with ini_set() commands in the sites/default/settings.php file, because I can never remember which values can be overridden that way, and which can’t, because by the time PHP scripts start executing, some values are already set, being used and can’t be changed.
Drupal itself uses similar .htaccess directives (as well as ini_set() in sites/default/settings.php) to do such things as make sure ‘magic quotes’ are turned off.
The solution seemed strange to me: put a custom php.ini file in the Drupal root directory with the values I wanted. I was skeptical of this, because my understanding is that unlike .htaccess files, php.ini files deployed in this way only effect the containing directory itself, and not any directories beneath it, yet with AN Hosting, this seemed to work on all directories, just like a .htaccess file would.
Which begs the question, why do they do this? For a host that claims they are ‘optimized’ for Drupal, WordPress and similar software, this seems to make things pretty inconvenient. My Drupal .htaccess file, which I can normally mostly ignore, only seems to partially work, and where it doesn’t, I have to add a php.ini file with some of the settings in my .htaccess file.
I assume there is an explanation for this–one that is at least logical and possibly even good, and the fact that I don’t see it may say something about where my expertise ends. But to my mind, this seems to add an extra layer of complication to all involved, and my even possibly be less secure.
Remember, that you have to make sure that the php.ini file that you add not only includes your customizations, but also matches what the default Drupal installation normally sets in its .htaccess file so you don’t override those settings. If for example, you accidentally deploy a php.ini file with register_globals or magic_quotes_gpc on, Drupal will not behave as expected, and may be less secure.
But otherwise, AN Hosting has been pretty smooth sailing, and I would definitely use them again.