Choosing a headless CMS for my simple static blog
When you use a “traditional”, or “monolithic” content management system (CMS) such as WordPress, your content editor, data and the website itself are part of the same package. Installing WordPress on a server gives you access to a “back-end” (by default, reachable at
yourwebsite.com/wp-admin), where you’ll create your pages and posts, which will in turn form the website itself (reachable at
Static site generators (SSGs), such as Jekyll, Hugo and Eleventy, are not CMSs. Think of them more as a script that you run from a command line. This script will typically convert a collection of files into a website, which, if you’re running the script on your computer, will need uploading to a server.
In order to create a new page or post, you can’t visit a “back-end”: there is no
yourwebsite.com/admin or similar. Instead, you’ll have to create and edit your source files, run the script and then get the generated files onto a server.
We can therefore see traditional CMSs offer two advantages over SSGs:
- The ability to create and edit posts and pages easily and with little or no technical knowledge
- The ability to create and edit posts and pages from anywhere with a web browser
As SSGs gained popularity, companies saw an opportunity to provide CMSs for static sites. Services like Forestry, Contentful, Cloudcannon and Sanity allow website editors to login to
forestry.io and enjoy easy-to-use back-ends and remote publishing on static sites.
Furthermore, these “decoupled” or “headless” services offer three possible advantages over traditional CMSs, such as WordPress:
- Becuase your content and the system that manages it are separated, it’s sometimes easier (in theory) to copy and move your content.
- Some headless CMSs work by serving your content as
json, which your SSG will use to build the website itself. You can also use this
jsonto build other services, such as an app. One CMS can power several services concurrently. Note that WordPress has offered an API for several years, thereby offering the same functionality (and making it a traditional and headless CMS at the same time).
- Some headless CMSs can scan your existing static site files and infer your data structures, thereby making it easier to create and manage custom data types than in some CMSs, such as WordPress.
I’m looking for a little or no config CMS
Unfortunately, my CMS Forestry will be switched off and become Tina soon. Add another advantage to traditional CMSs: even if development ends, you’ll still have a CMS sitting on your server.
This is obviously a personal thing, but spending time configuring or even installing a CMS seems too much like work to me. The beauty of Forestry in its pre-Tina incarnation – which I’ve used for years – is that you visit forestry.io, give it access to your Github repo and that’s it – it works out your content types from your folder structure. To add or edit a post or page you log back in to forestry.io and use its back end.
There are optional configuration options so you can tell Forestry what non-standard meta data to add to your content, and what form elements to use in its UI (for example, it has date pickers and dropdowns), but you set these up in Forestry itself.
Tina, on the other hand, requires installing software that you add to your file store. It’s not difficult for someone who has gone to the lengths of installing an SSG, but it’s another technical part of your stack to manage. And it is more work.
Headless CMSs broadly work in one of two ways:
- By storing your content and making it available as
json, which your SSG then uses to build a website, app or whatever. Sanity works in this way.
- By directly accessing your online file store, and adding, editing or deleting files there. Your file store could be Dropbox, Drive or, most likely, Github. Forestry works in this way.
As the first option entails setting up your content with a third party and then getting your SSG to generate a site from
json, that’s a non-starter for me: it would entail re-writing my website from the ground up and getting the existing content into the new CMS. This method is better suited to organisations with more complex requirements and more resources, who are looking to edit a data store for use across websites and apps.
So I want a “file store” CMS. The other main consideration will be how much configuration is involved, or whether I need to install anything at all.
As headless CMSs become more sophisticated they require more configuration; too much, perhaps, for a simple blog. So it’s maybe unsurprising that the best post-Forestry solution I’ve found is Prose, which is, as far as I’m aware, the oldest headless CMS of all, and requires no configuration beyond giving it access to your Github account.
Prose provides a simple front end for editing Github files and committing any changes you make. That’s all it does; unlike Forestry there are no configuration options, so if I wanted to set up a front end for adding meta data to posts I’d be out of luck. Instead, you add YAML in key value pairs, much as you do when editing a text file.
Despite (or maybe becuase of) its simplicity, I think Prose is the most elegant solution for my site. By just offering a way to edit your files, it respects the way you’ve set up your site – there’s nothing to configure or install. But if I am missing a better option, do leave a comment.
Consider subscribing to the RSS feed. That way, you’ll get notified whenever I post anything new. If you’re not sure about RSS feeds, I wrote a guide to RSS.
Make 2023 the year you help destroy Twitter Previous post
Next post When humans write for machines
Add a comment
What you’re after can easily be achieved with getkirby.com which is what I use to power my personal site for example.
Doesn’t rely on 3rd party services (unless you count hosting and domain as a service) and can be used as a headless cms if you want to go down that way.
But it also has a very simple admin interface you can use if you want to use it to write markdown.
Or you can just create folders and .md files and keep everything in sync with auto deploy through github.
That’s up to you.
Thanks. I used Kirby many years ago and it was great then – there’s also a ton of new stuff, I see.
I really should grasp the nettle and move to a system that does all this stuff out of the box, rather than force a static site to do things it’s not designed to do. I might then start writing about other things than getting a blog to behave like a blog.
Well, I’ve been using Jekyll for 10 years. Back in 2013, speed really was a problem if you were using WordPress on shared hosting, as was having your website hacked to sell viagra or whatever. But yeah, I doubt it’s a problem with a flat file CMS in 2023.
The other strength is the ease of creating custom data types and fields and outputting them to the front end (on this site, that’ll be notes and links and the associated meta data). You can just add something like
link-url: https://manuelmoreale.com/shared-understanding to a Markdown file and it’s available as
post.link-url in a template. But like you say, you can do that in Kirby too, and just keep everything in text files.
It has improved a lot in the past few years. A lot more flexible and powerful.
Also, I don’t personally see the appeal of a static site generator when you have to go through a 3rd party middle man of some sorts.
Unless you have a setup that lets you publish directly on a server you own, I don’t really see the benefits.
Some say speed but honestly, my current setup so a filed based cms with cache on an inexpensive VPS running nginx loads in 950ms with a server located in NYC and tested from Australia. So that’s the absolute worst case.
And most of that time is just light running through cables across the globe.
Kirby also very recently (a few days ago) released a new cache plugin that generates essentially static pages of your site.
So defintiely give it a try if you’re in the market for a replacement cms. I speak just as a happy user of the product. It powers my site, it powers my side projects and I used it for almost 50 client sites at this point and I personally couldn’t be happier.
Situations like this are why I elected to just write plain HTML. Eventually, developers will pull the plug on your authoring tools or even the static site generator itself. For those who can’t bear the sight of an HTML tag, there are tools like Pandoc that afford us the option of writing in Markdown or working in a variety of other file formats. If Pandoc were to suddenly disappear, you can still fall back to plain HTML without suffering too much of a hiccup in your authoring process.
That being said, working in HTML or manually managing most of your site can be quite a pain if you want all the fancy bells and whistles to make your site “indieweb compatible.” The build process in static site generators seems extremely convenient for managing full text RSS feeds and automating several tasks that I have to do manually, like sending mentions.
As I’m sure Manu would agree, you don’t need all the webmentions stuff, but RSS is a must. Jekyll handles all that really well as you just loop through collections and output text that you have full control over.
Yes, we’ve mentioned this before, I think. HTML with includes would be great. Having said that, it’d be pretty simple to come up with a PHP (or whatever langauge) system that stitched together header, content and footer files, and even handled a few variables.
Kirby does look very good, though. I like the fact you get a choice of just dealing in text files or in a CMS. For a start, that would make migrating over a process I could do in stages. And I could presumably just integrate my current text files for comments, posts and whatever.
Comments and replies to this post from other sites and services, such as micro.blog and Mastodon.