Trap number 1. Your database server is not the default localhost. This one is actually easy. On the “Database configuration” page the trick is to click the rather subtle “Advanced options” link near the bottom of the page. Then you can enter the name of the server.

Trap number 2. Register_globals needs to be disabled. To do this, set up an .htaccess file, and add the following code:

php_value register_globals Off

Trap number 3. Your system configuration does not support clean URLs. You could just ignore this one, but increasingly friendly URLs are seen as a basic site need. To do this, you have to expand the .htaccess file. Replace the one line in step two with the following more comprehensive code (where XXX is the path of your Drupal site if it’s not in the root):

<IfModule mod_php5.c>
  php_value magic_quotes_gpc 0
  php_value register_globals 0
  php_value session.auto_start 0
  php_value mbstring.http_input pass
  php_value mbstring.http_output pass
  php_value mbstring.encoding_translation 0
</IfModule>
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteBase /XXX
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

Trap number 4. You run cron manually. There is nothing wrong with running Drupal’s cron.php by hand at first. However, if you set up a search engine or do other things requiring cron, sooner or later you are going to have to face this UNIX beast. To do it, you can either SSH into your server and enter the appropriate crontab or use the Account Control Center. If the latter, go to the Advanced menu and then the Crontab Manager. Choose how often you want it to run, then enter the following (where XXX is the URL of your Drupal site):

/usr/local/bin/wget -O - -q http://XXX/cron.php

With these out of the way, you should be off and running, ready to do the real coding for a fabulous Drupal site.

• Drupal optimized (as opposed to any old host)
• Great customer service
• Reasonable cost – comparable to other shared hosts

Two months later, I have yet to find this holy grail — but I’ve learned enough about Drupal hosts to deem it worth sharing my findings.

Frankly I’m surprised this has been so hard. I’m reasonably good at web research and this host is for a modest site. Specifically it’s a redesign of Gilda’s Club Nashville. This is a small, low-traffic site to begin with, and all they want is a new look-and-feel using a simple content management system they can easily update themselves. Fairly basic Drupal will be more than enough. It doesn’t require any fancy-pants high-end Drupal coding.

My bet is in another year it will be much easier to find the kind of Drupal host they need. But for now, here is a quick summary of the pros and cons of the hosts I’ve looked at.

DreamHost

I have a soft spot for DreamHost — so soft it’s what I use for this very blog. Moreover, my first test Drupal install was on DreamHost. It worked like a charm. Nevertheless, my soft spot defies logic. DreamHost can be incredibly slow with MySQL-powered sites. I guess it’s because they are so much better than my previous host — plus they have excellent customer service and, even better, they are hilarious. One way of framing my quest is as a search for something better than DreamHost. I want a fast DreamHost that specializes in Drupal installs.

Bryght

At first blush, Bryght appeared to be the perfect match. Initially my biggest concern was that it was too dumbed-down. A certain amount of simplifying would be great — thinking of upgrades in particular. But it could easily be too much. So I used their contact form. I tried it a few times, but my sense was the form wasn’t working right. Sure enough. I never heard back from them. That did not auger well. So I crossed them off my list.

(mt) Media Temple

mt has a great reputation. I contacted them and heard back almost immediately. They even offer a one-click install for Drupal. That sounded promising, but it’s still (as of May 2008) only Drupal 4.7. Version 6 (not to mention version 5) has been out for quite some time. Ergo they must not care all that much about Drupal.

DrupalValueHosting

I came very close to going with DrupalValueHosting. They look ideal. In fact, they’re the reason I say it should be much easier to find a Drupal host in a year. My only hesitation with them is that they are very new. Since the host will not be for my own site, for now it seems just a bit too risky.

And the winner is…

pair Networks

pair was highly recommended at PodCamp Nashville, and like (mt) has an excellent reputation. I did discover one potential problem over memory caps in Cheny U’s thoughtful review of Drupal hosts. However, when I reached a sales person (right away) he knew about and acknowledged this issue quite openly. When I explained Gilda’s needs, he was confident it wouldn’t be an issue. He said they host an increasing number of Drupal sites. Also in their favor, he was able to quickly answer my questions about multisite installations (which means they really are used to Drupal), plus they offer a discount for non-profits.

So pair Networks it is — and I will let you know how it goes.

To back up, a multi-site install means you set up the core of Drupal just once, and then you can easily create lots of other sites using that one installation. The other sites don’t even have to have the same domain. It’s very cool. For example, at work I hope to set up one master Drupal site, and then create instances for each of the labs. After that, the labs can maintain their own sites.

For now all I’ve done is to set it up on my Macbook using localhost. I made it as modest as possible — just using one database and subdirectories. But having worked through this, it will be much easier to get it working in production.

Here are the gory details.

