Ein kleines Follow-up zu 1.2.0 mit zwei Bugfixes und erweiterter Dokumentation.

nginx Charset#

Plaintext-Antworten — /llms.txt, /robots.txt — wurden ohne Charset-Deklaration ausgeliefert. Browser stellten Nicht-ASCII-Zeichen als Kauderwelsch dar. charset utf-8; ist jetzt auf Server-Block-Ebene in docker/nginx.conf.template gesetzt, sodass jeder Antworttyp automatisch die korrekte Deklaration erhält.

Mehrdeutige Directory-Key-Warnung#

Die Warnung "Ambiguous directory key" wurde bisher zur Zeit des Baum-Aufbaus ausgelöst — in dem Moment, wenn ein zweites Content-Element mit demselben Basename registriert wurde — unabhängig davon, ob dieser kurze Key jemals in einem Template tatsächlich verwendet wurde.

Die Warnung wird jetzt auf den tatsächlichen Lookup verschoben: Sie erscheint einmalig und nur dann, wenn content_item() oder content_url() mit einem mehrdeutigen Kurz-Key aufgerufen wird. Sites mit Namenskollisionen in verschiedenen Content-Abschnitten sehen keine überflüssigen Warnungen mehr für Keys, die sie nie referenzieren.

Zwei neue Dokumentationsseiten#

Das Demo-Theme hat jetzt Seiten für Theme-Entwicklung und Sicherheit, verfügbar in allen vier Sprachversionen.

Theme-Entwicklung behandelt das vollständige Template-Schichten-Modell — wie local/templates/, registrierte Theme-Pfade und das Bare-Core nach Priorität aufgelöst werden — sowie eine Referenz für Template-Kontext-Verträge, Twig-Globals, Funktionen und Filter, die ContentItem-API, erforderliche Übersetzungsschlüssel und die sechs Portabilitätsregeln, die jedes Theme befolgen sollte.

Sicherheit erklärt das Bedrohungsmodell, das die Sicherheitsentscheidungen von notACMS prägt: keine Datenbank, kein dynamisches Rendering, eine Build-Pipeline, die niemals Content ausführt. Die Seite behandelt die eingebauten Schutzmaßnahmen (Turnstile-Hostname-Validierung, Path-Traversal-Schutz, strikte Typen), das bewusste CSRF-Design beim Kontaktformular und die Deployment-Best-Practices für eine Produktionsinstanz.

Beide Seiten erscheinen im Dokumentations-Dropdown der Navigation und in der Seitenleiste.

Vollständiger Changelog#

CHANGELOG.md

1.2.0 ist das Ergebnis eines vollständigen Audits von notACMS — Architektur, Sicherheit, Codequalität und beide Template-Bäume. Rund 170 Findings wurden behoben. Die Highlights:

Robustheit#

• Eine Markdown-Datei mit kaputtem Frontmatter legt nicht mehr eine ganze Sprache oder den Build lahm — sie wird übersprungen und mit Pfad und Fehler gemeldet.
• Ein fehlendes slug: kann die Startseite nicht mehr still übernehmen; posts_per_page: 0 crasht den Blog nicht mehr; doppelte URLs, mehrdeutige Verzeichnisschlüssel und ungültige Tag-Werte erzeugen klare Build-Warnungen.
• Entwürfe und geplante Seiten werden jetzt wirklich aus Builds, Menüs und /llms.txt ausgeschlossen — bisher wurden nur Beiträge gefiltert.
• app:build -o <dir> weigert sich ohne --force, ein anderes Verzeichnis als das konfigurierte Static-Verzeichnis zu leeren.
• Der Aufruf von /pl/ beim ersten Besuch leitet nicht mehr auf die englische Version um — die URL gilt als Sprachauswahl und ein Cookie wird gesetzt. Das Locale-Cookie ist jetzt auch Secure-bedingt, sodass der Mechanismus in HTTP-Entwicklungsumgebungen funktioniert.
• Suchergebnis-Ausschnitte zeigen jetzt hervorgehobene Begriffe als echte <mark>-Markierungen statt als wörtlichen <mark>-Text.
• Das bare Starter-Theme enthält jetzt Platzhalter-contact_form-Werte in _site.yaml — kein Build-Fehler mehr bei einer Neuinstallation.

Sicherheit#

