In the second part of this "The making of..." series, I will tell a little about setting up www.openlife.cc with Drupal.

The domain name

Already when I was publishing the Finnish book I prepared for an eventual translation and had in mind the name "Open Life". Unfortunately, domain names like openlife.org, openlife.info and openlife.net were already registered then, although none of those had functioning websites. I believe openlife.com might had been free, but even so, a .com name didn't feel appropriate. So instead of paying hundreds of dollars to transfer those to me, I did a trick I've used earlier too, I added a dash and registered open-life.org instead.

Then when I was actually finishing the English translation, I discovered the .cc top level domain. In this namespace "openlife" was still free so I decided that would be the address of my website. Since the book is published under Creative Commons I thought .cc was a really fitting top-level domain for it.

.CC is actually the country domain for a small island nation called Cocos (Keeling) Islands in the Pacific Ocean. (All 2-letter domains are national domains, .eu being a border case.) But it is actually administered by a VeriSign company, in a similar manner like the .nu and .tv domains you may have seen. In reality, there is no affiliation to Creative Commons, but there are all kinds of websites under the cc-domain.

Discovering Drupal

I'm a big fan of PHP for making websites. In my training days PHP was my favorite programming language to teach and also the courses were the most gratifying. I remember one group who had been using Oracle's PL/SQL to generate HTML pages attending my PHP course. It was like they had discovered a whole new world and couldn't wait getting back to work and using PHP instead.

There has always been a lot of different Content Management Systems for PHP. The only problem for me was that there were too many and it was hard to find out which was the best one. For those who want to use Python, there has always been one choice: Zope. But for PHP I could easily pick 5-10 CMS frameworks all worth considering and none standing out from the crowd. This problem had always been intriguing me for many years. (Actually, I also got to know Zope once, and in my opinion it is a bit too complex. I would pick Drupal in front of Zope or Plone any day!)

But last year I was finally lucky. At work I was involved in a project where we needed a PHP based CMS framework and I was designated to pick one! So I got to spend one full week (and was paid for that time) to investigate the best PHP frameworks out there.

Our methodology in the ramp-up workshop was simple: We enumerated all the main frameworks we could remember. There are several called something-Nuke. Those seem to always be news publishing sites and since our site was not a news site, we deemed all Nuke-frameworks inappropriate. I also considered the very fact that there were so many forks of the Nuke flavor alarming. Perhaps there was something in the concept that had not worked out that made people reinvent the Nuke-CMS all the time.

We were then left with some others: phpWebSite, phpCMS, Xaraya and Drupal. I had actually never heard of Drupal before, but we found it on a website called OpenSourceCMS which is devoted to reviews and comparisons of Content Management Systems. I'm really thankful to OpenSourceCMS, without it I may have never discovered Drupal! Out of these we picked Xaraya and Drupal for closer scrutiny. The most important factor when picking them was the image their website gave of an active project with a vibrant user community. For instance phpWebSite had not at that time updated it's web page for several months, an immediate reason for disqualifying it.

There were also two other popular frameworks we did not consider. Mambo was in the middle of the crisis that eventually spawned the Joomla fork. Because of the uncertain situation we just ignored it. After all, we had plenty to choose from and any reason to shorten the list was a good reason. Midgard is another venerable framework. For some reason I had a view of it as an old and stagnated project, but I've later found out that there are actually some Finnish and Swedish companies actively using it even today.

So, I got to spend 1 week with a Xaraya and Drupal shootout. At the outset Xaraya was the favorite actually. If you look at the Xaraya website you can see that it looks very cool, clearly the Xaraya developers know what they are doing. But when digging deeper Xaraya seemed to be quite complex. For instance in the 2 days I was investigating it I never figured out its user management system. Also the modules API was more complex than Drupal's. All the while when getting to know Drupal I liked it more and more. It was simple and easy to get up and running, yet the APIs where flexible and allowed a guru to do just about anything. Very much like PHP in short.

So we picked Drupal at work and started learning it for the project. Naturally, once I started to work on openlife.cc, I used Drupal too.

Setting up Drupal

After you get to know drupal, setting it up is quite straightforward. You need a MySQL database (or PostgreSQL is fine too, but MySQL really dominates the web hosting providers), then run the SQL script provided, unzip the Drupal code into a directory and you're done. Ah, of course you need the Apache webserver too. If you happen to be running Windows on your desktop computer, I recommend the XAMPP installation package to get Apache and MySQL in an easy Windows installation file.

So, after unzipping Drupal and generating the database tables, you just go to your Drupal site and start going through the configurations under the "administer" menu. This could even take a couple of days. While working with the basic configuration, you also download and install optional modules for the features you want.

