Moved to Jekyll

I have moved this blog to Jekyll.

Why

The main catalyst for this change is security. I had previously been using WordPress (since 2008) and while it has many features, it has simply been a security nightmare. My WordPress site has been hacked multiple times, each time requiring multiple hours of my time to undo the evil. Looking at the hacks closely, I’ve come away feeling the WordPress architecture (especially the plugins) needs to be redesigned from the ground up (with security-first design). The idea of a static (and secure) site has always been my goal, so I’ve been following the maturity of static site generators for years. I decided it was time to jump.

What

Here’s what Wikipedia says:

Jekyll is a simple, blog-aware, static site generator for personal, project, or organization sites. Written in Ruby by Tom Preston-Werner, GitHub’s co-founder, it is distributed under the open source MIT license.

The key phrase there is “static site generator”. Jekyll is a platform which is used to generate complete, fully-formed web pages/sites before going live on the hosting server. Effectively pre-compiled rather than just-in-time (eg. PHP/WordPress).

I knew I wanted a static site generator. I did a deep dive into a few top contenders, but decided on Jekyll because it is popular (and thus has support/themes/etc) and flexible. Having something I can tinker with is important for me. I also considered the GitHub Pages integration as a possible solution, tho I ended up not going that route.

How

It was far more difficult to migrate from WordPress to Jekyll than I had anticipated.

I have over 300 blog posts going back to 2003, so I had to first build a scriptable solution for extracting and converting my posts to Jekyll’s markdown (kramdown) format. Unfortunately, automatic convertion of pure HTML to markdown is full of problems. I ended up with a cobbled-together set of scripts and some manual intervention to get the final post files in a workable state. There are still broken links and missing images in some posts, but nothing systemic (I regularly use linkchecker to find problems).

Once I had the core dataset converted, I focused on the surrounding platform. Initially I was going to use GitHub Pages site with Jekyll, but found some of the limitations too restrictive (eg. supported themes), so I landed on self-hosting. And I felt I would learn more detail, at least initially, if I built the site from the core Jekyll without the turnkey GitHub abstraction. Maybe once I feel I understand the details, I may look at GitHub Pages again.

For the general look-and-feel I knew I needed a theme, thankfully there are many. The quantity and cost of for-pay themes was surprising (some themes are over $100), but there are plenty of free ones. I settled on using Minimal Mistakes theme. It’s popular, has active dev, and rather simple – but also a big upgrade from the default minima theme.

As part of this effort, I also wanted to formalize the build/test/push process of the site. The structure of my site is one top-level jump page (manjourides.com) with one or more second-level sites (eg. scott.manjourides.com). While both the jump page and all the second-level sites could be hosted under one server, I wanted to allow for each site to be hosted independantly. This means a separate build/test/push for each.

Although I decided to have each site component separate, keeping the process consistent was important. To this end, I have each component include a Makefile with identical targets (ie. build, push, etc). This allows a meta Makefile which recurses for the common targets. At the outer-level a simple make push will build and push all sites regardless of hosting. Very convienent.

Technical Summary

Blog site (scott.manjourides.com):

Jump site (manjourides.com):

  • simple hand-coded HTML/CSS
    • custom Javascript email obfuscator (inc Python generator)
  • snow - custom site build system I wrote using Bash 5.0.3
  • plow - custom site push system I wrote using Bash 5.0.3
  • Plausible analytics

Infrastructure:

Some may be wondering about CI/CD. No, for now the cycle is manual (tho, a very simple process). Maybe eventually I will automate, but I’m happy without for now.

Conclusion

Removing WordPress/PHP from my site makes me feel warm and fuzzy … er, more secure. Learning new tech is always a good thing. Overall the experience was more effort than expected, but I had fun and I’m pretty happy with the result.

Remaining Problems:

  • Creating new posts has too many hoops (file name format, Front Matter, etc)
  • snow does not have integrated local dev server (yet!)
  • boring landing page

EDIT: Site is live at 2020-07-26T17:05:19-05:00