Because Network Solutions Sucks
One man's frustration is not lost in vain.
5 comments
Share our glory:
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 = offYeah, 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.
Make people smarter:
Full Name
Fredric Mitchell
Website
http://brightplum.com
Email Address
fredric@brightplum.com
- Thanks and breadcrumbs
3 days 2 hours ago - Awsome!
6 days 9 hours ago - Thanks!
2 weeks 5 days ago - Finally.....
2 weeks 6 days ago - RE.
4 weeks 1 day ago - Very stuck... getting a 500 error. Need to tie just one table...
5 weeks 2 days ago - Dude! You just saved me 10 hours of tech-phone hell.
5 weeks 3 days ago - You must had the word Shared
5 weeks 5 days ago - Thanks
6 weeks 7 hours ago - Trapping Errors - Thanks for pointing the way!!!
6 weeks 1 day ago
Be sure to check out the latest from Smashing Magzine. They have a great article on CSS Specifity. Might be a review for some but still a good read.
There are a few variables that we can access from anywhere at anytime in Drupal, and the most important one is $user. The object
$usercontains (almost) everything you’ll ever need to know about the user that is currently surfing the web site.Be sure to check out 11 Heavens' article covering just about everything you need to know regarding the $user variable.
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.
Post new comment