• ImageMagick läuft über Symfony\Process mit Argument-Arrays — exec() ist Geschichte.
• Turnstile prüft jetzt den Antwort-Hostname gegen die base_url und loggt einen Fehler, wenn die mitgelieferten Test-Keys in Produktion aktiv sind. Ein Boot-Check warnt bei Platzhalter-APP_SECRET.
• JSON-LD-Output ist hex-escaped (</script> in einem Titel bricht nicht mehr aus), Übersetzungskataloge enthalten kein HTML mehr, und die nginx-Security-Header gelten jetzt auch für /assets/- und /media/-Antworten.
• Die Kontakt-API mit Sprachpräfix war im Docker-Runtime-Deployment wegen eines nginx-Regex-Bugs unerreichbar — behoben.

Für Theme-Entwickler#

• Neu: THEME_BUILDING.md — der vollständige Theme-API-Vertrag: Template-Kontexte pro Route, Twig-Funktionen und -Globals, die ContentItem-API und die Übersetzungsschlüssel, die jedes Theme definieren muss.
• #[LocalizedRoute] funktioniert jetzt in local/src/Controller/, der Sprachwechsel funktioniert korrekt auf Seiten mit 3+ Sprachen, und die Static-Build-Pipeline ist in wiederverwendbare Services zerlegt.

Neu#

• Der Static Build erzeugt jetzt eine /llms.txt-Datei pro Sprache — die neuesten Beiträge in einem maschinenlesbaren Format für LLM-Kontextfenster. Konfigurierbar über llms_limit in _site.yaml (Standard: 5). Das Template ist per-Theme über den @base-Twig-Namespace überschreibbar.

Breaking Changes#

Einige — jede mit einzeiliger Migration. directoryKey() liefert volle Content-Pfade (Basename-Lookups funktionieren weiter), getTree() ist nach ContentTreeProviderInterface umgezogen, blogPosting() nimmt eine benannte Map, der Kontext-Schlüssel lang_switch_url ist weg, vier tote Übersetzungsschlüssel wurden entfernt und das old-template-Paket aus 1.0 wurde eingestellt. Der vollständige Guide: UPGRADE-1.2.md.

Sofort aktualisieren. Führe composer update im Projekt aus und rebuild anschließend.

Symfony 7.4.13 (6 CVEs)#

• CVE-2026-48489 — Firewall-Umgehung: der failure_forward-Handler wertete einen vom Angreifer kontrollierten _failure_path-Parameter im internen Subrequest aus und ermöglichte so das Umgehen der Firewall.
• CVE-2026-48736 — SSRF-Umgehung in NoPrivateNetworkHttpClient und IpUtils::PRIVATE_SUBNETS über IPv6-Übergangsadressformen (IPv4-mapped, IPv4-compatible, 6to4, Teredo).
• CVE-2026-48761 — HtmlSanitizer bereinigt URL-Attribute auf <object>, <applet>, <iframe>, <img> und die URL im <meta http-equiv="refresh">-Inhalt nicht.
• CVE-2026-48760 — HtmlSanitizer akzeptierte prozentkodierte BiDi-Zeichen und Unicode-Whitespace in URLs und ermöglichte so eine Sanitizer-Umgehung durch visuelles Spoofing.
• CVE-2026-48784 — UrlGenerator kodierte verkettete ../- und ./-Segmente falsch und erzeugte URLs, die aus dem beabsichtigten Pfad herausführen konnten.
• CVE-2026-48747 — Mailer: Der Webhook-Signaturalgorithmus von Mailomat war nicht auf SHA-256 festgelegt, was Algorithm-Substitution-Angriffe ermöglichte.

Vollständige Liste: symfony.com/blog/symfony-7-4-13-released.

Twig 3.27.0 (5 CVEs)#

Alle fünf sind Sandbox-Umgehungen. Wenn dein Theme benutzergesteuerte Templates in einer Sandbox rendert, sind diese kritisch:

• CVE-2026-46636 — Umgehung der Allowlist für Filter, Tags und Funktionen, wenn sich der Sandbox-Status zwischen Renders in langlebigen Prozessen ändert (z. B. FrankenPHP, RoadRunner).
• CVE-2026-48808 — column-Filter umgeht die Property-Allowlist unter SourcePolicyInterface.
• CVE-2026-48806 — __toString()-Policy-Umgehung über dynamische Mapping-Keys: {% set arr = {(obj): "value"} %}.
• CVE-2026-48807 — __toString()-Policy-Umgehung über Traversable-Objekte in den Filtern join/replace und den Operatoren in/not in.
• CVE-2026-48805 — Sandbox-Statusregression in veralteten internen Wrappern (twig_check_arrow_in_sandbox(), twig_array_some(), twig_array_every()).

Weitere Änderungen in 1.1.4#

• symfony/polyfill-* von v1.37.0 auf v1.38.1 aktualisiert.
• Dev-Abhängigkeiten aktualisiert: phpstan/phpstan 2.1.55 → 2.2.1, phpunit/phpunit 13.1.10 → 13.1.13, rector/rector 2.4.4 → 2.4.5.

