Die wichtigste Änderung in 1.1.0: notACMS liefert jetzt zwei Themes ab Werk, und du wählst beim allerersten Build eines davon aus:

./notACMS deploy --demo    # Standard — das Amber-Phosphor-Design, das du hier siehst
./notACMS deploy --bare    # ein minimales Wireframe: Systemschriften, Light Mode, ~200 Zeilen CSS

ddev build unterstützt dieselben Flags. Egal, welches du wählst — alle Funktionen laufen: mehrsprachige Inhalte, Blog, RSS, Sitemap, Suche, Kontaktformular, Bilder mit responsiven Varianten, Lesezeit, Lesefortschritt. Der Unterschied liegt nur in der Optik — und vor allem darin, wie viel du erbst, bevor du mit dem Anpassen beginnst.

Schlanker Kern#

Der Kern in templates/, assets/, translations/ ist jetzt ein Wireframe. Er ist bewusst minimal gehalten, damit das Überschreiben eines einzelnen Blocks nicht gleich eine visuelle Sprache mitschleift, gegen die du ankämpfen musst. Wenn du ein maßgeschneidertes Design baust, starte mit dem Bare-Theme und du besitzt das gesamte Erscheinungsbild ab Tag eins.

Demo-Theme#

Das Demo lebt unter docs/demo/ und wird nach local/ kopiert, wenn du --demo wählst. Es ist das vollständige Amber-Phosphor-Design, das du gerade liest — Dark Mode, Such-Overlay, Docs-Sidebar, Theme-Umschalter, alles dabei. Starte hier, wenn du heute ein poliertes Design willst und planst, zu tweaken statt neu zu bauen.

Das local/-Override-System#

Beide Themes nutzen denselben Mechanismus: Jede Datei in local/ hat Vorrang vor dem entsprechenden Pfad im Kern.

Der Kern wird nie bearbeitet. git pull bleibt sauber. Anpassungen leben im Repo deiner Site, nicht in einem Fork dieses Repos.

Upgrade von 1.0.0#

Wenn du 1.0.0 benutzt hast und deine Site exakt so aussehen soll wie vorher, ist das Kompatibilitätspaket ein Einzeiler:

cp -r docs/customization/old-template/. local/
ddev build

Das legt das komplette Theme vor 1.1.0 — Templates, SCSS, Schriften, Bilder, Übersetzungen — in local/ ab. Deine Site rendert exakt wie zuvor. Anschließend kannst du Dateien aus local/ selektiv entfernen, sobald du neue Design-Elemente übernimmst.

Die echten Breaking Changes, auf die du stößt, wenn du den alten Kern angepasst hast:

• SCSS-Entrypoint umbenannt: local/assets/styles/local.scss → local/assets/styles/app_local.scss. Benenne die Datei um und passe den Import in local/assets/app.js an.
• SCSS-Farbvariablen im Kern durch CSS Custom Properties ersetzt: $color-body → var(--text), $color-link → var(--accent) usw. Vollständige Zuordnung in UPGRADE-1.1.md.
• Übersetzungsschlüssel entfernt aus dem Kern (im Demo-Theme weiterhin vorhanden): header.tagline, nav.projects, nav.search, blog.published_on, blog.comments_disabled. Wenn deine Templates '...'|trans auf diese Schlüssel aufrufen, passe das an.
• Verzeichnis docs/examples/ entfernt: Die nützlichen Teile sind nach docs/customization/old-template/ umgezogen; die Scratch-Override-Beispiele wurden durch das Bare/Demo-Modell abgelöst.

Siehe UPGRADE-1.1.md für die vollständige Liste mit Vorher/Nachher-Snippets.

Ebenfalls neu in 1.1.0#

• Lesezeit und Lesefortschritt auf Posts, Docs und Releases.
• Sprachumschalter als Twig-Extension (lang_switch_urls) mit korrekten Fallback-Ketten für Archive, paginierte Listen und Startseiten.
• Post-Excerpts entfernen Überschrift-Anker — keine verirrten #-Zeichen mehr in den Listenkarten.
• Test-Suite-Gerüst unter tests/Unit/, tests/Integration/, tests/Fixtures/ mit initialer Abdeckung und einem vom Host ausführbaren test-Befehl.
• KI-Agent-Skills unter .claude/skills/ für die Arbeit am Repo: Locales hinzufügen, Doc-Alignment-Checks, Site-Sweeps, Übersetzungen und Erstellen von Upgrade-Guides.

Vollständiges Changelog#

Jede Änderung mit Kategorie: CHANGELOG.md.

Nach mehreren Monaten internem Einsatz in persönlichen Projekten markiere ich das erste stabile Release. Der Kern-Funktionsumfang ist solide genug, um damit echte Seiten zu bauen.

Content-Pipeline#

Die Content-Pipeline ist das Herzstück von notACMS. Sie liest das local/content/-Verzeichnis, parst Frontmatter und generiert mit einem einzigen Befehl eine vollständige statische Seite.

• Markdown-Inhalte mit YAML-Frontmatter
• CommonMark-Rendering mit Überschriften-Permalinks
• Excerpt-Generierung aus Fließtext
• Berechnung der Lesezeit

Mehrsprachiges Routing#

Locales werden in _site.yaml definiert. Jede Locale erhält ihren eigenen URL-Raum, mit optionalen Pfadüberschreibungen in _routes.yaml. hreflang-Tags werden automatisch generiert.

