DEV Community: Marc Anton Dahmen

Automad 2.0 Beta, the Next-Level CMS

Marc Anton Dahmen — Mon, 29 Dec 2025 18:37:50 +0000

Today I’m excited to finally share something I’ve been working towards for a long time: the Automad 2 beta is out.

If you’d rather experience it than read about it, you can try the live demo right now and explore Automad 2 directly in your browser. A fresh demo site is created automatically, so you can jump straight into editing and get a feel for the new workflow within seconds.

Automad 2 is not a small iteration on version 1. It’s a rethink of what a modern, lightweight CMS can feel like — both for people editing content every day and for developers who care about clarity, performance, and long-term maintainability. The goal was simple: keep Automad fast and predictable, but make it far more powerful and pleasant to use.

The first thing you’ll notice is the new Standard Lite theme. It’s a fresh, elegant multipurpose theme that works out of the box for a wide range of projects, from personal sites to small business pages. It’s intentionally minimal, but flexible enough to grow with your content.

Editing content has taken a big step forward. Reusable components let you group blocks once and reuse them across the entire site. Update a component in one place, and it updates everywhere. This makes it much easier to maintain consistent layouts and shared content without copy-pasting yourself into trouble.

Automad 2 also brings native multilanguage support, making it straightforward to manage content in multiple languages without hacks or workarounds. Combined with a new draft and publish workflow, you can preview changes safely before they go live, while auto-saving ensures nothing gets lost while you edit.

The editor itself has grown more capable and expressive. Code snippets now come with syntax highlighting, and there are many new block types available, including collapsible sections, callout boxes, and even Math/TeX support for more technical content. Behind the scenes, page versioning keeps track of changes and allows you to restore older versions of a page whenever you need to.

On the more practical side, Automad 2 finally adds SMTP email configuration for transactional emails and contact forms, making integrations more reliable and production-ready. All of this is wrapped in a completely refreshed dashboard that feels calmer, clearer, and more focused on the task at hand.

This is a beta release, and the documentation is still a work in progress. Some rough edges are expected, and feedback at this stage is incredibly valuable.

Try the live demo, explore the new editor, and see how Automad 2 feels in practice. If you like where it’s going — or if something feels off — I’d love to hear from you. Automad has always been shaped by real-world use, and this next version is no exception.

Building Sortable Tree — A Lightweight Drag & Drop Tree in Vanilla TypeScript

Marc Anton Dahmen — Thu, 06 Nov 2025 17:00:00 +0000

When working on the Automad dashboard, I needed a collapsible and sortable navigation tree for the page browser sidebar — something that would feel like a small file explorer inside the browser. My goal was simple: use plain TypeScript, no frameworks, and rely only on native browser APIs.

So I went looking for an existing library. There are countless tree components on npm — but nearly all of them depend on React, Vue, or another frontend framework. I wanted something that works in any context: a small script I could drop into a project and wire up using plain events and DOM nodes.

Nothing like that existed.

So I built it.

From a Small Utility to a Full Library

What started as a small experiment for the Automad dashboard eventually became a complete standalone library: sortable-tree — a lightweight, dependency-free (well, almost) TypeScript package that can create foldable and sortable tree structures with drag-and-drop support.

It’s designed for file explorers, navigation editors, or any interface where a nested structure needs to be reorganized interactively. No virtual DOMs. No framework abstractions. Just events, DOM nodes, and TypeScript.

Features

For the Automad dashboard, I needed a tree that could do a few very specific things: foldable branches, sortable nodes via drag-and-drop, and a way to keep the state even if the page reloads. It also had to be fully stylable so it could match the dashboard’s clean look — and all of this had to work without pulling in a framework. sortable-tree was built exactly to meet these needs.

Written in plain TypeScript, framework-agnostic
Drag and drop sorting
Foldable branches
Optional confirmation when moving nodes around
Persisting state across page reloads
Fully stylable — customize icons, node templates, and CSS
(Almost) no dependencies

Basic Example

Here’s a minimal setup that renders a simple tree that persits state across page reloads:

import SortableTree, { SortableTreeNodeData } from "sortable-tree";
import "sortable-tree/dist/sortable-tree.css"; // basic styles

