DEV Community: Thorsten Marx ㋡

Why I Built a Markdown-First CMS Instead of Another Headless CMS

Thorsten Marx ㋡ — Thu, 25 Jun 2026 16:01:45 +0000

To answer that question, I need to go back a bit. It all started in 2020, when I needed a CMS for a few personal projects. Up until that point I had mostly worked with WordPress, but it didn't feel like the right fit for what I had in mind. So I started an evaluation phase, looking at various systems.

After a while I found several options that covered parts of my requirements, but none of them were quite what I wanted overall. That's when I decided to just build a CMS myself — the system I actually wanted to work with.

Headless CMS were already gaining momentum back then, and I even spent some time building a headless prototype. But for the things I wanted to build, headless was clearly overkill and would have added significantly more work per project. Don't get me wrong: headless CMS are great, just not the right solution for every problem. That pushed me towards a more traditional approach.

My goals for the first version were:

a lean and fast system
content in Markdown, so I could write using any editor I liked without having to build a UI
content and configuration versioned in Git
installation that's as simple as possible
a setup that's attractive for developers, both for plugin and project development

Lightweight system, simple installation

The system needed to be as simple to handle as possible. Installation should not require running through a complex wizard, and there should be no database involved.

Installing CondationCMS is accordingly short:

wget https://github.com/CondationCMS/cms-server/releases/download/v8.2.0/condation-server-linux-x64-2026.06.tar.gz
tar xfvz condation-server-linux-x64-2026.06.tar.gz
cd condation-server
./server.sh server start

That's it. The CMS is running and the test site is available at http://localhost:2020.

It starts in DEV mode and will need some configuration before going to production, but depending on your internet speed the whole thing is up in under five minutes.

Content in Markdown, versioned in Git

Creating content should be as straightforward as possible: create a file in your editor of choice, add front matter and Markdown content, done.

---
title: Page title
---

# Page content

Here is some content!

A big advantage here is that content is easy to create and can be managed directly in Git. And it goes beyond just the content itself: site configuration, defined image resolutions, module configuration, and project extensions all live in the same repository. Everything that belongs to the project gets versioned together, which makes deployment significantly simpler and keeps the project portable.

A system that's attractive for developers

Through the integration of the GraalJS engine, small extensions can be implemented directly inside the project as an Extension.

For example, a new shortcode can be defined and then used in Markdown:

import { $hooks } from 'system/hooks.mjs';
// register component via js extensions
$hooks.registerAction("system/content/shortCodes", ({shortCodes}) => {
    shortCodes.put(
            "hello",
            ({name}) => `Hello ${name}`
    )
    return null;
})

Extensions are plain JavaScript files, always part of the project, and automatically included in Git. They work well for small, project-specific solutions that you don't need to share across projects.

When things get more complex, there are modules — what other systems usually call plugins. Modules are written in Java and offer everything extensions do, plus access to the full Java ecosystem. If you need to integrate a third-party library or build something that should be reusable across multiple sites, a module is the right tool.

Providing that same shortcode via a module looks like this:

// register component via java module
@ShortCode("hello")
public String hello_shortcode (String name) {
    return "Hello " + name;
}

Modules are installed globally on the server and can then be activated per site.

Looking back at those five goals from 2020 — lean, Markdown-based, Git-versioned, easy to install, developer-friendly — CondationCMS hits all of them. It's the system I wanted back then, and it's still the one I'd reach for today. If any of this sounds like what you've been looking for, the best way to find out is to give it a try.

CondationCMS: A New Era for Editors, Developers & Admins 🚀

Thorsten Marx ㋡ — Mon, 01 Sep 2025 08:57:30 +0000

The Next Big Release of CondationCMS – More Freedom for Editors, Developers, and Admins 🚀

In CMS projects, many different people come together – and each role has its own needs. With the upcoming release of CondationCMS, we’ve taken this diversity seriously. Whether you’re an Editor, Developer, or Admin, you’ll get powerful new tools and features designed to make your daily work easier – and more exciting.

For Editors ✍️

Until now, content editing mostly happened directly in a plain text editor – not exactly the most user-friendly setup. The new release finally introduces the Manager App: a dedicated module built specifically for content editors.

With it, you can create, organize, and manage content in a clean, structured way. And here’s the kicker: the Manager App can be enabled per project. That means you can run a secure editorial system while keeping the delivery system lightweight.

