Apr 21 2010

PHP.ini Issues on Fat Cow Hosting

by andrew

You’ll have to bear with me – all of you who are interested in our story for the human aspect – I must descend into Geekdom Venting Land for a post here.

I’m a story teller, so if you just want to know how to fix shopping carts or other PHP web applications hosted by Fat Cow, skip down a few paragraphs.

Renee and I design and code websites together and between the two of us we’ve worked on everything from massive enterprise SharePoint driven collaborative web environments to mom-and-pop hand crafted simple sites and everything CMS or static in between. We’ve built and hacked and skinned and themed Drupal and WordPress and even peeked at Joomla, and we’ve done it across quite a range of hosting providers over the years:

  • Go Daddy (our personal favorite for a while now – a little too clicky but the best admin tools and excellent support)
  • Fat Cow (a pretty amazing deal with their unlimited plan)
  • 1 and 1 (so so… wouldn’t recommend necessarily, but tolerable)
  • iPowerWeb (sometimes a necessary evil)
  • HostPrince (I do NOT recommend them at all, but my experience with them is a couple years old now)
  • etc.

Implementing similar solutions across a variety of hosting platforms, I probably shouldn’t be surprised, but I am still caught somewhat off guard by the variety out there in default configurations and compliance (or lack thereof) with best practices that sometimes get taken for granted.

Case in point: Fat Cow’s default php.ini file is simply atrocious. I love their unlimited plan, and in my short experience with them so far their service is solid. But it’s like they installed PHP on the shared servers a few years ago and never touched the php.ini config. Ever.

Why is this a problem? Well, if you want to run anything like WordPress you’re going to need more than teh default memory_limit = 18M from like 1980 (ok, not really but you get the point). Go Daddy defaults theirs to 32M I think … or maybe it’s 64M now… And if you want to run anything like a shopping cart that requires php sessions – forget it (unless you start by uncommenting the session.save_path line and setting it to something useful – even though the session.save_handler = files … unreal! by default it tells php to use the filesystem to save sessions but doesn’t give it anywhere to put session files.).

This all finally came to head when I was trying to get eShop working in WordPress for http://ordercu.com

I knew eShop was probably NOT the culprit because we set it up and have it working great on http://foodbeautiful.com (hosted by Go Daddy).

What is funny (not) is that 2 months ago I had beaten my head against 3-4 different cart systems in WordPress for  http://indiefilmvideo.com (also hosted on Fat Cow) and never got to the bottom of why they wouldn’t work quite right. Well, now I know.

SO – the moral of the post is, here are the first tweaks you might want to make to your php.ini file if your host is Fat Cow. (If you don’t know where to find the php.ini file or how to modify it, you probably shouldn’t anyway). These are the changes I have made so far. In each case, just update the values being set.

  • memory_limit  = 64M
  • [uncomment – delete “;” – and set session.save_path to something like]:
  • session.save_path = “/home/users/web/b2634/moo.ACCOUNTNAME/cgi-bin/tmp”
    (make sure you pull YOUR actual home path from the front page of the Fat Cow control panel)
    (without this change php sessions will not work and you will get bizarre behavior in shopping carts where the things you add to the cart disappear on checkout or subsequent visits to the cart)
  • register_globals = Off
    (eeeek! can you believe that was still defaulted to On ???)

So, there you have it. Even with these basic tweaks WordPress will hum a LOT faster and you’ll actually be able to use shopping cart plugins for it. Imagine that.