const nodes: SortableTreeNodeData[] = [
  {
    data: { title: "Home" },
    nodes: [
      { data: { title: "Page 1" }, nodes: [] },
      {
        data: { title: "Page 2" },
        nodes: [{ data: { title: "Subpage" }, nodes: [] }],
      },
    ],
  },
];

const tree = new SortableTree({
  nodes: nodes,
  element: document.querySelector("#tree"),
  stateId: "my-tree",
  initCollapseLevel: 2,
  renderLabel: (data) => {
    return `<span>${data.title}</span>`;
  },
  confirm: async (moved, parentNode) => {
    return true;
  },
  onChange: ({ 
    nodes, 
    movedNode, 
    srcParentNode, 
    targetParentNode 
  }) => {
    console.log(movedNode.data);
  },
  onClick: (event, node) => {
    console.log(node.data);
  },
});

The library takes care of all drag-and-drop logic, nesting, and fold state management internally. It provides simple callback options like onClick and onChange to handle user interactions directly in your code. You can, for example, listen to when a node is moved or clicked and react accordingly — or even define optional confirmation logic before changes are applied. If you’d like to see it in action, check out the live demo and examples — you can play around with drag-and-drop, folding, and custom styling right in your browser.

Integrating in Real Projects

In Automad, this library powers the page browser sidebar. Pages can be folded and reordered with drag-and-drop, just like files in a file explorer.

Because Automad’s dashboard is written entirely in plain TypeScript — no frameworks — it’s a perfect example of how simple browser APIs can scale. The code is easy to read, inspect, and extend.

This simplicity is intentional. I wrote more about why Automad doesn’t rely on frameworks in another blog post — but in short: the less you depend on abstractions, the longer your software will live.

Try It Yourself

You can install the package directly from npm:

npm install sortable-tree

Then import it in your TypeScript or JavaScript project and render your first tree. Documentation, demos, and additional examples are available on the docs and demo site. The full source code is hosted on GitHub.

Closing Thoughts

What started as a missing piece in the Automad dashboard turned into a reusable, framework-free library for others to build on. From my perspective, sortable-tree shows that even complex UI patterns like nested drag-and-drop don’t need heavy dependencies — just a clear understanding of how the browser already works and what your project really needs.

It’s fully customizable, keeps state across reloads, and works anywhere TypeScript or JavaScript runs — a small tool that perfectly fits the kind of straightforward, practical approach Automad embraces.

Why I Prefer to Work Alone on My Personal Projects

Marc Anton Dahmen — Sat, 27 Sep 2025 18:07:12 +0000

Open source often comes with an expectation: projects are best built together. And in many cases, that’s true. In my professional life, I collaborate constantly — pair programming, code reviews, team planning. I know firsthand the value of working with others, and I enjoy it.

But when it comes to my personal projects, I prefer a different approach. I like to work alone.

Take Automad, for example. For me, it isn’t just a codebase — it’s the result of years of late-night experiments, side paths, and “what if I try this?” ideas. It’s my creative playground. The moment a pull request appears, that dynamic shifts. Even the smallest change — say, a one-line fix — suddenly gets logged as a contribution next to years of effort. Bigger contributions come with their own challenges: they require discussions, planning, compromises, and agreements. And before I know it, my personal project starts to feel like my day job.

There’s also the personal side of it. I’ve invested so much of myself into these projects that collaborating with complete strangers can feel strangely uncomfortable. It’s not about doubting someone’s abilities; it’s about maintaining a space where I can follow my own instincts without pressure, where I can make mistakes or abandon ideas without worrying about stepping on someone else’s work.

And then there’s the practical side: contributions take time to manage. Even the best pull requests rarely merge themselves. They need to be reviewed, tested, and adjusted to fit the project’s standards. Every one of those steps takes time and energy — time I’d rather spend actually creating, refining, or exploring new directions.

So yes, I choose to work alone. But here’s the important part: I still open-source my projects. Because open source isn’t only about collaboration — it’s also about sharing. A project doesn’t need a hundred contributors to bring value to the world. Even when it’s built by just one person, it can still help others solve problems, spark ideas, or teach something new.

That’s the balance I’ve found works best for me. By keeping my creative process personal, I protect the freedom and flow that make these projects enjoyable. And by open-sourcing the results, I make sure that freedom can still create value for others.

