PHP.ini Issues on Fat Cow Hosting
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.
April 24th, 2010 at 9:30 pm
thanks for the hints, now I can get back to work
May 2nd, 2010 at 12:48 pm
haha – You amaze me. Plenty of stuff out there to know, it seems.
June 2nd, 2010 at 11:49 am
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.
June 2nd, 2010 at 1:27 pm
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!
July 13th, 2010 at 4:33 pm
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!
July 14th, 2010 at 12:27 am
Once is plenty 🙂 Sincere thanks for letting me know. YOU’RE WELCOME!!!
August 5th, 2010 at 12:44 pm
Amazing. I spent a whole day trying to fix this issue!!! Thanks a lot Andrew
August 5th, 2010 at 1:45 pm
Sure thing! I totally know that frustration. Happy to help.
August 20th, 2010 at 7:32 pm
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
August 20th, 2010 at 8:08 pm
Fantastic! Thanks for chiming in!
September 13th, 2010 at 1:19 pm
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!!
October 1st, 2010 at 12:28 am
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 🙂
October 31st, 2010 at 11:57 pm
You are a legend! Searched everywhere for this fix, THANK YOU!
December 2nd, 2010 at 11:13 pm
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.
December 28th, 2010 at 6:00 pm
Thnx, for the post dude. You have saved lot of time.
December 30th, 2010 at 12:01 am
Sweet. Thanks for the info! Glad it helped.
December 30th, 2010 at 12:02 am
My pleasure! Glad to help save others time.
February 1st, 2011 at 4:33 pm
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!!!
February 1st, 2011 at 10:13 pm
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
April 20th, 2011 at 4:52 am
Thx for the very usefull tutorial on fatcow and php.ini
Really appreciated.
mik
May 1st, 2011 at 10:55 pm
im on fatcow, and damn THANK YOU very much!
May 9th, 2012 at 1:20 am
THANK YOU SO MUCH. I wish I could have found you 10 hours ago. This also works for iPage.
May 9th, 2012 at 2:15 am
Sweet! Thanks for letting me know! All the best!
October 25th, 2012 at 12:36 am
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 it.it 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 !
January 8th, 2013 at 6:22 pm
This is Talles from Brazil, just making my own online liquor store right now, hosting on FatCow. Precious advice you gave, thanks a lot!
January 22nd, 2013 at 2:29 pm
Sorry, @Ahmet – I haven’t had any direct experience with those particular issues on fatcow hosting.