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

I knew eShop was probably NOT the culprit because we set it up and have it working great on (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 (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.

    26 Responses to “PHP.ini Issues on Fat Cow Hosting”

    • Dad Says:

      thanks for the hints, now I can get back to work

    • Steven Howatt Says:

      haha – You amaze me. Plenty of stuff out there to know, it seems.

    • Joanne Says:

      Thank you! We were having some issues with Fatcow & sessions. I thought it was on our end. Just fixed the php.ini file & all is well now.

    • andrew Says:

      Yay! Thanks for letting me know – so glad it helped someone else. I remember the frustration when I was banging my head on it. All the best!

    • Mark Says:

      I don’t know how many times I can say “thank you” for this bit of info. I thought I was going to have to give my client his money back if I did not find this answer.Of all the forums and blogs I have been to this was the only one that lead me to the exact solution. I am about to go to the wp e-commerce forum now and post a link to this answer for all that have been wondering.
      THANK YOU!

    • andrew Says:

      Once is plenty 🙂 Sincere thanks for letting me know. YOU’RE WELCOME!!!

    • Steve Says:

      Amazing. I spent a whole day trying to fix this issue!!! Thanks a lot Andrew

    • andrew Says:

      Sure thing! I totally know that frustration. Happy to help.

    • StevenH Says:

      My company has 2 networks running both in house and VPN servers. I’ve just started using Fatcow as on offsite network and your post fastracked me to fixing the thing.

      Cheers and Thanks for this ***** post

    • andrew Says:

      Fantastic! Thanks for chiming in!

    • Maryann Says:

      Hi Andrew,

      I went in and changed the php.ini file for IPage hosting and it appears to be working now as well. I just changed the memory limit from 32 to 64 because the session.save_path was not commented out. However, I noticed this note: NOTE: If you are using the subdirectory option for storing session files
      ; (see session.save_path above), then garbage collection does *not*
      ; happen automatically. You will need to do your own garbage
      ; collection through a shell script, cron entry, or some other method.
      ; For example, the following script would is the equivalent of
      ; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
      ; cd /path/to/sessions; find -cmin +24 | xargs rm

      Did you create a separate script to delete the “garbage” sessions? I noticed in the /cgi-bin/tmp folder there are a lot of sessions just from testing it today.

      Thanks for your help!!

    • andrew Says:

      Thanks, Maryann. I didn’t do anything separate / special for garbage collection. I was using a 3rd party plugin and my assumption was that it would take care of garbage collection through its own session management. I guess I better go back and check the session folder 🙂

    • Adam Says:

      You are a legend! Searched everywhere for this fix, THANK YOU!

    • Grishnakh Says:

      Thanks for this, this fixed my problem with setting up jCart on my FatCow website. The real offender was the “register_globals” variable. When set to ON, as default, nothing worked, and I got strange PHP errors. Turning it OFF fixed everything. I also found that if my “session.save_path” variable is set properly, I don’t need to use the “session_save_path()” call before every instance of “session_start();” as FatCow recommends.

    • raghu sham Says:

      Thnx, for the post dude. You have saved lot of time.

    • andrew Says:

      Sweet. Thanks for the info! Glad it helped.

    • andrew Says:

      My pleasure! Glad to help save others time.

    • Kovo Says:

      You don’t know how much this has helped me. I was trying to setup WP-Ecommerce plugin in wordpress and the cart kept emptying every time i clicked checkout. Amazing how its 2011 and fatcow still hasn’t fixed this.

      Thank you very much!!!

    • andrew Says:

      Yay! Love it. Thanks for taking the time to let me know. You’d think it would be easier already hey? All the best! -andrew

    • mik Says:

      Thx for the very usefull tutorial on fatcow and php.ini
      Really appreciated.


    • Alid Misli Says:

      im on fatcow, and damn THANK YOU very much!

    • Marshall Says:

      THANK YOU SO MUCH. I wish I could have found you 10 hours ago. This also works for iPage.

    • admin Says:

      Sweet! Thanks for letting me know! All the best!

    • Ahmet Says:

      Hello. i had a problem with fatcow’s hosting. i have a wordpress based website and i tried to install a plugin but could not activated gives error about Zend Optimizer.I contacted to fatcow about this issue but they said
      “your applicaton needs a higher version of Zend optimizer which is not available on our server. Hence, unfortunately, you can’t use this plugin on our server or have to look for plugins that use the Zend optimizer that our server is running. ”

      “Adding the ZendOptimzer code will not upgrade the version of ZendOptimizer. Unfortunately, as of now we cannot provide higher version of ZendOptimizer. Hence, you cannot install the plugin that you are looking for. ”

      “We do provide Zend Optimizer v3.3.9 on our platform. We do support latest version in future and unfortunately, we do not have ETA for that. ”
      “We have already added the Zend Optimizer v3.3.9 Code in the php.ini file. We do support latest version in future and unfortunately, we do not have ETA for that. ”

      These were their answers. and now i could not activate the plugin and use it. What can i do about this ? Thanks for your help !

    • Talles Hentges Says:

      This is Talles from Brazil, just making my own online liquor store right now, hosting on FatCow. Precious advice you gave, thanks a lot!

    • andrew Says:

      Sorry, @Ahmet – I haven’t had any direct experience with those particular issues on fatcow hosting.

    Leave a Reply