Un petit suivi de 1.2.0 avec deux corrections de bugs et une documentation étendue.

Charset nginx#

Les réponses texte — /llms.txt, /robots.txt — étaient servies sans déclaration de charset. Les navigateurs affichaient les caractères non-ASCII comme du charabia. charset utf-8; est maintenant défini au niveau du bloc serveur dans docker/nginx.conf.template, de sorte que chaque type de réponse reçoit automatiquement la déclaration correcte.

Avertissement de clé de répertoire ambiguë#

L'avertissement "Ambiguous directory key" se déclenchait auparavant lors de la construction de l'arbre — au moment où un second élément de contenu enregistrait un basename en conflit — indépendamment du fait que cette clé courte soit jamais utilisée dans un template.

L'avertissement est maintenant différé jusqu'à la recherche effective : il se déclenche une seule fois, et uniquement quand content_item() ou content_url() est appelé avec une clé courte ambiguë. Les sites avec des collisions de noms dans différentes sections de contenu ne voient plus d'avertissements superflus pour des clés qu'ils ne référencent jamais.

Deux nouvelles pages de documentation#

Le thème demo dispose maintenant de pages pour Construction de Thème et Sécurité, disponibles dans les quatre locales.

Construction de Thème couvre le modèle complet de couches de templates — comment local/templates/, les chemins de thème enregistrés et le bare core sont résolus par ordre de priorité — ainsi qu'une référence pour les contrats de contexte de template, les globales Twig, les fonctions et filtres, l'API ContentItem, les clés de traduction requises et les six règles de portabilité que tout thème devrait suivre.

Sécurité explique le modèle de menace qui guide les décisions de sécurité de notACMS : pas de base de données, pas de rendu dynamique, un pipeline de compilation qui n'exécute jamais le contenu. La page couvre les protections intégrées (validation du hostname Turnstile, protection contre la traversée de chemin, types stricts), la conception CSRF délibérée du formulaire de contact et les bonnes pratiques de déploiement pour une instance de production.

Les deux pages apparaissent dans le menu déroulant Documentation et dans la barre latérale.

Changelog complet#

CHANGELOG.md

1.2.0 est le résultat d'un audit complet de notACMS — architecture, sécurité, qualité du code et les deux arborescences de templates. Environ 170 problèmes ont été corrigés. Les points forts :

Robustesse#

• Un fichier markdown au frontmatter invalide ne fait plus planter une langue entière ni le build — il est ignoré et signalé avec son chemin et le détail de l'erreur.
• Un slug: manquant ne peut plus détourner silencieusement la page d'accueil ; posts_per_page: 0 ne plante plus le blog ; les URL dupliquées, les clés de répertoire ambiguës et les tags invalides produisent désormais des avertissements de build explicites.
• Les brouillons et les pages planifiées sont maintenant réellement exclus des builds, des menus et de /llms.txt — seuls les billets étaient filtrés jusqu'ici.
• app:build -o <dir> refuse de vider un répertoire autre que le répertoire statique configuré sans --force.
• Visiter /pl/ pour la première fois ne redirige plus vers la version anglaise — l'URL est interprétée comme un choix de langue et un cookie est enregistré. Le cookie est maintenant conditionnel à Secure pour fonctionner aussi en HTTP.
• Les extraits des résultats de recherche affichent désormais les surlignages comme de vraies balises <mark>, et non comme du texte littéral <mark>.
• Le _site.yaml du thème de base contient maintenant des valeurs fictives pour contact_form — plus d'erreur de build à la première installation.

Sécurité#

