Recently, I switched from Wordpress to a static site generator – Pelican. Here are some of my experiences. If you don’t want to read the reasons and the techbabble , scroll down and read the summary.
Static site generator?
The best known static site generator is probably the ruby-based jekyll. As the name suggests, the sites are »static sites«, which means html files that could as well been written by hand – which would be a chore.
The interaction is different from a CMS like Wordpress. Whereas Wordpress uses a web-based administrative interface for writing content and changing settings, static site generators use files and command line. They take your post’s text as Markdown or HTML files in a and use them to generate the HTML files, complete with links, menus, list of articles by author or tag etc. It seems nerdy, but is not hard to use, since there is no programming required: You put all your posts in a "posts" folder and edit the settings file to match your preferences, then you generate the site by typing make html at the terminal.
Why?
I did not know how to write my own templates in Wordpress and assumed this would be easier if I used a Static System (This is probably an unjustified belief). In addition, I was annoyed by the updates Wordpress needed regularly. Wordpress updates automatically but nevertheless, static pages are much harder to attack: No backend to login to, no input fields for Cross-Site-Scripting attacks.
Getting stated
I started with the default config and default theme. In particular the default theme is fairly basic, so learned ho to get something more stylish. The answer (it’s usually the same): Edit the settings file. In this case: Set a path to a folder with a template (which are called Themes for Pelican.
First impression: There are many themes. Second impression, after trying a few: Many are from programmers for programmers. Almost all themes have a syntax highlighter integrated (nice). But I wanted subpages/nested menus too. And images with captions. No theme I found had that features but it can’t be to hard, can it?
Getting my handy dirty
Menus
Every content you feed into Pelican can have custom metadata attributes. Metadata can be (ab-)used for whatever you like. So I used it for nested menus and created a pagegroup attribute. And started to write a template which could use it. Great.
I looked at many other people’s themes and templates (themes are the complete style of the site, templates define the structure of the html and content) to get to know how they work. And I read lots of Jinja’s documentation – the templating engine used in pelican. Not everything worked like expected, so I started to debug pelican (use --debug on the command line for light cases and winpd for in-depth stuff), to find out which values were available in the templates. There is documentation on this but I saw that many themes were using values I could not find there (or used values attributes which I did not know). That was not too hard, but needed a bit of learning about debugging Python applications.
Captions
That’s a tough one. Turns out, it’s not Pelican’s fault that images defined in Markdown can’t have captions. The special pandoc-Markdown dialect I use allows to define captions. But the original Markdown and thus the Python markdown interpreter does not have image captions. Damn!
But one can write extensions to it… Long story short: My first Python program is a Python Markdown extension which generates image captions like Pandoc. That escalated quickly. I actually wanted to blog…
Blogging
After all this technical adventures in unknown programming and templating languages I finally felt that the basic needs were fulfilled and started blogging. This is actually rather easy: For a new post you create a new plain text file, write the content with any editor you like and add some metadata at the begin like »Date: 24.7.2015 10:32« etc.
Images go into another folder, you link them in your text.
When you want to update your blog you can use one of the upload options on the command line – make rsync_upload requires you to define a server (where? – in a text file) and then uploads only the changed content. Very useful. All the publish commands use the specific publish settings (in the publishconf.py file) since your local try-stuff-out settings might be different. They must be set once, but it is not difficult.
Styling
While I wrote the theme before I started blogging, there were unforeseen requirements and ideas that popped up while working with the system. It is very easy to accommodate these: Change the CSS of your theme, then regenerate the blog. If you are up to changing themes you can add your own classes/IDs, too.
Summary
Switching to Pelican was fun so far. But since Pelican does not hand you (almost) everything on a plate (like Wordpress), customizing the messing functions was some work. Naturally that would have been less difficult if I’d known Python and Jinja before. On the other hand, it gave me a good reason to start with those.
It is very nice to be able to customize many things and generate good old html directly – the whole system seems more transparent to me than Wordpress which pleases my inner programmer/maker/designer.