Switching to Pelican

Fri 19 February 2016
tags: meta

When I first set up this website I was using a set of hand-rolled scripts for generating the HTML from posts/pages written in markdown and Jinja templates. Recently I have come to the conclusion that although my initial aim was to avoid complexity, in reality the system I was using was probably too complex. Given that it's almost always better to use somebody else's well-implemented solution rather than re-implement your own unless you have a very compelling reason, I've decided to switch over to using the Pelican static site generator for this purpose. Although I could have used any of the myriad static site generators, I decided on Pelican due to the fact that it is written in Python (hence it will be easy for me to hack on it if needed), seems reasonably well maintained, and Jake Vanderplas already succeded to use it for generating blog posts from Jupyter notebooks, which I want to try out in the near future.

I also took this opportunity to change the look and feel of the site. I honestly don't know why I thought the previous theme looked any good (see below for a screenshot), but I feel the current theme has a more timeless and professional look. The basis for the theme HTML is the simple Pelican theme. I use Skeleton for the base CSS, which includes a simple 12 column responsive grid layout. The font used in the logo is Fredericka the Great from Google Fonts, the body text is Montserrat, and the headings are Libre Baskerville.

old website

The comment engine has also been changed, and I now use the Pelican comment system plugin. The basic idea is the same as what I had before (i.e. I receive the comment as an email), however now there is no PHP sitting server side that sends the emails. Instead, visitors fill out the comment form and then some javascript generates a mailto link with the body already filled out. All the visitor has to do is then check that everything is OK and hit send. I think that this is the best of both worlds, the only downside is that people who want to comment need javascript enabled to be able to do so. One slight gripe I do have with the plugin is that the comment content is not escaped when it is rendered into HTML, so people can in principle inject javascript into my blog pages in comments. In practice this probably won't be too much of a problem, as I have to explicitly add the comment to the website source, recompile and upload the output to my webserver, so it is unlikely that I would miss such an obvious attack, especially with the low volume of comments the blog receives.