Moving to Pelican

Published: 2014-10-18

In search of a simpler blogging framework, and intended to ditch PHP, I have tested multiple static site generators, settling on Pelican. Unlike Pico or Phile CMS, Pelican generates fully static content. So no dynamically rendered front page - which taxed my poor Beaglebone Black the most.

Of course, every migration comes with its pros and cons, so I'll list them up here.

Pros

  • Fully static content, so minimal load on your HTTP server, and maximum security.
  • Smaller footprint.
  • Supports Markdown just like Pico or Phile, but due to some idiosyncracies you might need to modify your files slightly, e.g. further indentation for nested lists, or code blocks.
  • Templates can be easily modified even if you don't know Jinja2, the code is highly readable.
  • Supports authors, tags and categories, but it also insists on rendering the cruft that comes with it, also if you don't use it.

Cons

  • Due to being a so-called static site generator, you need to regenerate your content every time it changes (you can have Pelican monitor files in the background so this is done automatically, though). This is inherent to how static site generators work, so it's not a Pelican flaw.
  • Pelican flattens all the output, keeping one directory (with some subdirs for drafts, author info, categories, etc.). Unless you start hacking the Python scripts, there's no way to organise your posts other than in blog posts (ending up in the top dir) and 'pages' (which are considered more static, are not indexed on the front page, and end up in their own subdir pages/). Since you're not editing the HTML files directly, but the source files, you can organise those, so it's not that big a deal. But I like my HTML to be manageable as well.
  • Unlike Phile and Pico, it does not strip markup in the post excerpts on the home page. It looks like it's going to be a bit of an ugly hack to get that. Again, minor, but I like a clean layout, especially on the front page.

Remember to edit the links in your source files to point to .html files, rather than the extensionless URLs you could use with Pico/Phile.

My workflow is: write locally, push over SSH to the server. If you want to keep your existing CSS, you'll have to hack the templates a bit, and modify the CSS here and there, but I'm no pro myself and I managed to get it done, so it's not that difficult. Render a page, look at the HTML code, and you'll see what CSS calls are made, and what you need to adjust. If you'd like to use my theme, you can grab it here.

Like with Phile, I have resorted to a wrapper script that handles most of the stuff. It's contained in a small Bash function:

pelican-generate() {
  # Hardware pages, to be moved
  HARDWARE=(beaglebone-black desktop hardware hp-6510b htpc laptop server sony-vaio-tz190n \
            tl-wr1043nd tl-wr1043nd-v2 tl-wr841n wl-500g-deluxe wndr3700)

  # Clean out old HTML, then regenerate
  cd ~/blog
  rm -r ./output/*
  pelican

  # Move hardware pages into subdir
  mkdir output/hardware/
  for i in "${HARDWARE[@]}"
  do
    mv output/pages/"$i.html" output/hardware/
  done

  # Remove stuff we don't need and transfer final content
  rm -r output/{author,category,feeds,archives.html}
  scp -i ~/.ssh/id_rsa-beaglebone -r output beaglebone:~/
}