A new home

Short version: I finally have a new blog. It only took me around five years, because of deadlines and an enormous unwillingness to decide in favor of a system.

After years of fiddling around with ProcessWire, Statamic, Craft CMS and other systems it came down to Backdrop CMS or Drupal. I decided on Drupal. Will I question my choice in the near future? I already do. Will I spend the next five years looking for a better system? I am always looking for other systems. Will I switch to another domain, because talesof.me is so incredibly generic? Maybe.

But for the moment this is it. More content to come. More features as well.

And now for the long version. Aka why the hell does it take so long to pick a system for a simple blog?

Drupal: Base of operations

Most of the projects I have worked on since 2008 were made with Drupal. This is the system I know best. I even wrote a book about Drupal 7 (in 2011, long long ago). So between 2010 to 2016, I had a blog built with Drupal 7. It made sense.

By the end of 2015, the first Release Candidate of Drupal 8 came along. There were a lot of improvements and new features. But I wasn’t happy with the direction. Mainly for three reasons:

1. I didn’t like the new template engine Twig (in combination with Drupal). I still don’t. But this is a rant for another time.
2. Compared to other systems updates in Drupal 8+ are way more complicated. Back then I didn’t want to use the command line for stuff. That changed over the years because of Git. But command line updates are still more annoying than click-here updates in other systems. (Drupal is working on Automatic Updates.)
3. But most importantly: I had a lot of smaller clients. And Drupal 8 was just too demanding for them. As in: I couldn’t use Composer in any of the smaller web spaces.

So I was slowly drifting away from Drupal. I needed a new system for my blog. But also a new system for my smaller clients. All while still working mostly with Drupal 7 in my projects.

WordPress: Works well. But!

If any non-developer would ask me how to start a blog, I’d tell him to buy a domain, and some web space, install WordPress, choose a theme – and start typing. Easy to implement. Easy to use. Ideal for blogs.

So in the summer of 2016, I did just that, I installed a WordPress blog. I already knew the system, I just hadn‘t used it in any of my own projects. This was good enough for a measly 19 posts till the fall of 2019. But I never felt at home with WordPress.

Coming from Drupal I expect a system to support custom content types and custom fields. I don’t care that you can add stuff with modules. I expect this to be in core! Every other modern system does this in core. Well, at least the other systems in this post. Only WordPress can’t be bothered to add these features. Really, I can’t take this seriously!

At the time I wasn’t sure what to make of the shift to Gutenberg editor. I still don’t know if this was a good direction. But a lot of people like Gutenberg. Some like it so much that they ported it into a Drupal module. So, maybe it’s ok? At least it wasn’t a no-go for me.

But. Then there are the modules. In Drupal almost all of the modules are free. In the last 15 years, I only once needed a paid Drupal module. I don’t mind buying stuff. But WordPress modules are a screaming mess! Just present your features and then let me decide to buy! There are just too many colors and alert boxes on some of the useful free versions of modules.

Also, with thousands of themes around, I just installed a theme and never built my own. But as a frontend web developer sooner or later you want a build a theme yourself.

Bottom Line: WordPress is good and well for other people. But it is not for me.

Minimal requirements

In 2020 I wanted to build my blog from scratch, with a new system that was neither Drupal nor WordPress. Minimal requirements: The option to build custom content types with custom fields, some kind of asset management, and a system that entices the developer to build a theme from scratch.

It’s January 2025 now. It took me around five years to publish this version of my new blog! Why? Because I am an idiot. Well, that, but I also wanted to try out some new systems. It wasn’t just about picking a system, and building the blog. As I wasn’t happy with Drupal 8 I was looking for another system for my smaller clients.

So every now and then I searched for CMS or someone praised his new favorite or I just stumbled upon a video on YouTube. Let’s meet the candidates I actually tested. As in: I spent at least three days with the software and built a small website. In some cases, I also wrote an article about the system. Which forced me to dig a bit deeper into the system than I might otherwise have done.

Kirby: Flat and neat

Kirby CMS is one of the better-known flat file systems. Especially here in Germany, since the system is mainly developed here. I know quite a lot of web developers who like and work with Kirby. So in Spring 2019, I decided to take a deeper look. I relaunched a website with Kirby and then wrote two articles for PC Magazin about it.

The system is not free. It costs 99 Euro for a Basic Site or 349 Euro for an Enterprise Site. Which includes 3 years of feature updates. That’s quite fair.

There is a lot of stuff I like in Kirby. You write the theme from scratch. No div or class you do not want. You can easily collect the content you need. If you need a list with all blog teasers you can do this with a few lines of code. You can easily set up content types with different fields. You can also modify the position of the fields for the user UI – or put them into tabs. And the documentation is also quite good.

