WordPress, and CMS in general, make it easy for users to create both simple and complex websites quickly.

However, as the platform grew, it became more like a website generator than a simple blogging tool, trying to meet the needs of everyone and nobody at the same time.

Growing complexity, as well as plugins, themes and core updates, started to feel unnecessary for my simple needs: a blog authoring tool.

I don't need extensive features, but a simple, streamlined and efficient workflow for authoring content, and a static site gave me exactly that.

No plugins, no database, no need for constant updates, just plain Markdown files, ready to go live once parsed, with a full focus on content authoring.

Why I migrated

While I'm trying to write more, at least to remember things I did, my posting schedule has remained quite erratic.

On the other hand, I've been handling server maintenance regularly, which became a chore, as I felt like I was spending more time managing WordPress than actually writing content.

By switching to a static site, I could eliminate this time sink with a lower-maintenance system and care about my blog only when I want to publish a new post.

Another major reason was speed; static sites are inherently fast, as there's no server-side processing or database queries, each page could be fully cached and delivered straight from a CDN.

The security benefits of a static site are also difficult to ignore: without a DB or dynamic content, there's a much smaller attack surface.

If my server gets compromised for a reason or another, I could wipe it and restore the content in minutes.

No more SQL injections from poorly written plugins, complex DoS mitigation, or brute force attempts.

Lastly, I wanted to improve the authoring process.

The simplicity of managing plain Markdown files with a straightforward deployment process was extremely appealing.

Writing in Markdown would allow me to focus on content rather than presentation, stripping away visual distractions and formatting concerns.

The language restrictions could also help prioritize clarity over embellishments.

Plus, writing a fully custom theme with just a couple of files seemed better than dealing with the overhead and quirks of WordPress templating.

How I did it

When I started considering the switch, I was already aware SSG tools existed, so I explored the most popular tools I could find: Jekyll, Hugo, Eleventy, and others.

These solutions all seem powerful enough and relatively widely adopted, but, as I dug deeper, they didn't quite fit what I was looking for.

I didn't need to replace an okay-ish workflow with another one, I knew exactly what I was looking for, and I didn't want to spend time compromising with what I had in mind to make it fit a certain workflow.

I had a couple of days in front of me, which seemed more than enough to write my own tool, so I wrote my own tool.

At the core, it's a simple PHP console app, and my needs were pretty straightforward:

• A template engine to generate the HTML pages: I was already familiar with Twig, so that was a done deal.
• A Markdown parser: The PHP League's league/commonmark is a good choice, and it's the one Twig did for me, so ... done deal too.
• And just because I'm extra lazy, a console app boilerplate thingy: symfony/console.

And that's it, give it a couple of hours, and everything is ready to go (you're currently seeing the result).

The theme is made of 2 main templates, the "default" template, which is the main page wrapper, and the "post" template, which extends the default template to display posts.

I tried to keep the idea of the visually lean WordPress template I had and translate it to something a bit better with a light/dark theme and flexbox everywhere (I mean ... Tailwind did most of the job for me).

There's nothing really fancy about the code, the whole codebase is about 500 LoC, and the UI is made of two commands:

• ssg generate <conf file> takes all the Markdown files, processes them and renders the Twig template. It's also generating the home page, the sitemap, the metadata and a couple of other things I don't want to touch manually.
• ssg deploy <conf file> is a simple wrapper around scp -- "wrapper" is loosely used here, the command just makes sure my config file doesn't do something stupid before pushing the trigger and calling the scp binary.

What's missing

Pretty much nothing, for now.

I'm planning on adding back the RSS feed, which is just another quick template to write.

There's no comment system, I don't really want to add it back right now, but if I were to do so, I'd use Disqus or similar.

I used to have a pretty basic plugin for stats, and I don't really care about it.

If I ever wanted/needed to extract stats, I still have a couple of ways to do so: parsing the server access logs and checking my CDN stats.

The main point of friction right now is the embedded contact form, I'm not entirely sure that I need it, but I replaced it with a Crowdsignal form, until I have a better solution (or just strip it off).