So aktualisierst du#

composer update
ddev build   # oder das entsprechende Build-Kommando in deiner Umgebung

Es sind keine Konfigurationsänderungen oder Migrationsschritte erforderlich.

Vollständiges Changelog#

CHANGELOG.md

Sechs JSON-Schema-Draft-07-Dateien liegen nun unter config/schema/:

Alle Template-YAML-Dateien (_site.yaml, _routes.yaml, _tags.yaml) in docs/bare/, docs/demo/ und docs/customization/old-template/ enthalten jetzt einen # yaml-language-server: $schema=-Kommentar mit dem URL auf den main-Branch. VS Code (und jeder Editor mit YAML Language Server) erkennt diese automatisch — Validierung und Autovervollständigung funktionieren ohne zusätzliche Projektkonfiguration.

Die Schemas sind für KI-gestütztes Authoring optimiert: Beschreibungen enthalten Standardwerte, Constraints und Verhaltensdetails, sodass ein KI-Agent in einem anderen Projekt ein Schema abrufen und genau wissen kann, was jedes Feld bewirkt.

Ein Schema direkt vom main-Branch abrufen:

https://raw.githubusercontent.com/holas1337/notACMS/main/config/schema/<name>.schema.json

Sicherheitsupdate: Symfony 7.4.12 und Twig 3.26.0#

Sofort aktualisieren. Führe composer update im Projekt aus und rebuild anschließend.

Symfony 7.4.12 (21 CVEs)#

Die relevantesten für CMS-Deployments:

• CVE-2026-45073 — SQL-Injection in Cache durch nicht validierten $prefix in PdoAdapter::doClear().
• CVE-2026-45071 — XXE / lokale Dateioffenlegung in DomCrawler::addXmlContent() bei aktiviertem validateOnParse.
• CVE-2026-45075 — HEAD-Anfragen umgehen den methods-Filter in den Attributen #[IsGranted], #[IsCsrfTokenValid] und #[IsSignatureValid].
• CVE-2026-45072 — XSS in CodeExtension::fileExcerpt() in TwigBridge.
• CVE-2026-45068 — Header-Injection in SendmailTransport; Adressen, die mit einem Bindestrich beginnen, werden nun abgelehnt.
• CVE-2026-45067 — E-Mail-Adressen mit Zeilenumbrüchen wurden von Mime\Address akzeptiert — werden nun abgelehnt.
• CVE-2026-45305 / 45304 / 45133 — Katastrophales Backtracking und unbegrenzte Rekursion im YAML-Parser.
• CVE-2026-45066 / 45064 / 45753 — Drei HtmlSanitizer-Umgehungen: BiDi-Override-Zeichen, URL-Parser-Differenzen sowie nicht bereinigte action/formaction/poster/cite-Attribute.

Vollständige Liste: symfony.com/blog/symfony-7-4-12-released.

Twig 3.26.0 (4 CVEs)#

Alle vier sind Sandbox-Umgehungen. Wenn dein Theme Twigs Sandbox für benutzerbereitgestellte Templates verwendet, sind diese kritisch:

• CVE-2026-46635 — Umgehung der Property-Allowlist über den column-Filter (array_column auf Objekten).
• CVE-2026-46638 — {% sandbox %}{% include %} überspringt checkSecurity() bei gecachten Templates; unvollständige Behebung von CVE-2024-45411.
• CVE-2026-24425 — Sandbox-Umgehung bei Verwendung einer Source-Policy.
• CVE-2026-47732 — Mehrfache __toString()-Policy-Umgehungen über ungesicherte String-Koerzionspunkte.

Weitere Änderungen in 1.1.3#

• Veraltete Pagefind-Fragmente behoben — scripts/rebuild-content.sh löscht jetzt public/pagefind/ vor der Neuindizierung. Zuvor hinterließen entfernte oder umbenannte Inhalte verwaiste Fragment-Dateien, die Pagefind neben aktuellen Ergebnissen auslieferte.
• DESIGN.md-Verbesserungen — Hartcodierte Hex-Werte in den DESIGN.md-Dateien von bare und demo durch Token-Referenzen ersetzt; primary-Farbalias hinzugefügt; card-hover-Komponenten-Token zum Demo-Theme hinzugefügt.

So aktualisierst du#

composer update
ddev build   # oder das entsprechende Build-Kommando in deiner Umgebung

Es sind keine Konfigurationsänderungen oder Migrationsschritte erforderlich.

Vollständiges Changelog#

CHANGELOG.md

