After nearly a decade, I have made the switch from WordPress to a static site generator. When I first fired up my personal blog, I had such high hopes for the possibilities it afforded. My hope is that this reboot breathes new life into my technical blogging.

Background #

I could build a CMS in PHP, or so I imagined. Then one day in 2011, I decided WordPress would be good enough for me. For a time, it was. I managed to optimise the death out of it over the years; adding reverse proxy caching, backend caching, opcode caching. I managed to get sub-200ms responses for the entire site. Sadly that stuff is all a nightmare to manage. Varnish needs memory for cache storage, and didn't support TLS connections^[1]. That necessitated another reverse-proxy to terminate TLS, which was initially Pound and later HAProxy. These are all worthwhile technologies to learn. I've used a lot of the knowledge I learned at work. For a simple technical blog though, it's way outside of the realms of simple. After ripping most of that out, we are left with mostly sub-second latency — which I was okay with.

The next problem is with WordPress itself. It's a piece of relatively complex software which executes on a server. Whatever your opinions on the underlying codebase, this is a risk. At least it is maintained, and the updates can be completely automated. Plugins however are not always so well supported, and sometimes carry security risks of their own. I am lucky that my blog was never caught up in any automated exploits — to my knowledge.

Finally—and I feel most importantly—I didn't enjoy the experience of editing in the WordPress UI. It has changed somewhat over the years, including the switch to the Gutenberg page editor. I think I used it a couple of times in the end. I just want to be able to write some words about some code; a new research topic. Markdown is perfect for this pursuit, in my humble opinion.

Compromises #

Naturally, moving from a dynamically generated CMS to a statically generated one exposes some limitations. You can overcome these using client-side rendering, or just don't do the things in the first place. I mean, did anybody really care what Steam games I was playing or music I listened to at any given time? I very much doubt it, other than maybe the people selling the games or streaming the music.

IPv6 Support ✅ #

Gitlab Pages doesn't support IPv6^[2]. Though to be fair, neither does Github Pages. The site employs Cloudflare for DNS; after enabling their proxy, the site is now available to end-users on both IPv4 and IPv6 networks. I may have to keep an eye on caching issues with pages though now, for the time being.

Content management ❗️ #

Moving to a static generator, the whole system relies on a CI/CD pipeline to generate and deploy new content to the site. There's no CMS interface to edit content, it's all Markdown in a git repository. This presents a barrier to content publishing; whilst welcomed in some respects, I consider it a bit inconvenient. Thankfully there is a W3C standard for that. I am researching methods to implement a micropub endpoint, which will allow a standards-based approach to content management. More on this soon, hopefully.

Search ❗️ #

I have yet to implement a client-side search solution for the blog. Of course, the site is public and should maintain rankings in SERPs from the old website. I put a lot of effort into the migration of content, particularly in maintaining archive-content permalink structure.

A potential solution comes in the way of Lunr. It's a simplistic weighted search based upon Solr, and relies on a pre-generated index. I plan on adding a search result page to incorporate this, as the index may become quite heavy.

Bookmark Favicon Support ❗️ #

One of the small things which I put loads of effort into; Dynamically loading and caching favicons from link-type posts. These would be included anywhere the link post was displayed, such as the link widget or Links category. It was a nice touch, in my opinion. I'm looking at options for how this functionality could be incorporated in a performance-tolerant manner. Possibly using a file-based database like sqlite.

Examples ❗️ #

Some of my older posts included PHP examples which were deployed to a directory on the host I shut down yesterday. These will now be broken. Soz m8. I may push them to a repository somewhere...

Comments / Pingback / Trackback / Webmention ❗️ #

I've dropped comments from the site. They have not been migrated, and they are not planned to make a comeback in the near future. Whilst I appreciate feedback, I'll find a better way to incorporate it in a more indieweb fashion. None of the above are incorporated into the workflow at this point.

To-dos #

I've set up a hit-list in the form of Gitlab issues, the top of which are Accessibility and Metadata. This was released as an MVP, once I thought that I had done just enough to ensure that content was migrated well enough to be passable.

• Accessibility changes; whilst it's quite simple in nature, I need to undertake an accessibility review to ensure that my content is accessible to all.
• Metadata improvements; I haven't added twitter card or opengraph tags, amongst other things that I probably should have.
• Mobile / desktop improvements; the site was built mobile-first, but very little has been done to ensure an optimal experience other than spot checks.

I'm quite happy with the results so far, and there is so much that could be done. I'm happy with where it is right now, which is great progress.