About my website
This website is hand-coded using HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), and SSI (Server-Side Includes).
Code Editor: Visual Studio Code
Dev Server: MAMP and/or XAMPP
FTP Client: Firezilla
For the sake of sanity and simplicity, I stopped using a CMS (content management system), and went back to the basics instead.
I learned how to code long ago, because Microsoft Front Page was trying to control my website. (Remember being leery of dependencies?)
Later, I used pMachine CMS, and then ExpressionEngine CMS, which powered my site for many years. I ran forums, comments, plug-ins, and multiple blogs on a single 1.x install. I didn’t upgrade much because it cost money, and it required a manual process that broke my site every single time. Eventually I had to switch hosts, which was a nightmare.
The process of backing up and moving a decade’s worth of blog content, while simultaneously updating an out-of-date CMS, was overwhelming. I’ve spent too many hours of my life on website maintenance, so I started searching for a straightforward, simple, and easy-to-use website builder.
ExpressionEngine was going through ownership changes, so I looked into Craft, Textpattern, and other database-driven content management systems. All of them were overkill for me. I longed for the early days of the web, back when my site was just a bunch of files on my desktop.
After doing some research, I found that a SSG (Static Site Generator) would output plain HTML pages, which seemed like the perfect solution.
All I had to do was choose one.
Which Static Site Generator?
Using ExpressionEngine for so long meant I had fallen out of touch with modern web development practices. To catch up, I read tutorials about SSG methodology: access the terminal command line to install packages to download dependencies to run software to hand-code my website using Twig or Blade templates (which turn into PHP), some flavor of Markdown (which turns into HTML), and Sass (which turns in CSS), then render the files and push them to a Github or Netlify repository.
Here are some of the static site generators I tried:
- Eleventy - never got it working
- Gatsby - never got it working
- Hexo - never got it working
- Hugo - never got it working
- Jekyll - got it working, but Github reliant
- Metalsmith - never got it working
- Middleman - never got it working
- Pelican - never got it working
- Publii - worked, but wasn’t for me
- Sculpin - never got it working
- Sphido - never got it working
My tolerance was low. I don’t enjoy using the command line, so that was a huge barrier. If things didn’t happen easily, I moved on. Markdown is cool, but it’s all over the place, and I like crafting and coding HTML.
Further research suggested that a flat-file CMS might be a better solution, so I began looking for a no-database, file-based CMS.
All I had to do was choose one.
Which Flat-File CMS?
My demands were reasonable. I needed to be able to make my own templates, control my code, and eliminate the maintenance vortex. My site is basically a conglomeration of microsites, so I wanted a modular, folder-based setup. I also wanted the CMS to get out of my way.
Here are some of the file-based content management systems I tried:
- Automad - not for me
- baun - not for me
- batflat - not for me
- Bludit - simple, but too blog oriented
- feindura - not for me
- Flattr - not for me
- FlatPress - not for me
- Flextype - not for me
- GetSimple - not for me
- Grav - too many buttons, bells, and whistles
- HTMLy - not for me
- Kirby - great for client sites, overkill for me
- Mecha - not for me
- Monstra - not for me
- October - cool, but overkill for me
- Pagenode - my favorite, almost used it
- Pico - not for me
- Publii - not for me
- Stacey - inspiring abandonware
- Statamic - I kept breaking it
- Sitecake - not for me
- TextPress - not for me
- TypeMill - not for me
- Typesetter - not for me
- Wonder - in-page editing, not for me
- Yellow - not for me
- ZWII - docs in French, not for me
Trying so many systems taught me a lot. I didn’t want to pay for a CMS again. I didn’t want to depend on software that might get abandoned, or that could break under a future version of PHP. I didn’t want to spend hours reading tutorials about how to automagically output HTML that I could easily code myself. I wanted less from a CMS, not more.
Two things became very clear:
- There is no perfect CMS.
- I wanted to write and understand every line of code in my website.
Using someone else’s software meant adjusting my information and/or website architecture to fit their methodology. I didn’t want to squish my content into pre-designed, fill-in-the-blank layouts, nor did I want an automated publisher forcing me to organize my data so it will work in that system’s pipeline — especially if it differed from my workflow.
There’s always a tradeoff. Gaining control in one area often means losing it in another. If a system is designed to blog, then I’m stuck with a post-pushing treadmill of a backend. The more flexible the CMS, the more I’d have to anticipate how to set it up for the various tasks it might perform.
Learning someone else’s software can be daunting — and that’s when it functions properly. When something breaks, troubleshooting is a slog. Using any third-party framework means being at the mercy of its developers, who can completely change things in a new version update.
HyperText Markup Language and Cascading Style Sheets are wonderful, but they are limited. To get beyond their constraints, I had to pick tools on which I’d ultimately become dependent. Instead of using another pre-built software package, I figured I’d go with a free, established language.
All I had to do was choose one.
Which Open-Source Language?
On a quest for minimalism, I set out to eliminate any extra steps between my imagination and the browser by creating basic PHP templates. Then I spent days building magic doohickeys (contact forms, email stuff, logs, etc.) in hopes of impressing someone (me) with code that folks would never see. No matter how much work I did, there was always one more PHP thing to learn, do, or fix before I could publish my website.
Instead of being inspired by PHP’s endless possibilities, I got lost in a maze of code with my website hanging like a carrot on a stick in front of me, luring me down yet another twisted corridor.
Luckily, the PHP rabbit hole revealed that I didn’t need the firepower of a full-blown programming language, nor a lot of backend processing at all. Being able to include one .html file inside of another would be sufficient.
I thought, “If only there was a really plain, easy, free HTML template language for building web pages, but without any bells and whistles.”
That’s when I remembered server-side includes (SSI).
SSI has been around for over 25 years. It’s a scripting language that assembles webpages on the server before sending them to the client.
After a ton of research, and a bunch of experiments, I chose to build my website with Server-Side Includes. SSI can do partials, variables, if/then statements, and more — plenty of flex for my needs. Yet, it’s minimalist.
Server-Side Includes in 2021 = ♥!