In the end, I don’t reject collaboration — I just draw a line between where it belongs. At work, collaboration is essential. In my personal projects, solitude keeps the spark alive. And thanks to open source, those sparks don’t have to stay mine alone.

Automatic Cookie Consent Banners in Automad

Marc Anton Dahmen — Thu, 08 May 2025 07:11:21 +0000

Cookie consent banners are, in my opinion, one of the worst things to have happened to the modern web. They clutter interfaces, confuse users, and ultimately serve as a band-aid for a problem that should be solved at the browser level — not by every single website reinventing the wheel in JavaScript.

That said, like it or not, cookie consent is a legal requirement in many parts of the world, especially in the EU. And since many Automad users need to comply, I’ve added built-in support for cookie consent banners in the latest alpha version of the Automad CMS.

Cookie Consent That Just Works

The new alpha version of Automad introduces a built-in cookie consent system that takes care of everything automatically. You don’t need to install a plugin, write custom JavaScript, or hack together your own solution.

Automatically Displayed When Needed

Automad now detects when a page has embedded third-party content that potentially sets cookies — like an embedded YouTube video or Soundcloud song — and displays a consent banner only when it’s necessary. If your page doesn’t include anything privacy-sensitive, no banner is shown at all. Simple as that.

Handle Manually Added Third-Party Scripts

For more advanced use cases, Automad includes the new web component. You can wrap any JavaScript block (e.g., social media widgets, third-party analytics, or anything cookie-related) in this component to ensure it’s only loaded after user consent.

<am-consent type="script">
    console.log('Hello you!');
</am-consent>

You can also wrap remote JavaScript files in the consent logic.

<am-consent type="script" src="https://domain.com/script.js"></am-consent>

This gives you full control while maintaining compliance.

Fully Customizable Look and Feel

No one wants a generic banner that looks like it was slapped on at the last minute. Automad lets you customize the consent banner entirely via the dashboard:

Change the banner text and button labels
Adjust background and text colors
Change the colors of the embedded content placeholders

This way, the banner and placeholders feel like part of your design, not a foreign element. All cookie consent customization settings can be found either in General Data and Files > Customizations section or under the Customizations tab in the page settings.

A Small Step Toward a Smoother Web

While cookie banners aren’t going away anytime soon, Automad now helps you deal with them in the least painful way possible. They appear only when needed, they don’t break your design, and you remain in control.

It’s a compromise between legal obligation and design minimalism — and another step toward making Automad an even more complete and effortless CMS for modern websites.

The Inflation of "Security Researchers" and Its Consequences for Open Source

Marc Anton Dahmen — Sat, 05 Apr 2025 07:06:05 +0000

As an open-source maintainer, I deeply appreciate the importance of cybersecurity. Security is a shared responsibility — both for users who rely on software to be secure and for developers who build and maintain open-source projects. Responsible vulnerability reporting strengthens the ecosystem, helping us all build better, safer software. However, in recent years, the term "security researcher" has been stretched to the point where it is becoming counterproductive.

The Problem with False Positive CVEs

Security should always be taken seriously. When genuine vulnerabilities are discovered and responsibly reported, it leads to stronger software. However, the rise of false positive CVEs (Common Vulnerabilities and Exposures) is eroding trust in the entire system. When reports are filled with exaggerated, misclassified, or outright incorrect vulnerabilities, security research turns from a net positive into a liability.

The more false positives flood the system, the harder it becomes to separate real threats from noise. If every minor misconfiguration, theoretical issue, or misunderstanding of an application’s context results in a CVE, security teams — and open-source maintainers like me — will struggle to prioritize what truly matters. This leads to a dangerous situation: if everything is a "critical" vulnerability, nothing is.

A second, equally concerning risk is that the increasing burden of handling false or exaggerated vulnerability reports could discourage open-source maintainers from continuing their work. Many of us develop and maintain open-source projects in our free time, often without compensation. When dealing with bad-faith reports, inflated CVE claims, and a lack of appreciation becomes overwhelming, it’s not hard to imagine that some maintainers might choose to step away from their projects. If that happens on a larger scale, the entire open-source ecosystem could suffer — not because of real security threats, but because the noise is drowning out legitimate concerns.

Understanding the Domain Before Reporting

One key issue in today's security research landscape is the lack of context in vulnerability reporting. Not all software is the same, and not all theoretical vulnerabilities are real-world threats.