👉 More clarity, fewer detours – content management has never been this smooth.

For Developers 💻

In CondationCMS, there are two main developer roles:

Frontend/Template developers, who set up projects, turn HTML templates into CMS templates, and create themes with JavaScript and CSS.

Module developers, who dive deep into integrations and custom features.

Both groups will love what’s coming in this release:

Template developers can now also define the forms that editors will use later to manage content – creating a direct bridge between design and editorial workflows.

Module developers get a huge productivity boost: routes, tags, and template components can now be registered with simple annotations.

The result: less boilerplate, more creativity – whether you’re building themes, extensions, or full-blown modules.

👉 No matter if you’re starting a project or shipping a new feature: CondationCMS takes care of the heavy lifting.

For Admins 🔧

Of course, we haven’t forgotten the people who keep everything running behind the scenes. The new release brings:

An extended and hardened CLI that’s even more reliable.

Server modules for global features that should only be configured by admins – like the backup module or the git module. These are no longer tied to individual projects but managed centrally and securely.

Enhanced password security, which is especially critical when using the new Manager App.

👉 More security, more stability, more control – without unnecessary complexity.

The Bottom Line 🌟

This release is packed with countless hours of work – all with one goal: making CondationCMS easier, safer, and more enjoyable for everyone involved.
Whether you love creating content, building features, or running systems: the new CondationCMS delivers the tools you need to simplify your work – and maybe even make it a little more fun.

CondationCMS manager application

Thorsten Marx ㋡ — Thu, 07 Aug 2025 08:28:17 +0000

CondationCMS – The New Manager

After five months of hard work, I'm proud to present the new Manager Application, coming in the next major update of CondationCMS.

But first, let me explain why I initially said CondationCMS doesn’t need a manager at all—and why I’ve now built one.

In the early days of CondationCMS, every piece of content had to be created in a text editor. That worked fine—as long as the person writing the content had some technical background. It was just Markdown with a YAML header, after all.

But at some point, I realized I didn’t want to be the one getting called for every small content change. So I decided to build something that would allow non-technical users to create and update content on their own.

Here’s what I had in mind when starting the project:

The Manager is primarily for content authors
Template development should stay outside the Manager
Content creation should be as simple and non-technical as possible
Authors should get all the tools they need—nothing more
Template developers should be able to define custom forms to give users just the right amount of control
Authors shouldn’t be able to break the layout—so complex editors like Elementor in the WordPress world offer too much freedom for this use case

That was the basic idea—and here’s the result.

Please note: This short clip doesn’t show every feature, but it should give you a good idea of how content editing works in CondationCMS.
More videos will follow soon, highlighting individual features.

CondationCMS, the java based flat file cms

Thorsten Marx ㋡ — Wed, 06 Aug 2025 17:24:54 +0000

A couple of years ago, I worked for one of the major CMS vendors here in Germany. That’s when I really fell in love with content management. Even after I left the company, the CMS world never quite let go of me. I kept testing new systems—especially open-source ones. There's something fascinating about seeing how different teams solve the same core challenges in entirely different ways.

As a developer, my head is always full of ideas. Whether it's a web app, a software tool, or just a “what-if” concept—I always have something brewing that keeps my spare time interesting. In the early days, WordPress was my go-to platform for nearly every web project. But over time, I started looking for alternatives—systems I could shape more freely and build on in my own way.

Eventually, I hit a point where even the best open-source solutions didn’t quite give me what I needed. Either they were too bulky, too rigid, or simply not fun to work with. That’s when the idea hit me: Why not build my own CMS? It was one of those long-time "dream projects" that had been sitting in the back of my mind for years. Now it was time to bring it to life.

The initial goal was modest: a lightweight, flexible platform with support for plugins, themes, templates, Markdown, and multisite functionality. Nothing fancy—just enough to experiment and build a few websites. One key decision early on: no UI. I wanted everything to be editable directly in the filesystem, using whatever code editor you prefer.

After a while, the system became surprisingly fast and stable. That’s when friends started asking me to build websites for their small businesses. I agreed—but only on one condition: I wanted to use my custom CMS. When they said yes, I was thrilled (and a little terrified). Suddenly, my little side project had real-world users.

And that’s how CondationCMS was born—the first Java-based flat file CMS. It all started about three years ago, and the journey is still going strong.