In my last post, I said that I have moved to Zola from Wordpress. In this post, I thought I would share a few reflections about how that went.

I had decided up front that I was going to move to a static site generator, because of the flexibility that this gives me in terms of the site hosting. I quite wanted skmething fast because, well, fast is better than slow. I looked a Hugo which is a main contender in this market. It looks nice, but I found the documentation unclear. In the end, I went for Zola because the documentation was pretty clean. I also liked it because it is implemented in Rust and I know how to code that and this is often useful with any tool that you are using. My main worry was that Zola has an “all in one binary” ethos; I can see why this is important, but it also means that it’s effectively unextendable except through templates; what you see is what you get; so, perhaps, my Rust knowledge was rather irrelevant in this light.

In use, I found that it did largely do what it says. It’s simple to get running, it produces a nice website. The metadata and text input is all markdown so relatively simple and straightforward. I thought my Rust knowledge was going to be useless but, actually, I did need it because I needed to hyperlink between anchors defined in html which Zola wouldn’t do otherwise.

The main drawback is that Zola is not as rich an environment as Wordpress and cannot be freely extended other than with it’s own template library. For example, in Wordpress, I had kcite for building reference lists. It was obvious that Zola templates were not going to be enough for this, so in the end I prompted for a hybrid solution. The markdown that Zola processes is all actually generated using pandoc. This somewhat negates the point of having a fast processor, although that’s still good if I change the template. I guess I cannot criticise Zola for this; it’s meant to support a certain kind of website and the academic extensions that I have added to Wordpress are not widespread requirements.

On choosing the theme, however, I did dig up an area where I think Zola is lacking. The themes unfortunately conflate appearance and functionality. For example, I wanted Mathjax functionality (or KaTeX, which ever). This is not provided by Zola natively, but can be provided by the themes; it just involves injecting some Javascript and adding a shortcode. But if you want this, you are now limited to picking only those themes with Mathjax or KaTeX support. It’s not possible to combine pre-bundled Mathjax support with any theme. This is something that Wordpress supports, with plugins and themes; while the separation between the two is still not perfect, it works most of the time.

This also impacts on the authoring experience; for example, several themes add KaTeX support. From the web side, they do this in more or less identical ways, but author side, turning the functionality on uses different configuration. I am not entirely sure how this could be addressed, but it does seem to me that adding something like wordpress plugins could work. These would add shortcodes and tera macros, but no actual themes files; this means that themes would need to support a given plugin. It would be possible to generalize this, though, by adding some standard hooks that could be called by a theme to support multiple plugins.

Alternatively, I could just wait till someone produces a theme that I like and has the functionality I need. This might be the easiest solution!