The Drupal community, and open-source community at that, has always had the altruistic goal of being accessible to all. The hope is that as freelancers and tech gurus go out into the world, maybe we can help by making better, more secure websites.
And then you have piece-of-crap hosting like that of Network Solutions.
Now, I only bring this up because as I work with clients to get their internet presence setup, sometimes you're stuck working with their choice of hosting provider, hosting package, and admin credentials.
This means crazy php.ini setups, no ssh access (because the cheap plans don't enable this), and passwords like '1234myfirstname'. Never the eternal pessimist, I figured I'd leave a few words of encouragement and one small tip to those that run into this.
First, don't give up. Although you can't convince your client to pay you monthly hosting fees on your leased vps (who hasn't tried that?), continue to make their internet presence more than a site built by iPowerweb. Yeah, you may have to wrestle with a table-filled layout, but a little progress is better than no progress.
Second, scour the drupal forums for a solution. Sometimes it may take a couple of days, but it seems like everytime I run into a roadblock, someone else has as well. A forked, non-hacked core, Drupal install on a POS hosting provider is STILL better than an MS Access-driven site hosted by 1and1. :-)
Third...if you're on Network Solutions, and get the dreaded email of 'we will not turn off register_globals or magic_quotes_gpc because it would affect other shared hosted sites', take a deep breath, laugh at them uncontrollably, blog about it, then put this piece of code in the cgi-bin of your vhost within a text file called 'php.ini':
register_globals = off magic_quotes_gpc = off
Yeah, this whole blog post was all about solving the Drupal install message of 'TURN THIS CRAP OFF', but I figured the it was better suited for the community to at least know I didn't give up! Why it ignores this directive in .htaccess or the ini_set() in the settings.php is beyond me, but....it does work.
Thanks go to this forum post, btw.
Comments
I hear ya...
Shared hosting normally sucks. However, you should be able to find hosts with SSH access and up to date distros.
Also, you may want to rethink the VPS option - it isn't as expensive as you may think. See slicehost.com and linode.com for unmanaged VPS hosting for only $20 a month. Both are repuitable but are completely "DIY". One nice thing about a VPS (besides the freedom) is that you can easily host multiple sites on a Drupal multi-site config. Then sell your clients on a larger monthly fee for "hosting +", keeping their sites up to date etc.
There will definately be a server admin learning curve but the knowledge you gain is worth it. Based on experience, many of the issues clients face are tied to email. I highly recommed offloading email to a service such as Google Apps. It will cut down support by half.
Good luck!
It ignores them in an
It ignores them in an .htaccess because Network Solutions is running their PHP as a CGI application, not as a module (php_value in an .htaccess only works against mod_php; the fact that you can do php.ini in a cgi-bin means they're running something like suPHP or mod_fastcgi or whatever they're called). As for not being able to use them in an ini_set() - well, "it's too late" - some PHP directives have to be set PRIOR to the script being run, not inside the script itself.
A Brief Word About Shared Hosting: No
I can only think of two reasons why you would choose shared hosting over hosting a site yourself on a VPS:
When we started out in business we offered hosting as an option. The first job we got from a client with an existing shared hosting account convinced us to make it compulsory. For the size of clients we get, we host dozens of sites on a mid-range VPS server (rarely using more than a few percent of the capacity of the allocated resources), which makes the hosting cost per client mere cents per month. What we call "hosting" is actually the cost of deploying security updates plus server housekeeping.
Now when a client comes to us with a domain registered, a site mockup (done in Microsoft Publisher), and a shared hosting contract, thinking that doing this ahead of time will make a noticeable difference to the price we charge, we even offer to waive our "hosting" fee (which is invariably cheaper than the shared hosting plan anyway) entirely for the duration of their shared hosting contract. The income we lose this way is much less than the equivalent value of the hours we'd spend struggling with a shared host. I'd rather spend my time developing than submitting support tickets.
Definitely.
"Client self-sufficiency" is our mantra, and you're right. We started out doing some hosting on an ad-hoc basis, only to decide that it didn't make sense. It's not what we do best and it'll never BE what we do best, and it doing it "just good enough to get by" still sucked enough energy that it was a drag on other projects we were passionate about.
We generally work with clients that have dedicated servers hosting their sites, but individually, every one of the 'Bots have shared hosting accounts for various personal sites and projects. I know that I never would've started working with Drupal if it wasn't at least possible to run it on shared hosting -- the goal of keeping it accessible to those without "big iron" is really important to keep the community healthy and growing.
Dude! You just saved me 10 hours of tech-phone hell.
Thanks for posting this is such a comprehensible and entertaining way. I'm a Drupal noob, hosted on Network Solutions, and I am SURE you just saved me 10 hours on the phone with tech support.
Implemented the fix and I'm on to setting up my database.
I also appreciated the folks who weighed in on VPS. I'm not there yet, but if I keep running into these kind of issues, I may make the leap.
Thank You
This solution worked very nicely.
Thank you!
Drupal.org recommends these hosts
Here is a no hassle list of Drupal organization approved hosts:
Network Solutions woes continue
I've just wasted the better part of a day trying to get a client's contact form to call a php script and send an email with the contents of the form.
No matter what I've tried, Network Solutions either gives me an INTERNAL SERVER ERROR or PAGE NOT FOUND. I've talked with 4 different tech support people and got 4 different explanations. None of them offered any real soltions that worked. One of them suggested that I should use a Perl script instead of php. Another said that I should use their ( somewhat primitive) built-in form generator. I suspect that they have the tool because getting php scripts to send email is so problematic.
The exact same contact form and php script runs flawlessly on my HostGator and GoDaddy test sites. In the future I plan to avoid taking on clients with Network Solutions hosting if they have anything more than a simple sales page.
200 OK Error Drupal on Network Solutions
I built a very basic Drupal site for a client and I wanted to keep them on their existing hosting package - Network Solutions. After turning off register_globals and all that other fun stuff, I see that every other page-load displays an HTTP "200 OK Error" which is sometimes printed on top of the theme and other times in plain HTML.
Two weeks of back-and-forth with tech support produced several support tickets marked as "resolved" - but no solution to the problem.
So after almost three weeks, Network Solutions continuously tells me that the problem is fixed, but my site continuously spits out "200 OK" errors. The "engineering department" apparently thinks that there is no problem having these errors on a site.
Bottom line: I gave Network Solutions a whole-hearted chance, but I end up saying this: DO NOT try to run a Drupal site on Network Solutions.
Hello, there will definately
Hello, there will definately be a server admin learning curve but the knowledge you gain is worth it. Based on experience, many of the issues clients face are tied to email. I highly recommend offloading email to a service such as Google Apps. It will cut down support by half.
Post new comment