Writing easier with a small CMS

A few months ago I complained over how hard it was to write new posts here. However, while browsing Lobsters, I stumbled over a blog post from someone with the exact same issue. They pointed out Sveltia CMS.

What on earth is Sveltia?

Sveltia is a "headless CMS."

To start with, a "CMS" is a "Content Management System", which is a fancy way of describing a system where you can create/edit/remove all kinds of content, from files and images to pages and posts. Wordpress is a classic example of a CMS.

The "headless" part is that it lacks a backend, and does not care about what actually uses the files in the end. It integrates with a git forge (as of writing, GitHub, GitLab, and anything based on Forgejo or Gitea) and simply commits edited files.

That fact is extremely important to me, since I have that accursed customized Jekyll setup.

Deployment

Getting started wasn't the hardest thing in the world. "Installing" it was extremely simple, you essentially just create an HTML page which pulls in the JS bundle from unpkg.

The harder part was the configuration. Since Sveltia doesn't have a fixed backend, you have to tell it where media is stored, what collections of files you have, and what fields are in the files. As the configuration file is intended to be public, you can read it yourself.

I had to make some changes under the hood to accommodate Sveltia as well, and there are still some things that require me to, bare minimum, run that shell script.

1. The root of YAML files must be an object, it cannot be an array. This is largely not an issue, but my buttons.yml which defines the buttons at the bottom of every page was an array. I ended up just having to place it under a key.
2. You can declare "singletons" for individual files, usually for static pages. I ended up moving all static pages to a xpages collection instead. Why xpages instead of pages? Turns out Jekyll hoists all collections to the site object in the templates, instead of just keeping them in site.collections as documented. site.pages usually contains all pages on a site, but I accidentally ended up having that refer to the handful of static pages in that collection, whoops.
3. I haven't been able to figure out how to handle drafts. Jekyll special cases how posts are treated, files in _posts that have a name that starts with a date are published posts, files in _posts without a date are drafts, and files in _drafts are drafts. Currently, I have two collections, one for posts and one for drafts, and have to use my old shell script to actually publish those drafts.
4. You can declare that a field should point to a file/image, and you can override where they should be stored, and you can override the "public path" to that location. However, because you can set the "public path" to a blank string to indicate that it should be the same as the storage path in the repo, you can't make the actual stored path be without a prefix. This is usually not a big deal, in my case I just had to change the buttons template to no longer automatically prefix /assets/buttons/.
5. As changes in Sveltia is directly committed to the git repo, I can't do things like optimizing images before committing anymore. That means I have to run things like oxipng when publishing posts with the script instead, which will bloat the repo a bit.
6. You can't use template tags as the default value for image fields. This is annoying for my artwork, as I then can't preview the actual artwork when modifying the metadata.
7. Sveltia is, unsurprisingly, completely unaware of the template syntax that Jekyll has. This is annoying because I use the link template quite a lot, as it will resolve the final URL during the build, as well as cause a build failure if it can't find the file, preventing link rot.

Ultimately, despite these flaws, I think I'll get a lot more writing done. I can even easily add images now, so you'll never be able to escape my memes, muahaha.