Wenn die Standardlokalisierung deiner Site en ist, waren sowohl /en/blog/ als auch /blog/ erreichbar und lieferten denselben Inhalt aus. Das sind zwei indexierbare URLs für eine Seite — und Suchmaschinen wählen die, die ihnen gefällt, was selten die ist, die du dir wünschst.

1.1.2 ergänzt den DefaultLocaleRedirectListener. Jede Anfrage an /<standardlokalisierung>/... liefert eine 301-Weiterleitung zur URL ohne Präfix:

GET /en/blog/         →  301 Location: /blog/
GET /en/about/?ref=x  →  301 Location: /about/?ref=x
GET /pl/blog/         →  200 (nicht-Standardlokalisierung, unangetastet)

Der Listener läuft vor dem Symfony-Router, sodass die Weiterleitung erfolgt, bevor das Framework überhaupt versucht, eine Route zu treffen — keine verschwendete Arbeit, kein 404-Rauschen in den Logs. Nicht-Standardlokalisierungen (pl, de, fr auf dieser Site) bleiben unangetastet.

Außerdem schließt das eine kleine SEO-Lücke: Backlinks, die das Lokalisierungspräfix versehentlich enthalten, konsolidieren sich nun zur kanonischen URL, statt die Domain-Autorität aufzuteilen.

Schema.org JSON-LD als flüssiger Builder#

Bis 1.1.1 baute jedes Template, das strukturierte Daten benötigte, ein PHP-Array inline ein, leitete es durch |json_encode|raw und packte das Ergebnis in einen <script>-Tag. Sechs Templates, sechs nahezu identische Blöcke — und jeder eine neue Gelegenheit, JSON_UNESCAPED_SLASHES zu vergessen oder <script>false</script> auszuliefern, falls irgendein Frontmatter-Feld ein ungültiges Byte enthielt.

1.1.2 ersetzt das alles durch einen Service und zwei Twig-Funktionen:

{% block structured_data %}{{ json_ld(structured_data().blogPosting(
    content.title(),
    site_base_url ~ content.url(),
    content.date(),
    content.htmlContent,
    site_author.name,
    content.image() ? site_base_url ~ content.image() : null
)) }}{% endblock %}

structured_data() liefert den Builder; verkette eine typisierte Methode (webSite, webPage, blogPosting, collectionPage, contactPage, person, breadcrumbList, organization, imageObject) und das Ergebnis ist ein einfaches Array. json_ld(array) kodiert es und packt es in einen <script type="application/ld+json">-Tag. Leere und null-Werte werden rekursiv entfernt, sodass optionale Eingaben (eine nicht gesetzte Autor-E-Mail, ein fehlendes Bild) schlicht nicht in der Ausgabe erscheinen.

Die Kodierung verwendet jetzt JSON_THROW_ON_ERROR — fehlerhaftes UTF-8 im Frontmatter zeigt sich als echte Exception während des Renderings, statt stillschweigend einen kaputten <script>-Tag auszuliefern.

Die schlichten Kern-Templates für die Seiten contact, default und projects geben jetzt ebenfalls Schema.org-Markup aus. Bisher hatten schlichte Bereitstellungen schlechteres SEO als jedes Anpassungsbeispiel, das wir mitliefern; diese Lücke ist geschlossen.

Die vollständige Builder-API und wie du den structured_data-Block in deinem eigenen Theme überschreibst, findest du im Anpassungsleitfaden → Strukturierte Daten.

Sicherheitsfixes#

Zwei Bugs sind während des 1.1.2-Reviews aufgetaucht und vor der Veröffentlichung behoben worden:

• Open-Redirect über die Pfad-Normalisierung. Die Methode Request::getPathInfo() von Symfony fasst wiederholte Schrägstriche nicht zusammen, sodass eine Anfrage an /<standardlokalisierung>//evil.com andernfalls Location: //evil.com erzeugt hätte — eine protokollrelative Weiterleitung, der Browser cross-origin folgen. Der neue Redirect-Listener verweigert nun Weiterleitungen auf alles, was kein lokaler Pfad mit einem einzelnen führenden Schrägstrich ist.
• XSS in Suchergebnissen. assets/search.js band das excerpt-Feld von Pagefind ohne Escaping in innerHTML ein. Der Demo-Build war bereits korrekt; der Kern war auseinandergedriftet. Beide sind nun synchron. Die <mark>-Hervorhebungstags von Pagefind werden in den Suchergebnissen des Kerns nicht mehr gerendert — ein bewusster Kompromiss zugunsten der sichereren Standardausgabe.

Ebenfalls neu in 1.1.2#