At the same time, you start developing a theme for the layout of your site, and the configuring and working with the layout pretty much support each other. Many Drupal sites (like Drupal.org itself) have a basic layout with a middle column with content and lots of boxes on both sides, or at least one side. For my site I wanted a simpler and plainer layout. Actually, I was quite content with the layout on the Finnish site and tried to copy it as much as possible.

A nice and plain theme to adapt is Chameleon, one of the themes that comes with Drupal. That is the one I used for my own theme. Chameleon uses Drupal's original theme API, but in the newest version it is also possible (and recommended) to create themes using PHPTemplate and XTemplate engines. (Read more from the Drupal Theme guide.)

So my strategy for the layout was to have as little boxes as possible, basically it is just the navigation menu on the left. Even for the boxes in use I removed all borders and also the title. I mean, people will know it is a menu even if it doesn't say "Menu" on top of it! The "Login/Register/Forgot password" links on the top right are from a tip on the Drupal site. In my opinion that is much smarter than having the login form taking up space on each page.

The resulting theme is called Vineyard. I'm going to release it on Drupal.org as Open Source one day, but I need to clean up my CSS files first, perhaps even comment them a little.

Hacking the book module

I've used some basic Drupal modules on this site. But the most important one for my purposes was obviously the Book module, which you can use to publish... online books. On Drupal.org the Book module is used for the online guides. It also allows collaborative editing of a book.

But I soon realised the Book module only supported very basic user rights. Actually the problem is, that all book pages on one site share the same access rights. For me that was not ok. I wanted one version of the book which was read-only, as published on paper, and another book that it is possible for all logged in users to edit and contribute to.

So, in true Open Source fashion I went to the source code and added a feature to provide for this. Also in true Open Source fashion, I settled for the easiest solution that would satisfy my needs and actually my feature has not been included in the official Drupal Book module. But it is available if you are interested.

The Footnotes module

There was one important feature I couldn't find anywhere. As you know if you've read any of the book I'm a big user of footnotes in my writing. When uploading the book as html to this site, I didn't want to manually start formatting over a hundred footnotes. I wanted to be able to write footnotes within the text and have them automatically moved to the bottom of the (web)page and automatically numbered. The same as you do with OpenOffice or other word processors that is.

So, it is time for some Open Source magic: If you need a feature, you can add it yourself. Luckily I'm more than proficient in PHP programming, so I actually enjoyed implementing this.

When searching for the footnotes feature (before doing something yourself, always find out if someone else already did it!) I had found the Textile module. Textile is a markup language you can use in Drupal instead of HTML. I found it because it actually has a footnotes tag, but it doesn't provide automatic numbering. Even so, I was planning to use Textile markup for the book pages, so I created my Footnotes module to output Textile compatible markup. As an excercise or something, I also created another function to support HTML-style footnotes, but didn't plan to use it.

It took about 1-2 weeks, programming in evenings and weekends. After that I applied for a CVS account and published Footnotes on Drupal.org.

Then the Open Source magic happened. Another Drupal user also needed to use footnotes. He found this module and was very happy about it. But he was using the HTML compatible version of Footnotes, and since it was very basic he made some enhancments to it and sent those to me. It went so far, that after a couple of weeks the HTML version was great, much better than the Textile markup version. A couple of weeks later the book was ready and I started to copy-paste it into my Drupal site. I too ended up using HTML instead of Textile, mainly because of the nicer footnotes!

To me this was the first time I was in charge of a small Open Source module, and I have truly enjoyed the experience. You can read about the discussions leading up to the enhancements on Drupal.org. Thanks to all who used and contributed to Footnotes!

GoDaddy

I bought my domain name and web hotel from GoDaddy.com. It is cheap and the web tools to administer the site are ok. However, there seems to be some limitation in the MySQL on GoDaddy servers that makes it impossible to use the Drupal search module. That was a disappointment really.

I've had problems with hosting providers and MySQL before. Once I was really careful to select a provider that had a new enough version of MySQL to support transactions. Only to find out that this hosting provider had compiled their own version of MySQL with transactions turned off! This is really an annoying feature of MySQL in webhotels, you never know what you get. I think MySQL AB should want to enforce some kind of standard or at least encourage webhotels to make it more explicit what they support.

There is a discussion on Drupal.org with links to good hosting providers. This could be interesting to you whether you use Drupal or not.

The End

OpenLife.cc went live on September 4th, 2006. So far there has been a couple of thousand visits. Not too bad, but actually that's even less than the Finnish book got during its first months. Unfotunately I was all too busy at work the past months, so I haven't been able to promote the book as much as I should have either.

In the third and (most likely) last part of "The making of..." series, I will tell about my experiences with Lulu.com publishing.