locales:
  en:
    label: "English"
    date_format: "M d, Y"
  pl:
    label: "Polski"
    date_format: "d.m.Y"

Pagefind-Suche#

Volltextsuche ist über Pagefind in die statische Ausgabe eingebaut. Der Build-Befehl generiert den Suchindex automatisch. Keine externe API, keine serverseitige Suche — nur ein statischer Index, der auch offline funktioniert.

Bildverarbeitung#

Bilder, die sich neben den Inhalten befinden, werden beim Build verarbeitet. notACMS generiert WebP-Varianten in mehreren Breiten, aktualisiert src-Attribute automatisch mit responsivem srcset und übernimmt die Pfadzuordnung zwischen Inhalts- und Ausgabeverzeichnissen.

DDEV lokale Entwicklung#

Die Entwicklungsumgebung ist mit DDEV vollständig containerisiert. ddev start stellt PHP 8.5, Nginx und alle Build-Werkzeuge bereit. ddev build erzeugt die statische Ausgabe. ddev code-check führt PHPStan und PHP CS Fixer aus.

Breaking Changes#

Dies ist das erste stabile Release. Wer eine Pre-1.0-Version verwendet hat: Das _site.yaml-Schema prüfen — der social-Schlüssel wurde von einer Liste in eine Map geändert.

Upgrade#

git pull
ddev composer install
ddev build

Was als nächstes kommt#

v1.1.0 wird sich auf das Design-System und die Dokumentation konzentrieren. Diese Seite — gebaut mit notACMS — wird zur offiziellen Dokumentation und Design-Referenz.

Ausführlichere Hintergrundgeschichte in meinem persönlichen Blog: I left WordPress.

Das Problem, auf das ich immer wieder stieß#

Jedes PHP-Projekt, an dem ich arbeitete, brauchte irgendwann eine Website. Dokumentation, eine Landingpage, ein Blog — das Übliche. Und jedes Mal, wenn ich nach einem Tool griff, landete ich am selben Ort: einem Tool, das mich dazu brachte, wie es zu denken — nicht wie ein PHP-Entwickler.

Hugo ist schnell, aber seine Template-Sprache ist fremd. Jekyll setzt Ruby voraus. WordPress hat die falsche Form für statische Inhalte. Next.js ist mächtig, verwandelt aber ein Markdown-Publishing-Problem in ein JavaScript-Bundler-Problem.

Ich dachte immer wieder: Ich kenne Symfony bereits. Ich kenne Twig bereits. Ich habe Composer bereits. Warum muss ich ein neues Ökosystem lernen, nur um Text zu veröffentlichen?

Die Entscheidung gegen eine Datenbank#

Das Erste, was ich entschied: keine Datenbank. Nicht „Datenbank optional" — gar keine Datenbank. Inhalte leben in Dateien. Der Build-Prozess liest Dateien. Die Ausgabe sind Dateien.

Das erzwingt eine gewisse Disziplin. Die Inhaltsstruktur muss explizit und vorhersehbar sein. Es gibt keine Datenbankabfrage, auf die man zurückgreifen kann, wenn man verwandte Beiträge finden oder eine Sitemap generieren möchte. Alles muss aus dem Dateibaum ableitbar sein.

Diese Einschränkung stellte sich als die richtige heraus. Sie macht das System leicht verständlich, einfach zu sichern und trivial für KI-Tools nutzbar.

KI-freundlich by Design#

Ich begann darüber ernsthaft nachzudenken, als ich LLMs in meiner täglichen Arbeit einzusetzen begann. Eine KI um Hilfe beim Generieren von Inhalten, Übersetzen von Seiten oder Validieren von YAML-Schemas zu bitten, ist unkompliziert, wenn das Format Plain Text ist.

Bei einem datenbankgestützten CMS müsste man das Schema erklären, SQL schreiben und Migrationen verwalten. Mit notACMS übergibt man der KI ein Verzeichnis mit Markdown-Dateien, und sie kann Inhalte direkt lesen, generieren und bearbeiten — weil das Format einfach Text ist.

Das ist keine nachträglich hinzugefügte Funktion. Es ist der Grund, warum das System so gestaltet ist, wie es ist.

Das Symfony-Fundament#

Ich habe notACMS auf Symfony 7 aufgebaut, aus demselben Grund, warum ich Symfony für alles andere nutze: Es ist explizit, typisiert und gut dokumentiert. Der DI-Container, Konsolenbefehle, Twig — all das ist Standard-Symfony. An der Infrastruktur ist nichts Neuartiges.

Das Content-Modell ist der interessante Teil. Das Routing-System liest _routes.yaml und generiert Symfony-Routen aus dem Content-Baum. Der Build-Befehl rendert jede Route und schreibt statisches HTML. Die Service-Schicht ist schlank und austauschbar.

Was als nächstes kommt#

Dieses erste Release ist ein funktionierendes Fundament. Was ich noch bauen möchte:

• Pagefind-Suchintegration (kommt in v1.0.0)
• Bessere Bild-Pipeline mit WebP-Generierung
• Vollständigere mehrsprachige Unterstützung
• Eine vollwertige Design-Referenz-Seite (dazu entwickelt sich diese Seite gerade)

Das Repository ist öffentlich. Wer mitverfolgen oder beitragen möchte: der Link befindet sich in der Fußzeile.