• Interner Twig-Refactor. Die Logik für Sidebar, Breadcrumbs, Beitragslabels, og-Bilder und Blog-Filter wurde aus den Templates in dedizierte Twig-Erweiterungen ausgelagert. Templates konzentrieren sich auf das Layout; Tests können jede Helper-Funktion direkt anvisieren. Neue Anpassungsfläche: siehe Layout-Helfer im Anpassungsleitfaden.
• O(1)-Lookups nach Verzeichnisschlüssel in ContentTree — eine kleine Performance-Verbesserung auf Sites mit Hunderten von Seiten.
• docs/customization/old-template/ ist nun veraltet und wird in 1.2.0 entfernt. Es war eine einmalige Übergangshilfe für 1.0→1.1; neue Anpassungsarbeiten sollten von custom-footer/ oder self-hosted-fonts/ ausgehen.
• Abhängigkeitsupdates: Symfony 7.4.8 → 7.4.9 im gesamten Bundle, PHPStan 2.1.51 → 2.1.54, PHPUnit 13.1.7 → 13.1.8.

Vollständige Liste der Änderungen#

Alle Änderungen mit Kategorien: CHANGELOG.md.

Navigationslabels für Content-Seiten kommen jetzt aus dem Frontmatter — nicht aus Übersetzungskeys. Setze menu.label im Frontmatter einer Seite und es wird zum Label in der Navigation; lass es weg und der Seiten-title wird als Fallback genutzt.

---
title: "Architektur-Leitfaden"
slug: "architecture-guide"
menu:
  label: "Architektur"
  weight: 30
---

Die neue Twig-Funktion content_item() löst jede Content-Seite über den Directory-Key auf:

{{ content_item('architecture-guide', 'de').menuLabel() }}
{# → "Architektur" (oder der Seitentitel, wenn menu.label fehlt) #}

Warum das wichtig ist: Bisher musste jede messages.*.yaml pro Locale Übersetzungen für nav.home, nav.blog, nav.about, nav.contact, nav.privacy_policy (Core) und site.releases, site.about, site.manual, site.architecture, site.customization, site.locales, site.design_reference, site.contact (Demo) enthalten. Eine neue Seite bedeutete N Übersetzungsdateien zu aktualisieren. Jetzt reicht ein Frontmatter-Feld. Custom Templates, die auf die entfernten Keys verweisen, sollten auf content_item('key', locale).menuLabel() umsteigen.

Deploy respektiert bestehenden Inhalt#

Der Bug#

./notACMS deploy --prod würde bei jedem Deploy das gesamte local/-Verzeichnis sichern und durch docs/demo/ ersetzen — selbst wenn es bereits eigenen Inhalt, Templates und Anpassungen enthielt. Die Seed-Logik unterschied nicht zwischen „Nutzer möchte explizit ein Theme neu seeden" und „Nutzer möchte nur mit bestehendem Inhalt redeployen."

Der Fix#

Deploy verhält sich jetzt genauso wie ddev build:

• Kein --bare / --demo Flag → seedet local/ nur wenn es fehlt oder leer ist; überspringt, wenn Inhalt vorhanden ist.
• --bare oder --demo explizit übergeben → sichert bestehendes local/ und seedet das gewählte Theme.

./notACMS deploy --prod          # bestehendes local/ bleibt erhalten
./notACMS deploy --prod --demo   # erzwingt Neu-Seed aus docs/demo/
./notACMS deploy --prod --bare   # erzwingt Neu-Seed aus docs/bare/

--prod steuert jetzt nur Composer-Flags (--no-dev) und die Laufzeitumgebung (APP_ENV=prod). Es berührt local/ nie.

Ebenfalls in 1.1.1#

• Dependency-Update: symfony/polyfill-* Pakete aktualisiert von v1.36.0 auf v1.37.0.
• Polnische, deutsche und französische Demo-Inhalte überprüft und verbessert auf allen Seiten und Blog-Posts.
• Übersetzungsstil-Guides zum AI-Agent-Skill-System für Polnisch, Deutsch und Französisch hinzugefügt, um konsistente Qualität bei zukünftigen Übersetzungen sicherzustellen.

Vollständige Liste der Änderungen#

Alle Änderungen mit Kategorien: CHANGELOG.md.

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 befindet sich 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 anzupassen, 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 befinden sich 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ändige Liste der Änderungen#

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.

Inhalts-Pipeline#

Die Inhalts-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 befinden sich 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 vom Konzept her#

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 Inhaltsmodell ist der interessante Teil. Das Routing-System liest _routes.yaml und generiert Symfony-Routen aus dem Inhaltsbaum. 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.