But. In Drupal, I can click together a form with the module Webforms. In Kirby, this is not as easy as you have to juggle different templates and write code yourself. Possible, but quite some work if you need different forms. Also, Kirby did not have built-in asset management. You could handle assets like content and write an asset management yourself. In this case, it could be easily finetuned to your needs. But again, you have to put some effort into it.

Bottom line: I understand the appeal. But let’s look around some more.

Eleventy: not for me

In 2019 lots of people were talking about static site generators. I didn’t see much use for this for my own blog or client sites. But I have a few small sites like kurzweiliges.de, a website I haven’t touched since 2006, which could use an update and maybe a switch to a static site generator. So in fall 2019, I decided to test Eleventy. Again, I built a small test site and wrote an article about it.

It’s easy to learn. You can switch an existing site with a few dozen pages to Eleventy in a few hours. And a static website has its obvious advantages. You don’t have to update the system every other week. There are no CMS or databases that can be attacked. And it is really fast. Great.

But. If I want to render HTML from Markdown files I could write some PHP code to render the stuff I need. That’s easy to do. And I don’t have the 20+ MB overhead Eleventy gives me. What? Eleventy offers more? Yeah, ok, but I don’t need more.

Bottom line: Nice to know. But for my stuff, a few PHP scripts can do the job.

ProcessWire: Hello and Goodbye

By the end of 2019, the beginning of 2020, I was going back to some good old CMS with databases, and installed ProcessWire. I knew that some webworker colleagues liked the system. And with some experience in other systems, it is quite easy to understand. Another very lean system.

The only downside might be that some useful modules cost money, which you can pay for as an agency and then use in all of your projects. Again, a very fair system. By summer 2020 I had bought the Form Builder and ProFields. And had built two small websites for clients with ProcessWire. So far so good.

But. After I spent half a day with the basic configuration for this blog, I decided against ProcessWire. There are two, rather small reasons for that:

1. ProcessWire is using a page tree. Coming from Drupal I prefer systems that just add content by type and add trees on top as needed.
2. I don’t like ProcessWire’s backend. At all. It has one of the worst backends I have encountered in the last few years. With client websites, I don’t mind it that much. But with a personal website, I will spend more time with the system. And that’s just not fun if the backend sucks.

Bottom line: The system was ok for smaller clients. But not for my personal blog. (Was, because in the meantime I moved on from ProcessWire to Backdrop CMS for smaller clients. See below.)

Strapi / Gatsby: Two systems for one purpose?

By now I had tested Flat File Systems and Static Site Generators. The big buzzword I had tried to ignore was: Headless CMS. I never thought this was a good option for my kind of projects, but I still gave it a spin in the fall of 2020 when I tested Strapi and Gatsby (bought by Netlify in 2023) – again writing articles about this.

One big disadvantage of the better-known systems was the pricing. Smaller tiers were quite limited to the number of content items, API calls, or file uploads. I think that has gotten better over the years. But still, Butter CMS wants 99 US dollars per month for the lowest tier, which is limited to 50 blog posts and 3 users. You must be braindead to buy this stuff (or have no clue about webdev stuff).

In the world of countless Headless CMS providers, Strapi is one of those with a big advantage: You can self-host it for free. Hooray! So just set it up and build your content structure. Easy peasy.

For the frontend part, I chose Gatsby. I had some minor problems with this but in the end, I had a small test site. I liked the combination of Strapi/Gatsby better than Eleventy. Just because I like a backend better than just writing Markdown files.

Again, this felt really nice and easy. But. In my projects, I don’t need to separate frontend and backend. Why hassle with two systems when I can build a website with one system?

Also, it’s 2025 now. Almost all CMS have a way to export their data as JSON, REST, and/or GraphQL. Since I already know Drupal I would use Drupal as Headless CMS. It’s free. It can be installed on your own server. No need to pay anyone for Headless services.

Bottom line: I am glad I tested this. But these are not the right tools for my kind of projects.

Statamic: So flat. So very cool.

Let’s go back into the past. We are in November 2020 now when I stumbled over Statamic. Another flat file system. It offers everything I needed – and more. Like 40+ unique field types, Asset Manager, Globals, Revisions, Focal Points, Video Embeds etc. It was glorious!

By the way, I love Globals. This can be stuff you use anywhere on your website, like a site slogan, text for the footer or the sidebar, or a global message. Just define your Globals and access them anywhere in your templates. In other systems, it can get rather unelegant to store this information. Like in Drupal, where you need a custom entity, a block, or a custom module.