A security vulnerability in a desktop application may not be relevant in a cloud-based system. A theoretical attack vector that requires unrealistic conditions — like admin access already being compromised — may not be a true risk at all. Yet, reports often do not consider these nuances. As a maintainer of Automad, a content management system, I have seen reports that claim a severe risk without understanding how the system actually works in a real deployment.

Without proper domain knowledge, security researchers risk creating unnecessary panic over non-issues. Worse, this can lead to maintainers being overwhelmed with bad reports, which in turn slows down the response to actual security concerns.

A Real-World Example

A perfect example of this issue happened last year when I received multiple CVE notifications about a supposed cross-site scripting (XSS) vulnerability in Automad. The reports claimed that a non-sanitized input field could be exploited to inject JavaScript. However, these reports completely misunderstood the nature of the project. Automad is designed as a single-user content management system, meaning there are no user sessions to steal, and the only person with access is the site owner — who already has full control over the server. While it is possible to add other trusted collaborators, Automad does not include role-based access management or a permission system — this is intentional. As a minimalistic CMS, it is designed for simplicity rather than complex user management. This fact alone eliminates any meaningful attack vector for XSS.

Even more ironic is that the actual purpose of this field is to modify the template, which includes the ability to add JavaScript. It is an essential feature, not a vulnerability. Filtering out JavaScript in this context would make Automad less functional for its intended users. Yet, these reports reflect an extremely low intellectual quality, reducing the complexity of web security to an oversimplified "JavaScript = bad" narrative. This kind of thinking ignores the fact that JavaScript is a fundamental part of modern web development and that context matters. Not every instance of JavaScript is a security risk, and not every field that allows JavaScript input is a vulnerability. This level of reasoning results in false reports that waste time and distract from real security threats.

Following the logic of these reports, one could argue that all static websites on all servers are, by definition, a security threat — since they allow JavaScript to be embedded freely. But that would be an absurd claim. An admin is an admin, and with those privileges comes responsibility. If we start labeling every instance of an admin performing admin tasks as a security flaw, we will render security research meaningless. Despite this, the CVEs were still registered, adding unnecessary noise to security databases and further proving how poorly contextualized vulnerability reports can lead to misleading conclusions. The situation escalated to the point where even INCIBE, Spain's national cybersecurity institute, reached out to ask me to react — further illustrating how these flawed reports can create unnecessary bureaucracy and pressure on open-source maintainers. It was clear that nobody involved had actually taken a proper look at the issue or was simply unable to understand the affected code.

Fortunately, the at least the GitHub Security Advisory team reviewed the reported CVEs listed there and, after assessing the claims, decided to withdraw most of them (CVE-2024-40111, CVE-2023-7036 and CVE-2023-7035). This demonstrates that not all security platforms blindly accept reports and that careful review processes can help mitigate the spread of misleading vulnerability claims. However, the fact that these CVEs were published in the first place still highlights a major problem: maintainers must invest time and effort into defending their projects against false positives rather than focusing on actual development and security improvements.

The Data: False Positives on the Rise

Studies and industry reports indicate that a significant percentage of reported CVEs are now false positives. This is a troubling trend because, instead of strengthening security, it weakens it. When organizations and maintainers are forced to sift through countless invalid reports, real threats can be missed.

For example, a study by JFrog found that 78% of reported CVEs in popular DockerHub images were not actually exploitable [source]. Similarly, discussions in the open-source community have highlighted how many CVEs are assigned without proper validation, leading to unnecessary panic and wasted resources [LWN article].

A well-documented case that illustrates this problem is CVE-2020-19909, which was recently reassigned as a "critical" vulnerability in Curl — despite being a decades-old, non-exploitable bug. This case exposes the systemic flaws in how CVEs are assigned and scored [Daniel Stenberg’s blog][Hacker News discussion].

This is not just an open-source problem — it affects the entire cybersecurity field. If security research continues to focus on quantity over quality, the long-term effect will be a loss of credibility. Users, developers, and security teams will start ignoring vulnerability reports altogether, assuming they are just more noise. This is the exact opposite of what cybersecurity research should achieve.

The Way Forward

