My web server setup

Overview

As I alluded to recently, I completely overhauled the way my web site is hosted. Most of the changes are behind the scenes, but there are a few differences that the user sees. I will go over what I did and how, as well as why I prefer this method of managing my web site.

Why Did I Do This?

As I mentioned previously, I was primarily using my CMS (Oddmuse, then Movable Type) to generate static web pages. Most of my content doesn’t change daily, or even weekly, and it didn’t make sense to suffer the performance losses involved in a truly dynamic site.

In order to change a web page, or add a new one, I had to visit the site, log in, make the changes, publish the changes, and then possibly repeat if I wanted to tweak something. This was slow and painful, and made it more tedious to use a real text editor (e.g. TextMate) instead of editing the content within Firefox.

Additionally, I wanted to have a local copy of my site on my laptop that could be accessed while offline if necessary, but that was a faithful copy of the live version. This would make it easier to keep a backup, as well as to test changes locally before publishing them to the web.

Using MultiMarkdown To Publish Web Pages

My web pages are created as plain text files in the MultiMarkdown syntax. They include a bit of metadata (Title, Tags, Date). I use an XHTML to XHTML xslt file to add some extra information into the header, and to add some SSI includes at key points to create the layout for each page (the header, the sidebar, and the footer, as well some cgi for a few other features).

Because I didn’t want to remember to add metadata to specify the proper XSLT file on each page, I modified the mmd2XHTML.pl script to do it for me by adding the first line in the snippet below and naming the copy mmd2web.pl and then aliasing it in my .tcshrc file.

my $data = "xhtml xslt: xhtml-static-site\n";
$data .= <INPUT>;
close(INPUT);

MultiMarkdown::Support::ProcessMMD2XHTML($MMDPath, $filename, $data);

This way, I can update the xhtml of any page by calling mmd2web file.txt to generate file.html.

Obviously, it’s up to you to decide what you need to add to your pages to make them complete, and it’s up to you to manage your templates and cgi scripts. But this example should point you in the proper direction.

Of note, the pages I produce are valid XHTML, and I serve them as such to capable browsers in order to enable the MathML features. This does not work with IE. Additionally, if you use SSI in apache, you need to enable this in your Apache configuration.

An interesting benefit of this approach, since I upload the html and the raw text files to my server, is that visitors can examine the raw MMD source of any page by adding a .txt extension to the appropriate URL (sort of like what Gruber does on the Markdown section of Daring Fireball). To see the source of this page, visit my_web_server_setup.txt.

Using Git To Publish To A Web Server

I have begun using git (and GitHub) to manage my source code. It made sense to try and use it to manage my web site. This offers the advantage of automatic backups of every change I make, and the ability to revert those changes as necessary.

So I created a git repository on my local machine to serve as my working directory for the web site (in my case /Users/fletcher/Sites/mmd_static). Move the files you need to upload to your web host to this folder.

Do the usual git magic to commit your files, and you want to create a git repository on your server to handle the files you’re going to send. This should be the folder where your web files reside.

The trick is that you want to be able to push changes from your machine to your server, and have those changes reflected in the working directory. This requires a post-update hook (.git/hooks/post-update):

#!/bin/sh
#
cd /path/to/your/web/root
/path/to/env -i /path/to/git reset --hard

Obviously you need to determine the proper file paths.

This script causes git to force a reset of the working directory on the server after every push, causing your changes to “go live”. Obviously, this will overwrite any changes you have made on the server that were not pulled into the git repository. For me, this means that files that are modified on the server (e.g. comment files) are not stored in git. Therefore they are not overwritten. But it also means that I don’t have a local copy of those files.

Now, whenever I have tested a change locally, I do a commit and then a push from git, and my changes appear on my web server after a few seconds.

Other Tricks

There are a few things that I wanted to be more interactive about my site, such as comments. Also, I didn’t want to have to manually update the lists of entries by date. So CGI scripts handle that for me — they’re called by SSI include commands in the html files. I wrote some scripts to handle OpenID authentication as well as comment submissions. Hopefully I’ll get around to documenting these and release them, but it might be a while. There are more complete packages out there if you want something to plug in, and if you want something this basic you’re probably better off writing it yourself.

I also wrote a quick perl script to scour the archives and create an atom feed — since I am no longer using Movable Type, I had to create my own.

Summary

I basically have replicated most of the functionality that I desired from my Movable Type installation. The only thing I am currently missing is the ability to get email notifications of comments that are posted. I’m not sure what to do here. I looked into Disqus, but they have still not upgraded their javascripts to be XHTML compatible (after knowing about the issue for over a year?). Since XHTML compatibility is important (and necessary) for my ability to demonstrate the MathML features of MultiMarkdown, this is currently a deal-breaker for this site.

Similar Pages

• MultiMarkdown-CMS
• Colophon
• MultiMarkdown as CMS
• Ubuntu Virtual Server Walkthrough
• MultiMarkdown