• ImageMagick passe maintenant par Symfony\Process avec des tableaux d'arguments — exec() a disparu.
• Turnstile valide le hostname de la réponse par rapport à base_url et journalise une erreur quand les clés de test toujours-valides sont actives en production. Un contrôle au démarrage avertit si APP_SECRET est resté le placeholder par défaut.
• La sortie JSON-LD est hex-échappée (</script> dans un titre ne peut plus s'en échapper), les catalogues de traduction ne contiennent plus de HTML, et les en-têtes de sécurité nginx s'appliquent maintenant aussi aux réponses /assets/ et /media/.
• L'API de contact préfixée par la langue était inaccessible dans le déploiement Docker à cause d'un bug de regex nginx — corrigé.

Pour les créateurs de thèmes#

• Nouveau : THEME_BUILDING.md — le contrat complet de l'API de thèmes : contextes de templates par route, fonctions et globales Twig, l'API ContentItem et les clés de traduction que chaque thème doit définir.
• #[LocalizedRoute] fonctionne maintenant dans local/src/Controller/, le changement de langue fonctionne correctement sur les sites à 3 langues et plus, et le pipeline de build statique est décomposé en services réutilisables.

Nouveautés#

• Le build statique génère désormais un fichier /llms.txt par langue — les billets les plus récents dans un format lisible par les LLM. Configurable via llms_limit dans _site.yaml (par défaut : 5). Le template est personnalisable par thème via le namespace Twig @base.

Changements cassants#

Quelques-uns — chacun avec une migration en une ligne. directoryKey() renvoie maintenant les chemins de contenu complets (la recherche par nom de base fonctionne toujours), getTree() a été déplacé vers ContentTreeProviderInterface, blogPosting() accepte une map nommée, la clé de contexte lang_switch_url a disparu, quatre clés de traduction inutilisées ont été supprimées et le paquet old-template de la 1.0 a été retiré. Le guide complet : UPGRADE-1.2.md.

Mettez à jour immédiatement. Lancez composer update dans votre projet, puis rebuilder.

Symfony 7.4.13 (6 CVEs)#

• CVE-2026-48489 — contournement du firewall de sécurité : le handler failure_forward honorait un paramètre _failure_path contrôlé par l'attaquant dans la sous-requête interne, permettant de contourner le firewall.
• CVE-2026-48736 — contournement SSRF dans NoPrivateNetworkHttpClient et IpUtils::PRIVATE_SUBNETS via des formes de transition IPv6 (IPv4-mapped, IPv4-compatible, 6to4, Teredo).
• CVE-2026-48761 — HtmlSanitizer ne nettoyait pas les attributs URL sur <object>, <applet>, <iframe>, <img> et l'URL dans le contenu <meta http-equiv="refresh">.
• CVE-2026-48760 — HtmlSanitizer acceptait des marques BiDi encodées en pourcentage et des espaces Unicode dans les URLs, permettant un contournement du sanitizer par usurpation visuelle.
• CVE-2026-48784 — UrlGenerator encodait incorrectement les segments ../ et ./ chaînés, produisant des URLs pouvant sortir du chemin prévu.
• CVE-2026-48747 — Mailer : l'algorithme de signature du webhook Mailomat n'était pas fixé à SHA-256, permettant des attaques par substitution d'algorithme.

Liste complète : symfony.com/blog/symfony-7-4-13-released.

Twig 3.27.0 (5 CVEs)#

Les cinq sont des contournements de sandbox. Si votre thème rend des templates contrôlés par l'utilisateur dans un sandbox, ils sont critiques :

• CVE-2026-46636 — contournement de la liste d'autorisation des filtres, tags et fonctions lorsque l'état du sandbox change entre les rendus dans des workers de longue durée (ex. FrankenPHP, RoadRunner).
• CVE-2026-48808 — le filtre column contournait la liste des propriétés autorisées sous SourcePolicyInterface.
• CVE-2026-48806 — contournement de la politique __toString() via des clés de mapping dynamiques : {% set arr = {(obj): "value"} %}.
• CVE-2026-48807 — contournement de la politique __toString() via des objets Traversable dans les filtres join/replace et les opérateurs in/not in.
• CVE-2026-48805 — régression d'état du sandbox dans les wrappers internes dépréciés (twig_check_arrow_in_sandbox(), twig_array_some(), twig_array_every()).

Aussi dans 1.1.4#

• symfony/polyfill-* mis à jour de v1.37.0 à v1.38.1.
• Dépendances de développement : phpstan/phpstan 2.1.55 → 2.2.1, phpunit/phpunit 13.1.10 → 13.1.13, rector/rector 2.4.4 → 2.4.5.

Comment mettre à jour#

composer update
ddev build   # ou la commande de build équivalente dans votre environnement

Aucune modification de configuration ni étape de migration n'est nécessaire.

Changelog complet#

CHANGELOG.md

Six fichiers JSON Schema draft-07 se trouvent maintenant dans config/schema/ :

Tous les fichiers YAML de template (_site.yaml, _routes.yaml, _tags.yaml) dans docs/bare/, docs/demo/ et docs/customization/old-template/ portent désormais un commentaire # yaml-language-server: $schema= pointant vers l'URL brute sur la branche main. VS Code (et tout éditeur avec YAML Language Server) les détecte automatiquement — validation et autocomplétion fonctionnent sans aucune configuration de projet supplémentaire.

Les schémas sont optimisés pour l'authoring assisté par IA : les descriptions incluent les valeurs par défaut, les contraintes et les explications de comportement, pour qu'un agent IA dans un autre projet puisse récupérer un schéma et savoir exactement ce que fait chaque champ.

Récupérer n'importe quel schéma directement depuis la branche main :

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

Mise à jour de sécurité : Symfony 7.4.12 et Twig 3.26.0#

Mettez à jour immédiatement. Lancez composer update dans votre projet, puis rebuilder.

Symfony 7.4.12 (21 CVEs)#

Les plus impactantes pour un déploiement CMS :

• CVE-2026-45073 — injection SQL dans Cache via un $prefix non validé dans PdoAdapter::doClear().
• CVE-2026-45071 — XXE / divulgation de fichiers locaux dans DomCrawler::addXmlContent() avec validateOnParse activé.
• CVE-2026-45075 — les requêtes HEAD contournent le filtre methods des attributs #[IsGranted], #[IsCsrfTokenValid] et #[IsSignatureValid].
• CVE-2026-45072 — XSS dans CodeExtension::fileExcerpt() de TwigBridge.
• CVE-2026-45068 — injection d'en-tête dans SendmailTransport ; les adresses commençant par un tiret sont désormais rejetées.
• CVE-2026-45067 — les adresses e-mail contenant des sauts de ligne étaient acceptées par Mime\Address — elles sont maintenant rejetées.
• CVE-2026-45305 / 45304 / 45133 — backtracking catastrophique et récursion illimitée dans le parseur YAML.
• CVE-2026-45066 / 45064 / 45753 — trois contournements de HtmlSanitizer : caractères BiDi override, différences de parseurs d'URL et attributs action/formaction/poster/cite non assainis.

Liste complète : symfony.com/blog/symfony-7-4-12-released.

Twig 3.26.0 (4 CVEs)#

Les quatre sont des contournements de sandbox. Si votre thème utilise le sandbox de Twig pour des templates fournis par les utilisateurs, ils sont critiques :

• CVE-2026-46635 — contournement de la liste des propriétés autorisées via le filtre column (array_column sur des objets).
• CVE-2026-46638 — {% sandbox %}{% include %} ignore checkSecurity() sur les templates mis en cache ; correction incomplète de CVE-2024-45411.
• CVE-2026-24425 — contournement du sandbox via une source policy.
• CVE-2026-47732 — multiples contournements de la politique __toString() via des points de coercition de chaîne non protégés.

Aussi dans 1.1.3#

• Fragments Pagefind obsolètes corrigés — scripts/rebuild-content.sh supprime maintenant public/pagefind/ avant de réindexer. Auparavant, supprimer ou renommer du contenu laissait des fichiers de fragments orphelins que Pagefind servait avec les résultats à jour.
• Améliorations DESIGN.md — les valeurs hex codées en dur remplacées par des références aux tokens dans les fichiers DESIGN.md bare et demo ; alias de couleur primary ajouté ; token de composant card-hover ajouté au thème demo.

Comment mettre à jour#

composer update
ddev build   # ou la commande de build équivalente dans votre environnement

Aucune modification de configuration ni étape de migration n'est nécessaire.

Changelog complet#

CHANGELOG.md

Si la locale par défaut de votre site est en, /en/blog/ et /blog/ étaient toutes deux accessibles et rendaient le même contenu. Cela fait deux URL indexables pour une seule page — et les moteurs de recherche choisissent celle qu'ils veulent, qui est rarement celle que vous souhaitez.

1.1.2 ajoute le DefaultLocaleRedirectListener. Chaque requête vers /<locale-par-défaut>/... retourne une 301 vers l'URL sans préfixe :

GET /en/blog/         →  301 Location: /blog/
GET /en/about/?ref=x  →  301 Location: /about/?ref=x
GET /pl/blog/         →  200 (locale non par défaut, intacte)

L'écouteur s'exécute avant le routeur Symfony, de sorte que la redirection a lieu avant même que le framework ne tente de faire correspondre une route — pas de travail gaspillé, pas de bruit 404 dans les logs. Les locales non par défaut (pl, de, fr sur ce site) restent intactes.

Cela ferme également une petite fuite SEO : les liens entrants qui incluent accidentellement le préfixe de locale se consolident désormais vers l'URL canonique au lieu de diviser l'autorité du domaine.

Le JSON-LD Schema.org comme constructeur fluide#

Jusqu'en 1.1.1, chaque template ayant besoin de données structurées intégrait un tableau PHP, le passait à |json_encode|raw et enveloppait le résultat dans une balise <script>. Six templates, six blocs presque identiques — et chacun une nouvelle occasion d'oublier JSON_UNESCAPED_SLASHES ou de livrer <script>false</script> si un champ du frontmatter contenait un octet invalide.

1.1.2 remplace tout cela par un service et deux fonctions Twig :

{% 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() retourne le constructeur ; chaînez une méthode typée (webSite, webPage, blogPosting, collectionPage, contactPage, person, breadcrumbList, organization, imageObject) et le résultat est un simple tableau. json_ld(array) l'encode et l'enveloppe dans une balise <script type="application/ld+json">. Les champs vides et null sont supprimés récursivement, donc les entrées optionnelles (un email d'auteur non défini, une image manquante) n'apparaissent simplement pas dans la sortie.

L'encodage utilise désormais JSON_THROW_ON_ERROR — un UTF-8 invalide dans le frontmatter remonte comme une véritable exception au rendu, au lieu de livrer silencieusement une balise <script> cassée.

Les templates de base du cœur pour les pages contact, default et projects émettent désormais aussi le balisage Schema.org. Auparavant, les déploiements bare avaient un SEO plus faible que tous les exemples de personnalisation que nous fournissons ; cet écart est comblé.

Consultez le guide de personnalisation → Données structurées pour l'API complète du constructeur et pour savoir comment surcharger le bloc structured_data dans votre propre thème.

Correctifs de sécurité#

Deux bugs ont été identifiés lors de la revue de 1.1.2 et corrigés avant la sortie :

• Redirection ouverte via la normalisation des chemins. La méthode Request::getPathInfo() de Symfony ne réduit pas les barres obliques répétées ; ainsi, une requête vers /<locale-par-défaut>//evil.com aurait sinon produit Location: //evil.com — une redirection relative au protocole que les navigateurs suivent vers une autre origine. Le nouvel écouteur de redirection refuse désormais d'émettre des redirections vers tout ce qui n'est pas un chemin local enraciné par une seule barre oblique.
• XSS dans les résultats de recherche. assets/search.js injectait le champ excerpt de Pagefind dans innerHTML sans échappement. La build de démonstration était déjà correcte ; le cœur avait dérivé. Les deux sont désormais synchronisés. Les balises de surlignage <mark> de Pagefind ne sont plus rendues dans les résultats de recherche du cœur — un compromis volontaire au profit d'une valeur par défaut plus sûre.

Également nouveau en 1.1.2#

• Refactorisation interne de Twig. La logique des barres latérales, des fils d'Ariane, des badges d'articles, des images og et des filtres de blog a été déplacée des templates vers des extensions Twig dédiées. Les templates restent concentrés sur la mise en page ; les tests peuvent cibler chaque fonction d'aide directement. Nouvelle surface de personnalisation : voir les Aides de mise en page dans le guide de personnalisation.
• Recherches par clé de répertoire en O(1) dans ContentTree — une petite amélioration de performance sur les sites comportant des centaines de pages.
• docs/customization/old-template/ est désormais déprécié et sera supprimé en 1.2.0. C'était une aide de transition ponctuelle pour 1.0→1.1 ; les nouveaux travaux de personnalisation devraient partir de custom-footer/ ou self-hosted-fonts/.
• Mises à jour des dépendances : Symfony 7.4.8 → 7.4.9 dans tout le bundle, PHPStan 2.1.51 → 2.1.54, PHPUnit 13.1.7 → 13.1.8.

Liste complète des modifications#

Toutes les modifications avec leur catégorie : CHANGELOG.md.

Les labels de navigation des pages de contenu proviennent désormais du frontmatter — pas des clés de traduction. Définissez menu.label dans le frontmatter d'une page, et ce texte devient le label du menu ; omettez-le, et le title de la page sera utilisé comme fallback.

---
title: "Guide d'architecture"
slug: "architecture-guide"
menu:
  label: "Architecture"
  weight: 30
---

La nouvelle fonction Twig content_item() résout n'importe quelle page de contenu par sa clé de répertoire :

{{ content_item('architecture-guide', 'fr').menuLabel() }}
{# → "Architecture" (ou le titre de la page si menu.label est absent) #}

Pourquoi c'est important : Auparavant, chaque fichier messages.*.yaml devait dupliquer les traductions pour nav.home, nav.blog, nav.about, nav.contact, nav.privacy_policy (core) et site.releases, site.about, site.manual, site.architecture, site.customization, site.locales, site.design_reference, site.contact (démo). Ajouter une page impliquait de mettre à jour N fichiers de traduction. Maintenant, il suffit d'un champ dans le frontmatter. Les templates personnalisés qui référencent ces clés supprimées doivent migrer vers content_item('key', locale).menuLabel().

Deploy préserve le contenu existant#

Le bug#

Exécuter ./notACMS deploy --prod sauvegardait et remplaçait tout le répertoire local/ par docs/demo/ à chaque déploiement — même lorsqu'il contenait déjà votre contenu, templates et personnalisations. La logique de seeding ne distinguait pas « l'utilisateur a explicitement demandé un re-seed du thème » de « l'utilisateur veut juste redéployer avec le contenu existant. »

Le correctif#

Deploy fonctionne désormais exactement comme ddev build :

• Pas de flag --bare / --demo → seede local/ uniquement s'il est absent ou vide ; ignore s'il contient du contenu.
• --bare ou --demo passé explicitement → sauvegarde le local/ existant et seede le thème choisi.

./notACMS deploy --prod          # préserve le local/ existant
./notACMS deploy --prod --demo   # force le re-seed depuis docs/demo/
./notACMS deploy --prod --bare   # force le re-seed depuis docs/bare/

--prod ne contrôle désormais que les flags Composer (--no-dev) et l'environnement d'exécution (APP_ENV=prod). Il ne touche jamais à local/.

Également dans 1.1.1#

• Mise à jour des dépendances : paquets symfony/polyfill-* mis à jour de v1.36.0 à v1.37.0.
• Contenu démo polonais, allemand et français révisé et amélioré sur toutes les pages et articles du blog.
• Guides de style de traduction ajoutés au système de compétences de l'agent IA pour le polonais, l'allemand et le français afin d'assurer une qualité cohérente pour les traductions futures.

Liste complète des modifications#

Tous les changements avec leur catégorie : CHANGELOG.md.

Le changement phare de 1.1.0 : notACMS livre désormais deux thèmes d'origine, et vous en choisissez un dès votre tout premier build :

./notACMS deploy --demo    # par défaut — le design amber-phosphor que vous voyez ici
./notACMS deploy --bare    # un wireframe minimal : polices système, mode clair, ~200 lignes de CSS

ddev build accepte les mêmes flags. Quel que soit votre choix, toutes les fonctionnalités fonctionnent : contenu multilingue, blog, RSS, sitemap, recherche, formulaire de contact, images avec variantes responsives, temps de lecture, indicateur de progression. La différence ne se joue que sur l'apparence — et, surtout, sur ce que vous héritez avant de commencer à personnaliser.

Cœur minimal#

Le cœur situé dans templates/, assets/, translations/ est désormais un wireframe. Il est volontairement minimal pour que surcharger un seul bloc ne traîne pas derrière lui un langage visuel contre lequel il faudrait lutter. Si vous construisez un design sur mesure, partez du bare et vous maîtrisez l'intégralité du rendu dès le premier jour.

Thème démo#

Le démo se trouve sous docs/demo/ et est copié dans local/ quand vous choisissez --demo. C'est le design amber-phosphor complet que vous lisez en ce moment — mode sombre, overlay de recherche, sidebar docs, bouton de thème, tout y est. Partez de là si vous voulez un design abouti dès aujourd'hui et prévoyez d'ajuster, pas de reconstruire.

Le système de surcharges local/#

Les deux thèmes utilisent le même mécanisme : chaque fichier dans local/ prend le pas sur le chemin correspondant du cœur.

Le cœur n'est jamais modifié. git pull reste propre. Les personnalisations se trouvent dans le dépôt de votre site, pas dans un fork de celui-ci.

Mise à niveau depuis 1.0.0#

Si vous tourniez en 1.0.0 et voulez que votre site ait exactement la même apparence, le paquet de compatibilité tient en une ligne :

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

Cela dépose le thème pré-1.1.0 complet — templates, SCSS, polices, images, traductions — dans local/. Votre site s'affiche exactement comme avant. Vous pouvez ensuite retirer des fichiers de local/ au fur et à mesure que vous adoptez de nouveaux éléments de design.

Les vraies ruptures auxquelles vous ferez face si vous aviez personnalisé l'ancien cœur :

• Point d'entrée SCSS renommé : local/assets/styles/local.scss → local/assets/styles/app_local.scss. Renommez le fichier et mettez à jour l'import dans local/assets/app.js.
• Variables SCSS de couleur du cœur remplacées par des CSS custom properties : $color-body → var(--text), $color-link → var(--accent), etc. Correspondance complète dans UPGRADE-1.1.md.
• Clés de traduction retirées du cœur (toujours présentes dans le thème démo) : header.tagline, nav.projects, nav.search, blog.published_on, blog.comments_disabled. Si vos templates appellent '...'|trans dessus, mettez-les à jour.
• Répertoire docs/examples/ retiré : les éléments utiles ont été déplacés vers docs/customization/old-template/ ; les exemples de surcharge ont été supplantés par le modèle bare/démo.

Voir UPGRADE-1.1.md pour la liste complète avec extraits avant/après.

Également nouveau en 1.1.0#

• Temps de lecture et indicateur de progression sur les posts, docs et releases.
• Sélecteur de langue comme extension Twig (lang_switch_urls) avec des chaînes de fallback correctes pour les archives, listes paginées et pages d'accueil.
• Les extraits de posts retirent les ancres de titres — plus de # parasites dans les cartes de liste.
• Ossature de batterie de tests sous tests/Unit/, tests/Integration/, tests/Fixtures/ avec une couverture initiale et une commande test exécutable depuis l'hôte.
• Scripts d'agent IA sous .claude/skills/ pour travailler sur le dépôt : ajout de locales, vérifications d'alignement des docs, balayages de site, traductions et génération de guides de mise à niveau.

Liste complète des modifications#

Chaque changement avec sa catégorie : CHANGELOG.md.

Après plusieurs mois d'utilisation interne sur des projets personnels, je publie la première version stable. L'ensemble de fonctionnalités est suffisamment solide pour construire de vrais sites.

Pipeline de contenu#

Le pipeline de contenu est le cœur de notACMS. Il lit le répertoire local/content/, analyse le frontmatter et génère un site statique complet en une seule commande.

• Contenu Markdown avec frontmatter YAML
• Rendu CommonMark avec permaliens sur les titres
• Génération d'extraits à partir du contenu textuel
• Calcul du temps de lecture

Routage multilingue#

Les locales sont définies dans _site.yaml. Chaque locale dispose de son propre espace d'URL, avec des surcharges de chemin optionnelles dans _routes.yaml. Les balises hreflang sont générées automatiquement.

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

Recherche Pagefind#

La recherche en texte intégral est intégrée à la sortie statique via Pagefind. La commande de compilation génère l'index de recherche automatiquement. Pas d'API externe, pas de recherche côté serveur — juste un index statique qui fonctionne hors ligne.

Traitement des images#

Les images colocées avec le contenu sont traitées lors de la compilation. notACMS génère des variantes WebP à plusieurs largeurs, met à jour automatiquement les attributs src avec un srcset responsive et gère la correspondance de chemins entre les répertoires de contenu et de sortie.

Développement local avec DDEV#

L'environnement de développement est entièrement conteneurisé avec DDEV. ddev start vous donne PHP 8.5, Nginx et tous les outils de compilation. ddev build produit la sortie statique. ddev code-check lance PHPStan et PHP CS Fixer.

Changements cassants#

Il s'agit de la première version stable. Si vous utilisiez une version antérieure à la 1.0, vérifiez le schéma de _site.yaml — la clé social est passée d'une liste à un tableau associatif.

Mise à niveau#

git pull
ddev composer install
ddev build

Et ensuite#

La v1.1.0 sera centrée sur le système de design et la documentation. Ce site — construit avec notACMS — deviendra la documentation officielle et la référence de design.

Contexte plus complet sur mon blog personnel : I left WordPress.

Le problème que je rencontrais sans cesse#

Chaque projet PHP sur lequel je travaillais finissait par avoir besoin d'un site web. De la documentation, une page d'accueil, un blog — les classiques. Et chaque fois que je cherchais un outil, j'aboutissais au même constat : un outil qui voulait que je pense comme lui, pas comme un développeur PHP.

Hugo est rapide mais son langage de templates est déroutant. Jekyll nécessite Ruby. WordPress n'est pas adapté au contenu statique. Next.js est puissant mais il transforme un problème de publication Markdown en un problème de bundler JavaScript.

Je me répétais : je connais déjà Symfony. Je connais déjà Twig. J'ai déjà Composer. Pourquoi devrais-je apprendre un nouvel écosystème juste pour publier du texte ?

La décision zéro base de données#

La première chose que j'ai décidée : pas de base de données. Pas « base de données optionnelle » — aucune base de données du tout. Le contenu vit dans des fichiers. Le processus de compilation lit des fichiers. Le résultat est des fichiers.

Cela impose une certaine discipline. La structure du contenu doit être explicite et prévisible. Il n'y a pas de requête de base de données à laquelle se raccrocher quand vous voulez trouver des articles connexes ou générer un sitemap. Tout doit pouvoir être dérivé de l'arborescence de fichiers.

Cette contrainte s'est avérée être la bonne. Elle rend le système facile à comprendre, facile à sauvegarder et trivial pour les outils d'IA à manipuler.

Conçu pour l'IA dès l'origine#

J'ai commencé à y penser sérieusement quand je me suis mis à utiliser les LLM dans mon travail quotidien. Demander à une IA de vous aider à générer du contenu, traduire des pages ou valider des schémas YAML est simple quand le format est du texte brut.

Avec un CMS basé sur une base de données, il faudrait expliquer le schéma, écrire du SQL, gérer les migrations. Avec notACMS, vous remettez à l'IA un répertoire de fichiers Markdown et elle peut lire, générer et modifier le contenu directement — parce que le format est simplement du texte.

Ce n'est pas une fonctionnalité ajoutée après coup. C'est la raison pour laquelle le système est conçu tel qu'il est.

Les fondations Symfony#

J'ai construit notACMS sur Symfony 7 pour la même raison que j'utilise Symfony pour tout le reste : c'est explicite, typé et bien documenté. Le conteneur d'injection de dépendances, les commandes console, Twig — tout cela est du Symfony standard. Il n'y a rien de novateur dans l'infrastructure.

La partie intéressante, c'est le modèle de contenu. Le système de routage lit _routes.yaml et génère des routes Symfony à partir de votre arborescence de contenu. La commande de compilation rend chaque route et écrit du HTML statique. La couche de services est fine et remplaçable.

Et ensuite#

Cette première version est une base fonctionnelle. Ce que je veux construire :

• Intégration de la recherche Pagefind (prévue dans la v1.0.0)
• Un meilleur pipeline d'images avec génération WebP
• Un support multilingue plus complet
• Une véritable page de référence de design (c'est ce que ce site est en train de devenir)

Le dépôt est public. Si vous souhaitez suivre le projet ou contribuer, le lien se trouve dans le pied de page.