For security research to be effective, we need to emphasize responsible disclosure and domain expertise. Researchers should take the time to understand a system before reporting vulnerabilities. The industry needs better guidelines to filter out false positives before they are assigned CVEs. Open-source maintainers, in turn, need to be given the space to address real issues rather than constantly responding to invalid reports.

Cybersecurity is too important to be diluted by low-effort, context-free reports. If we want to improve security, we must ensure that vulnerability reports are meaningful, accurate, and relevant. Otherwise, we risk making the internet a less secure place — despite the best of intentions.

Why Automad No Longer Uses Any Frontend or Backend Framework

Marc Anton Dahmen — Fri, 28 Mar 2025 11:00:00 +0000

Long-term open-source projects, such as Automad, require stability and independence from third-party libraries. Relying on external frameworks introduces risks that can impact maintainability, long-term support, and overall project longevity.

Removing dependencies on jQuery and UIkit in preparation for Automad 2 was a painful process that ultimately led to an entire re-write. This transition required significant effort to replace legacy implementations with modern, native solutions while ensuring feature parity and long-term stability.

The Appeal of Frameworks

In my day job as a software engineer, I work extensively with React and Svelte, along with their respective metaframeworks, Next.js and SvelteKit. These tools provide significant advantages in modern development workflows, including:

Support for teams with varying skill levels
Rapid development
Easy onboarding
Common industry knowledge

However, these benefits come with a hidden cost: dependency on the decisions of framework authors.

The Hidden Costs of Framework Dependency

When adopting a frontend or backend framework, you are not just using a tool — you are also agreeing to follow the evolution of that tool. This means:

Breaking changes
Shifting paradigms
Ecosystem lock-in
Uncertain longevity

For a project like Automad, which aims for long-term maintainability and minimal dependencies, these issues present a real challenge.

The Case for Native Solutions

Instead of relying on third-party frameworks, Automad embraces native web technologies where possible. Native solutions, such as Web Components, provide:

Stable APIs
No external dependencies
Built-in browser support
Full component lifecycle management

Despite these advantages, Web Components have often been met with skepticism, primarily due to negative perceptions perpetuated by framework maintainers. Many articles critiquing Web Components come from authors with vested interests in framework adoption.

That being said, using smaller libraries and packages is not a problem as long as they can be easily isolated and replaced. Unlike monolithic frameworks, modular libraries provide flexibility without locking a project into a particular ecosystem or paradigm.

Conclusion

Automad's decision to move away from frontend and backend frameworks is driven by a long-term vision of stability, maintainability, and independence. While frameworks provide immediate benefits, they also introduce long-term risks that are incompatible with the goals of an open-source CMS that seeks to remain lightweight, flexible, and future-proof. By leveraging native solutions, Automad ensures a stable foundation that is not subject to the shifting priorities of third-party framework maintainers.

Setting Up Neovim for Automad Theme Development

Marc Anton Dahmen — Wed, 26 Mar 2025 11:30:00 +0000

As the developer of the Automad flat-file content management system, I wanted to make working with Automad themes in Neovim as smooth as possible. Automad has its own templating syntax, so I created tree-sitter-automad to provide proper syntax highlighting. Since it’s not yet an official parser, you need to manually register it in Neovim. To speed up template writing, you can also add custom snippets using LuaSnip. Here's how to set everything up.

Syntax Highlighting with Tree-sitter

By default, Neovim doesn't recognize tree-sitter-automad since it isn't an official parser yet. You can manually register it by modifying your Neovim config. Open ~/.config/nvim/init.lua (or ~/.config/nvim/lua/plugins/treesitter.lua if you separate plugins) and add:

local parser_config = require('nvim-treesitter.parsers').get_parser_configs()

parser_config.automad = {
  install_info = {
    url = 'https://github.com/automadcms/tree-sitter-automad',
    files = { 'src/parser.c' },
  }
}

require('nvim-treesitter.configs').setup {
  ensure_installed = { "lua", "html", "css", "javascript", "php", "automad" },
  highlight = {
    enable = true,
  },
}

Save the file and restart Neovim. Now Neovim will recognize Automad templates and provide syntax-aware highlighting.

Apart from the parser, Tree-sitter also needs query files to define syntax highlighting rules. Again, since Automad isn't an official parser yet, these queries aren't included by default, so you need to copy them manually.

Clone the tree-sitter-automad repository:

git clone https://github.com/automadcms/tree-sitter-automad.git ~/tree-sitter-automad

Then, create the directories where Neovim looks for Tree-sitter queries:

mkdir -p ~/.config/nvim/after/queries/php
mkdir -p ~/.config/nvim/after/queries/automad

Copy the query files from the repository into these directories:

cp ~/tree-sitter-automad/queries/* ~/.config/nvim/after/queries/php/
cp ~/tree-sitter-automad/queries/* ~/.config/nvim/after/queries/automad/

Once that's done, restart Neovim and check if the parser is working by running:

:checkhealth nvim-treesitter

If everything is set up correctly, automad should appear in the list of installed parsers. You can also take a look at my personal Neovim config repository to see how I have everything set up.

Adding Automad Snippets with LuaSnip

I personally use LuaSnip to manage my Neovim snipptes. To make writing Automad templates faster, I recommend that you define some custom Automad snippets directly inside your LuaSnip config. If you want to see how I integrate it into my setup, you can check out my personal Neovim config repository.

local luasnip = require('luasnip')
local s = luasnip.snippet
local t = luasnip.text_node
local i = luasnip.insert_node

luasnip.add_snippets('php', {
  s(
    { trig = '<@', name = 'Automad Statement' }, 
    { t({ '<@ ' }), i(1), t({ ' @>' }) }
  ),
  s(
    { trig = '@', name = 'Automad Variable' }, 
    { t({ '@{ ' }), i(1), t({ ' }' }) }
  ),
  s(
    { trig = '#', name = 'Automad Comment' }, 
    { t({ '<# ' }), i(1), t({ ' #>' }) }
  ),
  s(
    { trig = '@pagelist', name = 'foreach in pagelist' },
    { t({ '<@ foreach in pagelist @>', '    ' }), i(1), t({ '', '<@ end @>' }) }
  ),
  s(
    { trig = '@pagelistelse', name = 'foreach in pagelist else' }, 
    {
      t({ '<@ foreach in pagelist @>', '    ' }),
      i(1),
      t({ '', '<@ else @>', '   ' }),
      i(2),
      t({ '', '<@ end @>' })
    }
  ),
  s(
    { trig = '@if', name = 'if ...' },
    { t({ '<@ if ' }), i(1), t({ ' @>', '   ' }), i(2), t({ '', '<@ end @>' }) }
  ),
  s(
    { trig = '@ifelse', name = 'if ... else ...' }, 
    {
      t({ '<@ if ' }),
      i(1),
      t({ ' @>', '  ' }),
      i(2),
      t({ '', '<@ else @>', '   ' }),
      i(3),
      t({ '', '<@ end @>' })
    }
  ),
  s(
    { trig = '@with', name = 'with ...' },
    { t({ '<@ with ' }), i(1), t({ ' @>', ' ' }), i(2), t({ '', '<@ end @>' }) }
  ),
  s(
    { trig = '@withelse', name = 'with ... else ...' }, 
    {
      t({ '<@ with ' }),
      i(1),
      t({ ' @>', '  ' }),
      i(2),
      t({ '', '<@ else @>', '   ' }),
      i(3),
      t({ '', '<@ end @>' })
    }
  ),
  s(
    { trig = '@for', name = 'for ... to ...' }, 
    {
      t({ '<@ for ' }),
      i(1),
      t({ ' to ' }),
      i(2),
      t({ ' @>', '  ' }),
      i(3),
      t({ '', '<@ end @>' })
    }
  ),
  s(
    { trig = '@snippet', name = 'snippet ...' },
    { 
      t({ '<@ snippet ' }), 
      i(1), 
      t({ ' @>', '  ' }), 
      i(2), 
      t({ '', '<@ end @>' })
    }
  ),
})

Now you can type Automad syntax triggers like @if, @for, or <@, then press Tab (or your configured expansion key) to insert full syntax structures automatically.

Wrapping Up

With Tree-sitter and LuaSnip set up, developing Automad themes in Neovim becomes much smoother. You now have syntax highlighting and custom snippets to speed up your workflow.

If you run into any issues, feel free to submit an issue on the tree-sitter-automad repository. You can also check out my personal Neovim config for more setup inspiration. Happy coding!

How to Create a Multilingual Website Using Automad 2

Marc Anton Dahmen — Sun, 23 Mar 2025 15:45:34 +0000

Creating a multilingual website can significantly expand your reach and user engagement by catering to a global audience. Automad 2, a lightweight flat-file CMS that prides itself on simplicity and flexibility, makes it easy to create and manage multilingual websites.

In this tutorial, I'll walk you through the steps to build a multilingual website using Automad 2. You'll learn how to set up language-specific landing pages, configure slugs, and enable language routing. Let's dive in!

Step 1: Create the Site Structure with Language-Specific Landing Pages

The first step in creating a multilingual website is to organize your site structure. In Automad 2, you want to create a structure where each language has its own landing page directly under the homepage. This will make it easier to manage the content for each language and keep things organized.

Here’s how to do it:

Log into your Automad 2 admin panel.
Go to the Pages section and add a new page for each language you want to support. For instance, you can create pages called “English,” “Français,” “Deutsch,” etc. These will serve as the landing pages for each language.
Give each page any title you like at this stage — since you'll be changing the slugs in the next step, the title here doesn’t affect navigation or URLs. You can focus on whatever naming convention works best for your workflow.

Important Note: The order of the pages matters! The first page at the top of the sidebar will serve as the default language for your site. If a visitor accesses your website with an unsupported locale, Automad will use this default language. Make sure to place your preferred default language page at the top of the list.

Once you’ve created the pages, you should have a homepage that points to the different language-specific landing pages.

Step 2: Change the Slug for Each Language Page

By default, Automad will automatically generate slugs based on the titles you gave your language-specific landing pages. However, we need to change the slugs to the corresponding language codes (like en, fr, or de) for proper routing.

Here’s how to change the slugs:

Open the settings of each language-specific landing page.
In the Directory Name field (this field represents the page’s slug), change the automatically generated slug to the matching language code. For example:
Make sure each landing page has its unique language code as the slug.

By setting these language codes as slugs, you’re telling Automad that these pages represent different languages, which is essential for proper language routing later.

Step 3: Enable Language Routing in the System Settings

Now that you’ve created your language-specific landing pages and configured the slugs, it’s time to enable language routing. This ensures that Automad will handle the routing for your multilingual content based on the language code in the URL.

Here’s how to enable language routing:

Navigate to System Settings in the admin panel.
Look for the Internationalization section.
Find the Language Routing setting and enable it.

Enabling this feature ensures that when someone visits your site with a specific language code in the URL (like www.yoursite.com/en), Automad will automatically serve the content for that language. For example, if someone visits www.yoursite.com/fr, they’ll be redirected to the French language version of the site.

Step 4: Translate Your Content

At this point, your multilingual site structure is set up, but it’s still empty. Now you’ll need to add translated content to each language-specific landing page. To do this:

Go to each language-specific page in the admin panel.
Add the appropriate content for each language.
You can use Automad’s simple block editor to add text, images, and other media that are relevant to each language.

Repeat this for all the pages in your site, making sure each language version has its own unique content.

Step 5: Test Your Multilingual Website

Once you’ve added all your content and completed the setup, it’s time to test your multilingual website. Make sure to check:

Whether each language-specific page loads correctly when visiting its respective URL (e.g., /en, /fr, /de).
That content is displayed correctly in each language and there are no broken links.
Navigation and links between languages are working as expected.

Bonus: Add links to Other Languages in the Footer

Now, your multilingual site is ready for visitors. But what if you want to give those visitors the chance to change to another language? With language routing enabled, pages in other languages than the currently active one are not visible in the site navigation and can’t be found in the site search.

In order to allow visitors to change to another language, we can simply create page for another language that is alias inside the active language. With the three languages used in this tutorial, we can create the page /en/german and forward it to the German landing page by changing the URL field to /de in the page settings. Finally we can check the "Show Page in Footer" checkbox to show the link in the footer. This procedure we can also repeat for the French version as well as all remaining combinations inside the other two languages.

Conclusion

Setting up a multilingual website with Automad 2 is simple and straightforward. By creating language-specific landing pages, modifying slugs to match language codes, and enabling language routing, you can effectively manage and deliver content in multiple languages. With Automad’s clean and intuitive interface, it’s easy to expand your reach to a global audience without overwhelming complexity.

Happy writing, and enjoy building your multilingual website with Automad 2!

Automad CMS 2.0 Alpha

Marc Anton Dahmen — Sun, 23 Mar 2025 15:11:54 +0000

After a long development process, the stable release of the Automad CMS 2, is getting closer. While many aspects of the system have evolved, the core vision remains the same — delivering a fast, flexible, and file-based content management system with a powerful templating engine.

What's New?

With Automad 2 now in alpha, the list of improvements is extensive. A finalized documentation and release notes will provide full details soon, but here are already some of the most significant updates:

Modernized Frontend

One of the biggest changes is the complete removal of UIkit and jQuery as dependencies. Instead, the frontend is now built entirely with modern web components and TypeScript, making the dashboard lighter, faster, and more maintainable.

Enhanced Block Editor

The block editor has been significantly improved for a more intuitive editing experience, especially when working with nested layouts. Nested sections no longer require modal windows, and drag-and-drop functionality between sections is now fully supported.

Native Multilingual Support

Automad now includes built-in multilingual support. Visitors can be routed to different language versions based on their locale settings, and editors can define language-specific routes (e.g., /de or /en). If a visitor's locale doesn’t match any of the available options, the top-listed language is used as the default.

Image Editing Within Automad

No need for external tools — images can now be edited directly within Automad. The built-in image editor supports cropping, resizing, rotation, filters, watermarks, markups, and color corrections.

Reusable Components

Frequently used content can now be saved as reusable components, making it easy to maintain consistency across an entire site without duplicating work.

New Editing Workflow

Starting with Automad 2, all dashboard edits are automatically saved as drafts. This eliminates the need to manually hit "Save". Drafts are only visible to admins and can be reviewed in the in-page editing mode before publishing.

Additionally, Automad now supports automatic revision snapshots. When editing a page for an extended period, previous versions are periodically saved in the background, allowing for easy restoration with a few clicks. The trash bin, which previously existed but wasn’t accessible from the dashboard, is now fully integrated — making it simple to restore deleted pages.

Improved Page Management

The file tree in the sidebar now supports drag-and-drop for moving and sorting pages. Manual index prefixes are no longer required, and moving pages no longer involves opening modal windows.

SMTP Email Configuration

Configuring SMTP for outgoing emails is now supported, with both sendmail and external SMTP servers available as options. Additional configurations may be added in future releases.

New Dashboard Themes

To enhance the user experience, the new dashboard includes three theme options — Light, Dark, and Low Contrast — allowing users to customize the interface to their preference.

Try the Live Demo

Want to test Automad 2 without setting up a local server? A live demo is available, allowing you to explore all the new features instantly. No signup is required, and each demo instance lasts for one hour.

Click here to start your demo

Installation

The alpha version of Automad version 2 can be deployed using Docker or Composer. It is also possible to simply download and install a distribution bundle manually. Note that the new version will require a modern browser, currently Chrome or Firefox, and a server running Apache or Nginx with PHP 8.2+.

Docker

The quickest way to try out Automad version 2 without actually worrying about Nginx and PHP, is using Docker. The v2 tagged image includes everything you need.

docker run -dp 80:80 -v ./app:/app --name mysite automad/automad:v2

This will essentially make your site available at port 80 and mount a directory called app in the current working directory for data persistence. A new user account for the Automad dashboard will be created automatically. The account details will be logged by the running container. You can show these logs using the following command:

docker logs mysite

Composer

Alternatively you can install Automad version 2 on your web server using Composer as follows:

composer create-project automad/automad . v2.x-dev

A temporary user account for the user account will be created automatically, which can be changed later.

Also make sure that the entire directory where Automad is installed is writable by the web server and the PHP process. On Apache, everything should then be pretty much working out of the box. However, in case you are running Nginx, you can use the following server config:

server {
  root    /path/to/automad;
  index    index.php index.html;

  location / {
    try_files $uri $uri/ /index.php$is_args$args;
  }

  location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;
  }
}

Manual Installation

Download a distribution bundle and move the unpacked content to the document root of your web server.
Make sure the PHP process has the permissions to write to the document root and its subdirectories including all installed files.
Visit the /dashboard route on your site and create the first user.

What's Next?

There's still more work to be done before Automad 2 reaches its stable release. A solid beta version is planned soon, which will be production-ready for real-world usage.

Enjoy, and stay tuned for more updates!