1. Go to the “sites/” directory and set up your new directory. At first, I named it “sites/site2/”, but that turned out to be a mistake. Given that the URL I was going for was http://localhost:8888/drupal/site2/, the correct name was “sites/8888.localhost.drupal.site2/”. It still looks weird to me, but that’s how you do it. The pattern is:
   [Port #.]domain[.directory][.subdirectory]/
   So if the URL were to be http://happywebdiva.com/drupal/site2, then the new directory would have to be happywebdiva.com.drupal.site2/
2. Copy the “settings.php” file found in “sites/default/” into the new directory.
3. Edit the new “settings.php” file. Leave the $db_url the same, but on the next line, give $db_prefix a value. I cleverly edited mine to read:
   $db_prefix = ‘site2_’;
   This way you won’t have to set up a new database. Once you install the second site (step 6 below), the database size will double — from 40 tables to 80 tables.
4. Further down in the “settings.php” file, look for a line that’s something like:
   # $base_url = ‘http://www.example.com’;
   Uncomment this and change it to your desired URL. In my case this was:
   $base_url = ‘http://localhost:8888/drupal/site2′;
5. Next it’s time to create the dreaded symbolic link. Open Terminal (on a Mac) and use the ln -s command followed by first the full path of your base install and then the full path of the second sites’ directory (leaving off the characters before the periods in the final directory, e.g. changing “8888.localhost.drupal.site2″ to just “site2″). In my example, it was:
   ln -s /home/username/public_html/drupal/ /home/username/public_html/drupal/site2
   One caution: be sure there’s not a file or directory in the first directory that’s the same name as your new install. You don’t want the symbolic link overwriting something critical.
6. The last step…. In your browser, go to the new site’s URL followed by install.php, e.g. http://localhost:8888/drupal/site2/install.php

That’s it. You should now have a second site (and soon a third and fourth) to play with.

Addendum: In the myriad of multi-site documentation that’s on the web, these three pages helped me the most:

• Drupal Cookbook (best if you are using Windows)
• Multisite with drupal for dummies
• Geek Glue

• Lullabot’s Drupal Podcast
  I love how Jeff Robbins and crew laugh their way through Drupal tips, analyses and news. Team Lullabot describes itself quite accurately as “Drupal experts.” While some of what they are talking about goes over my head, I can always return later, and meantime I’m learning what matters most to Drupal developers. This particular link is to Podcast #40, one of their best shows for those new to Drupal. In fact you might want to start with their shows ending in a zero, as #50 is also particularly helpful.
• Security Announcements
  While far from fun, if you’re serious about Drupal, it’s good to know what needs patching.
• Planet Drupal
  This aggregator has tons of great info, though I’d only recommend this for the enthusiast or Drupal-serious, due to sheer volume.

Go straight to “Administer” / “Administration theme” and change the theme in the dropdown from “System default” to a theme that you know is stable. With version 5, the best choice is “Garland.”

Then one day when you make some hideous mistake in the custom theme you are developing and it blows up your ability to get to much of anything, your administration panel is safe.

For the rest of the time, your home page and content areas, even when you are signed in as an admin, have the (hopefully not hideous) look-and-feel you are developing.

1. Send in a form request to ITS to set up a new database. This is likely to take a day or two. Once it’s set up, hang onto the connections strings and….
2. Download Drupal (version 5.6 in this case).
3. Unzip and move the contents to the correct directory on your computer.
4. Read the install.txt.
5. SFTP all of the files to the server. (I use Dreamweaver for this).
6. Change the permissions (temporarily!) to the file /sites/default/settings.php, so the server can write to it. I do this using CyberDuck.
7. Manually add a “files” directory and set permissions on it so that it can be written to.
8. Point your browser to the base url of your soon-to-be Drupal website. At this point you should see the setup screen. As well as filling out the required fields, click on “Advanced’ near the bottom of the page, and then replace “localhost” with the host ITS supplies.
9. Voila! Drupal should appear. There are just a few minor housecleaning items left.
10. Change the permissions back on the settings file you altered in step 6.
11. Go to the status report (in admin/logs/status) and see if there are any problems. You’ll see immediately if there are. Probably “Cron maintenance tasks” is highlighted. Just run it manually for now.
12. Chances are you’ll want cron to work automatically in the future. ITS has to do this for you. (They don’t allow SSH.) Email ITS Partner (its-partner@vanderbilt.edu) and tell them you need a cron job that looks something like “0 * * * * wget -O – -q -t 1 http://exampledrumpalsite.vanderbilt.edu/cron.php” — replacing “exampledrumpalsite.vanderbilt.edu” with your own drupal URL. This example would run your cron every hour on the hour. If you don’t need it that often, tell ITS.

That’s it. Now go forth and build a fabulous Drupal site for VU.

Not only that, there are more and more web developers and designers where I work (Vanderbilt) gravitating to Drupal. It looks as if a group of us will be gathering soon and developing our own site. And Gill Murrey has started her own Drupal site listing great resources and blogging news.

It seems to me these are the two keys to success.

1. Just dive in and do it.
2. Find others to network and brainstorm with.