I also adore the tonality of the website and the docs. Just take a look at this version from March 2024. The colors, the deer, the typeface for TL;DR. Very different from other CMS. Further down the homepage tells you to »Choose your own Statamic adventure!« Man, I love Choose Your Own Adventures. Compared to all the other CMS websites that offer buzzwords for marketing people Statamic’s tonality is wild and fun. They toned it down a bit, but in 2020 I was over the moon just strolling through the site.

Just look at the features and the examples for live previews or video embeds. Not for everyone. But my kind of humor.

I was hooked and started building with Statamic. You can build complex content structures with all those field types and the Bard type (kind of like Paragraphs in Drupal). There are revisions and content history. Inline Content Editing. This blog was close to being a Statamic blog. I had already started writing my first new blog post about how I built this with Statamic. If I only had known what I wanted to build …

During the next few weeks I was iterating over everything, I also changed the field types quite a lot. Unfortunately, I had already copied my old blog posts into the system. And the flat files just couldn’t keep up with my changes. As in, the files were built with an older architecture, and the system could not map the old syntax to the new fields. That is not a problem if you have some simple fields. But since I was tweaking my building blocks every other week I came to the conclusion that I needed a database-driven system for my own blog.

Bottom line: Sorry, Statamic. I like you a lot. But I think we should just be friends.

Craft CMS: Looking good

A few days later, we are in February 2021 now, I met Craft CMS. Another promising system. This one does cost money, but a self-hosted solo website is free. So I went for a test drive.

And again: lots of stuff I liked. Of course, you get unique content types, lots of fields, and a Matrix type (like Paragraphs in Drupal or Bard in Statamic) to add various other combinations of fields. A clean backend. Easy upgrades. The option for multi-sites in core. Some useful plugins – although the more useful ones are not for free.

Not the bottom line: Probably not my choice for client websites (because of the price tag), but a contender for my own blog. The only thing missing was an option for comments. I could have bought a plugin for that, but work had brought other options back on the menu.

Drupal: Hello again

I still had some Drupal 7 websites I was responsible for. And I still did not want to upgrade those small sites to Drupal 8+. But at the end of 2020, I was asked to join an existing project for a Drupal site. The old developer for the project wasn’t really at home in Drupal, and they needed someone who actually knew the system better.

So now I had a big website where Drupal 8/9 actually made sense. All of the early bugs I had encountered in the beta versions and release candidates of Drupal 8 were gone. So I felt quite at home and actually had fun using Drupal again. I even made peace with Twig. Just kidding. After writing themes for all those other systems above I hated Twig even more.

But now that I was back in the Drupal cosmos another problem popped up: If I use Drupal for bigger clients and another (still unknown) system for smaller clients, it makes no sense to learn a third system just for my own blog.

So … maybe just do the blog in Drupal? The system is still too big for a simple blog. But on the other hand, I could reuse one or two simple modules I wrote for clients. There are also many free and useful modules – especially if you are only building a blog.

So for a few weeks, I was building this website with Drupal 9. Because of work, this went very slowly. And then I just stopped. Why? Because it is impossible to theme from scratch in Drupal. For this blog, I was still playing around with the theme a lot of the time. Moving the navigation around, trying different stuff with the footer, and different building blocks for the content. Man, I hate working with Drupal on this level. It’s just super annoying. Drupal assumes you are working with regions, blocks, nodes, and fields. Every little item may have its own template. But there are a lot, no, not a lot, there are tons of unnecessary divs hidden in the default templates. And you have to work too much to get the bullshit HTML out.
From the perspective of a front-end developer, it is much easier to work with a system that does not offer a basic theme. So you have to build everything yourself. In that case, yes, you may make some mistakes, but the generated HTML is much much leaner.

Also, Drupal’s update process is still annoying. By now I was fine with using Composer and the command line. As long as the update works the way it should. With 50+ modules installed and occasional changes in Drupal core every few years an update is not so simple and some problems can keep you up for a few hours (or even days). Very annoying.
This may be a bit unfair, as this only happened in two larger projects I was working with. With many added modules. But still, I never had this kind of problem with Drupal 7 or other systems.

Not the bottom line: Drupal is a great system. It’s free. It offers tons of features. I like it in other projects. But not for my small blog.

Craft CMS: Finishing touches

So hello there, Craft CMS, I am back. I spent some time in fall 2021 to build my blog from scratch. And after getting rid of those shitty divs in Drupal, writing a theme for Craft CMS felt so very … clean. Just like in Kirby or ProcessWire or Statamic. Any div in the theme is there because I put it there. And accessing data from other content types is so much easier than the shit you have to do in Twig.

