A New Website, Part Two - Choosing Drupal

In the previous installment I wrote about selecting a hosting service and setting up my web server. Now I'm to the point where I actually want to put something on it.

I could simply put up some web pages. The hosting package I selected gives me several domains, and in one of them - fallacies.ca - I could simply upload an index file. In the previous installment I actually did this, to test the domain.

But I run a large and complex site, one which would be impossible to maintain merely by creating and uploading HTML files (even simple blogging websites are too complicated to maintain this way - sure, you could learn how to do it pretty easily, but then you'd be doing a lot of extra work every time you created a new post).

This means that I'm looking at a content management system (CMS) of some sort, and as the title suggests, I selected Drupal. To be precise, the beta version of Drupal 5.0, which was released just a couple of weeks ago.

Why Drupal?

First of all, I don't have a lot of money to spend on this (I had to pay my electricity bill this morning, which means I have no money to spend on this). So I am looking at free and open source software. Though that said, even if I had a budget, I would be going down the free and open source route. Not simply because I think it's philosophically the right thing to do (though I do). But because the open source CMSs tend to be better.

In choosing my CMS my primary focus was the computer language it is written in, rather than, say, features or brand name. Why focus on the computer langauge? First of all, the properties of the language will become the properties of the CMS. A slow language means a slow CMS; a complex language means a complex CMS. Second, I will have to maintain the CMS myself, which means I may have to mess around with the coding. That means I want code that is simple, straightforward, logical and easy to maintain.

Opting to go the open source route still left me hundreds of choices. My preferance would have been for a CMS written in the Perl computing language, because this is the computer language I am most comfortable using. However, Perl systems, like, say, Scoop, typically require the installation of Perl modules, which requires the cooperation of the server administrator - in other words, my hosting service. Sure, they would probably cooperate - but there's always the possibility that they won't install a key component. As at JaguarPC, where I asked, but was bluntly told, "We don't support mod-Perl."

How about another computer language called Python? There is a perfectly good CMS that runs under Python, called Plone. Of course, to make Plone work, you have to install a framework called Zope. Could still work. But now I'm installing functionality I don't need in order to get functionality I do need. Also, I'm not comfortable with the size and nature of the Plone community. And finally, most of the Plone installations I've seen run slowly. Maybe it's not a problem with Plone per se. I'm just saying.

CSoft also supports Ruby on Rails. I could have built a Rails site - I may well experiment with something in the future. But the Rails community is immature, both in temperament and development. I've already documented my experiences with Rails, and I didn't want to go back there again.

I won't even linger on Java. It might be faster, if I could manage to get all the versions correct and to keep the Tomcat server from crashing. But it might not be - after all, I'm running on a little hosted service here, not an enterprise server. And I don't have the desire or the patience to spend writing Java code. I've seen development work in Java. It can take weeks to write a simple application. Who needs that grief? Java runs a Flash application on its homepage. Need I say more?

Really, when it came down to it, the only CMS I was going to choose was Drupal. It is written in PHP, which is sort of like Perl for impatient people. Personally, I don't like PHP at all - it's a spaghetti language, with far too many commands and no internal consistency. But it is reasonably fast, it is quite popular, and it's still a lot easier to work with than Java. A lot of what I know from Perl will be immediately applicable in PHP. It has a large development community, and Drupal in particular has a large development community.

I could have selected some other PHP applications. WordPress, for example, is popular blogging software, and written in PHP. The majority of edublogs are written in WordPress. However, I wanted something that would handle complex data types, not just blog posts. I could additionally have chosen other PHP content management systems. I have tried, for example, PostNuke. But while it's very similar to Drupal, without the development community there are not as many modules to choose from; I would have to write a lot more code myself.

And really, that's what clinched it for me. The Drupal modules. Much of the additional functionality I need - everything from RSS to image processing - can be handled in Drupal modules. And for some of the special stuff I will need I can write my own Drupal module. These I can turn back over to the Drupal community, which means the modifications I make will be available immediately to a wide user base.

So I chose Drupal. Why Drupal 5.0, especially since it's still in beta, which means it's not ready for production use? Well, beta software doesn't scare me - I have been working with software for a long time. Also, Drupal 5.0 supports multiple sites on a single installation. I will be running at least three sites, each with their own URL. One is very big, but the other two are pretty small. I don't want to install and maintain additional instances of Drupal for them. So I figured I would take the risk.

Installing Drupal

Normally, on a site with a single domain name, you would simply install Drupal in the main directory (usually called 'www' or 'htdocs' or something like that). On my server, because I have several domains, I have several directories for my web files: www/fallacies.ca/, for example. I couldn't install Drupal in the main directory, because all the requests will route to a subdirectory. But I couldn't install in a subdirectory either, because then I would have to run three separate versions.

What I decided to do was to create a separate directory for Drupal, called (naturally enough), www/drupal/. I can use my base internet address, 205.205.221.37, to configure it. Then I can simply reroute requests to the other subdomains through my Drupal installation. So I set up what is called a 'symbolic link' to route requests from 205.205.221.37 to www/drupal/.

This may all sound straightforward, but in fact, I spent the entire morning getting to this point. I first had to look at the Drupal information to see how to set up the multiple domains. There is essentially no documentation for Drupal 5.0 (I am not thrilled by the documentation for other versions of Drupal, though there is an online manual (that never shows up in Google searches - you get this page, which is useless, because you want this page, or actual manual pages, and the first page doesn't evenm link to them).

So what I did is I downloaded the Drupal installation files from here, and then opened up the archive. Any large application like this will consist of dozens of individual files; these files are grouped together and then compressed to form a package called an 'archive'. Linux has a nice application called 'Fire Roller' which will offer to open up archives for you, which is what I used. On windows, you might be presented with the option to use WinZip. Anyhow, to simply read something, rather to install it, it's a lot easier to just open it up right away. In any event, I looked for the file 'INSTALL.txt' (all applications will have some file like this).

Once I understood how Drupal 5.0 would set up separate domains, I realized that I would have to route all the requests to Drupal directly (I had thought it might have me create a separate home page for each domain name). This meant I would need to find a single place to put Drupal. This in turn had me looking through the documentation on CSoft, trying to undo the way they handle requests to different domains.

Once I learned that the system was set up using symbolic links, I realized them that I could simple alter the links. I thought at first I could remove the links and have everything go to the www directory, but it doesn't work that way - it wanted to go to a directory called www/205.205.221.37. Aha! I thought, and proceeded to set up the sympolic link. The command failed. I tried a dozen different variations. All failed. I asked Luc what was doing wrong. Ah, I was doing it backwards. I was using ln -s original destination, but I should have been using ls -s destination original. Why oh why would they make it backwards like that?

I made my drupal directory, set up my symbolic link, tested everything (by putting index.htm files in the different directories), then wrote this and had some lunch.