CMS Search Update: The Winner
2024-03-20
949 words, ~7min reading time
What happened since December
The last update I gave on my search for a new content management system was some time ago. Last December, to be precise. I haven't aborted that project, though. Quite the contrary: I was active in narrowing down the shortlist.
I started by excluding TYPO3, Contao and WordPress. The first is too complex for my use cases, the second is too similar to TYPO3 for me to consider any longer and additionally too complex to implement the template, and the last one is too plugin-driven. That left me with Kirby and Statamic.
Trying out Kirby
Kirby looked very nice and customizable at that point: a system where I could design my backend/editing area in exactly the way I wanted without much trouble or any custom implementations. From my previous research, I knew that it had all the features and possibilities I wanted. And so, I started a Kirby project for my composition website. Considering the difficulties of migrating the TYPO3 template to Kirby/plain PHP and my missing knowledge regarding Kirby I progressed quite fast. And I got nearly to the point where I could start thinking about deploying a test instance.
But that didn't happen.
Trying out Statamic
I don't precisely remember what it was – perhaps the price of three Kirby licenses (I want to switch all my three pages to run the same CMS), the cumbersome contact form setup, or just pure curiosity – but I started playing around with Statamic a bit and instantly liked it. It seemed that many things that took me a lot of time with Kirby, were incredibly fast with Statamic. One part certainly was, that the template and content migration from TYPO3 to Kirby was already done and that I could use that earlier invested time. Another thing that made it easy to start was the integrated blueprint tool: instead of doing a lot of reading and writing a bunch of YAML files by hand, I could generate the blueprint configurations using a UI in the backend. Certainly, something that is not that much of a time saver (if at all) once one is more comfortable working with Kirby blueprints. Nevertheless, there is one thing where Statamic was objectively faster to set up: the built-in form functionality made it a breeze to set up a contact form.
So, I finished developing the new site using Statamic and ran a test instance for a few days. Afterwards, I deployed it to production, and it is still running: marcel-kapfer.de is currently served by Statamic.
After that, I decided to migrate this site to also use Statamic. And initially, I made very good progress.
But then I encountered a problem. A deal-breaker problem.
Encountering problems
To be precise, there was only one problem which turned out to be a deal breaker for me. Subsequently, I encountered another one which could prove to be at least a major inconvenience in the long run. It has to do with the page's main content. There seem to be two options for managing text: using the Bard editor or writing Markdown. Bard is the rich text editor in Statamic and rich text (whether block-based or block-less: I don't care) is what I want to use for my other two pages. Here, on mmk2410.org, I want to write in Markdown (well, I'd prefer org-mode, but that's for another day) and I have a very short list of requirements for this.
It even boils down to just one: Link to other blog posts and pages without having to navigate to the page using the frontend. Even nicer if it would be a permalink, though I could live without it. Statamic has that feature. But only in the Bard rich-text editor. The link button in the Markdown editor just opens an HTML text input box to enter the destination URL. Statamic even has internal IDs (URIs starting with statamic://
) which it could store and translate back to "real" URLs during the rendering process.
But it doesn't. I searched for plugins adding that functionality and also for issues and pull requests as well as the world wide web. But I didn't find anything. So, the only way would be to use the Bard editor for this site, too. Well, not what I originally intended, but you can't have everything. Like Kirby, Statamic is a flat-file CMS and so I looked into one of the stored YAML files (which have a .md
file extension for some reason) where I used Bard as the editor. The text output is not stored as HTML as I'd expected but as a YAML representation. For example:
-
type: paragraph
content:
-
type: text
text: 'This is some random text that is not styled at all '
-
type: text
marks:
-
type: italic
text: 'but this part is italic'
-
type: text
text: ' or not?'
Arguably, this certainly works. But I don't like such representations especially if the content is meant for the web and I don't have any interest in writing a tool that transforms my current posts and pages which are written in org-mode/markdown towards this format.
Quite sad, because other than that I really thought that I could work with Statamic smoothly although the rest of the backend is certainly not as polished as what one can achieve using Kriby. At least in my eye. You're opinion may differ.
Therefore, using Statamic is no longer an option.
A final decision
What now? Well, finally I decided to go with Kirby and just over a week ago I started migrating this website to Kirby. Astonishingly, I made very fast progress. Apparently, I already learned a lot during the first still unfinished migration and as of Sunday evening there were only some smaller issues to tackle.
Yesterday I bought three licenses during the current sale and just now I deployed my new site! Next on the roadmap is finishing the migration of marcel-kapfer.de and then creating an entirely new site for marcelkapfer.photography.
I would like to hear what you think about this post. Feel free to write me a mail!
Reply by mail