The current (2023–2024) iteration of sapphirepaw.org doesn’t use a full-blown Content Management System (CMS) or an off-the-shelf static site generator. Instead, it is derived from the original framework for the site, written when I was a wee professional programmer, and should never have been turned loose to make such things.
Making this into a bespoke static site generator was almost trivial, after one mind-blowing revelation. The PHP didn’t depend on the request, meaning I could pre-render the output pages!
There were a few issues to take care of in that first version:
- I had MySQL databases for a now-defunct project or two
- Links like
“typo.php”would need to be rewritten to “typo.html” to work correctly - I would ignore any page that didn’t produce output, like the framework code
file, or drafts (call
exit(0);before doing anything)
One conversion of MySQL to SQLite on my desktop, and one HTML5 parser🌎 later, I had something working.
When I brought the site back in 2023, I made another simplification: if I did
not intend for the PHP sources to be hosted, why not write the html form of
the link in the PHP already, and drop the whole HTML parser? Then1,
with the SQLite projects gone, sapphirepaw.org ran on a “generator” that did
little more than wrap a consistent header and footer around the main content.
I couldn’t simplify forever, though. To add the page counter in the footer,
/cgi-bin/ is excluded from pre-rendering, and treated as plain files. The
/cgi-bin path is a delightfully retro place to put it. It’s a throwback to
the days when server-side code would only be processed when placed within
that directory.
I’m not against static site generators on principle or anything. I chose Pelican🌎 out of a crowded field for my GitHub user pages🌎. I had also written “blog21”2 to power another (now-deleted) blog.
I also knew about content management systems. I had built a site for work on Drupal 7 (may it rest in peace) over a decade ago. I was also aware of WordPress and Joomla, and knew that people built real websites on them. Beyond those famous ones, I used to have Serendipity🌎 and Pixelpost installations here, before comment spam made them no longer worthwhile to deal with.
The Drupal site at work let a succession of “marketing partners” fill the place with junk, without involving anyone on our side. For that purpose, it did an excellent job. Also, they weren’t good enough at actual marketing that anyone looked at the output of their efforts, so it didn’t put any load on the server.
So why did I choose to hand-write HTML? It gave me full, direct control over
my entire URL space, markup, and styling. That is something a static site
generator or CMS can’t give me. They always want to own the entire space and
content beneath some root URL. Standalone pages typically end up under
/pages/ somewhere, like it or not.
I would just want it to be able to mix articles like these with the one-offs like 12-tone. Besides, having a chaotic URL structure that reflects the growing pains of the site makes it more authentic as a small, indie/retro homepage.
In the end…
It’s about being able to implement your ideas.
About a dozen articles later, just after starting this one, I got tired enough of HTML to rework the system on Twig templates. While I was there, I added optional Markdown support, making this the first Markdown-based article to be rendered. The irony thickens! ↩
Sadly, even though I used a Markdown parser, it was more lines of code than its inspiration🌎… but then, I had more features (previous/next links, for instance.) Because I already “knew” what a blog “should” look like. ↩