(Imagine here a video of Kirk screaming »Khaaaaaan!«. But instead of him screaming »Khaaaaaan!« it is me screaming »Twiiiiiig!!«)

There was still the problem with comments. I bought and tested two plugins for comments, but I wasn’t happy with them. I spend five minutes thinking about writing a plugin myself. Stupid idea. Then I settled on using another content type as a crutch for comments. That works, but it felt … wrong.

By the end of 2021, I was almost done with the blog. I had already imported all the blog posts from my old blog. The only thing missing was writing the starting blog post (this one) on why I settled with Craft CMS.

Bottom line: At this point, Craft CMS had won.

Then I drowned in work.

Backdrop CMS

In 2022 I had a big project with Drupal 7, another one with Drupal 9. But I still had clients with smaller sites. One Drupal 7 site needed an update. And I still needed a system for those sites. ProcessWire had fallen out of favor. For some reason, I decided to check the current state of Backdrop CMS.

When Drupal 8 was coming up I wasn’t the only one who didn’t like the direction. There were lots of people who liked Drupal 7 well enough to fork it. That was back in 2013, 2014. At the time some people, me included, thought that Backdrop wouldn’t last very long.

Eight years later, Backdrop was not only still around, it was (and is) really good. Lots of useful extra modules from Drupal 7 are now in core in Backdrop, like Views, Redirect, Admin Menu, fields for links, emails, and date.

All very cool. And because of my background with Drupal, Backdrop feels so much better than ProcessWire. After some tests, it was clear, that Backdrop CMS is the go-to-system for all my smaller clients. Switching a small, old Drupal 7 site to Backdrop CMS is also relatively easy. Only the theming is a tiny bit different. Backdrop CMS is also smaller than Drupal 9/10 and way easier to upgrade.

Although my Craft CMS was sitting there, nearly finished, I suddenly had a new contender for my blog system. One with a simple method for comments.

Backdrop vs. Drupal

As I wrote before, it makes no sense to work with three systems. Since I earn my money with Drupal and now Backdrop CMS, I decided to let Craft CMS go.

At that point, the new clear winner should have been Backdrop CMS. It’s small. And it has everything I need for my blog. But I was mostly working knee-deep in Drupal 7/9 projects. And there is one problem I still haven’t figured out: the question of languages. Most of this blog will be in English. But occasionally I will have content that is only interesting for German readers. And for the now-posts, I still have content that mixes both languages.

Now, the big Drupal 9 project is a multilingual site. And we tested the DeepL integration. This might be a useful addition to my blog as well. Write a blog post in language A, use DeepL for a first translation, then just rewrite the translation where necessary and offer the post in both languages. Useful? Yes. Worth the additional work? Probably not? I don’t know. I will need to test this.

Since this blog should also include some Indie Web features (in the long run) the Drupal Indie Web module might come in handy.

Bottom line: After four years of Rumeiern (German for rumbling around) I finally made a decision. Well, another one. Again. I went with Drupal. As a simple blog system, I wouldn’t recommend this to anyone else. And for me, this will only make sense if I use the two modules I mentioned above. I could also use Drupal as a Headless CMS to store the content of some older static websites. 

Funny, how this journey started with me trying to get away from Drupal only to end here again a few years later.

Of course, if I don’t use these Drupal modules I should have gone with Backdrop instead. We will see.

Tales of … me?

Another topic I couldn’t decide on was/is the domain. My first impulse was: New blog, new domain. And the first domain that came to mind was talesof.me.

I was always a fan of tales / stories. In the 90s I edited a collection of very short stories Kurzweiliges – Geschichten gegen den Alltag (roughly: Entertaining – stories against everyday life). There were other story-related projects, but none of them are online anymore.

Since this blog will feature content from various topics (video games, music, comics, the web, life) I had the idea to use various headers like: Tales of the Weary Webdev. Tales of the Got Gud Gamer. Tales of the Comic Connoisseur. Of course, »Tales of …« sounds kind of piratey, and that’s where the design went.

The only thing that speaks against talesof.me is: This domain name is generic as fuck. A lot of other bloggers just use their name, so I could have used nicolaischwarz.me. But I already have the ocean in the footer and the skull in the menu. And I am quite fond of both (and I’ve spent way too much time on them). So for the time being I will stick with talesof.me. Until my next blog relaunch … with the next CMS …

Bottom line: Online. Finally. Published is better than perfect!