Nouvelle version de Zola et petites corrections

README.md

@@ -4,7 +4,7 @@
 
 Site public : <https://lescarnetsdakkadien.netig.net>
 
-Le site est généré avec **Zola 0.23.1** et **Tera 2** à partir de fichiers Markdown. Il est entièrement statique : aucune base de données, aucune interface d’administration et aucune exécution côté serveur ne sont nécessaires.
+Le site est généré avec **Zola 0.23.6** et **Tera 2** à partir de fichiers Markdown. Il est entièrement statique : aucune base de données, aucune interface d’administration et aucun code applicatif côté serveur ne sont nécessaires.
 
 ## Contenu
 
@@ -21,7 +21,7 @@ La page d’accueil présente le dernier article et les trois fiches les plus r
 Pour le développement local :
 
 - Python 3.11 ou ultérieur ;
-- Zola 0.23.1 ;
+- Zola 0.23.6 ;
 - Git, si le dépôt est versionné avec Git.
 
 Pour le déploiement décrit ici :
@@ -83,7 +83,7 @@ Les contenus sont stockés dans `src/content/`. Trois commandes accompagnent leu
 
 - `new-content.py` crée un brouillon complet pour une section donnée ;
 - `update-content.py` actualise son horodatage `updated` ;
-- `check-content.py` vérifie la présence et le type des champs prévus.
+- `check-content.py` vérifie les noms de fichiers ainsi que la présence et le type des champs prévus.
 
 Le module `_schema.py` centralise les modèles utilisés par le générateur et le validateur ; il n’est pas exécuté directement.
 
@@ -93,6 +93,7 @@ Les commandes, conventions et modèles de front matter sont détaillés dans le
 
 ```text
 .
+├── .env.example
 ├── Caddyfile.example
 ├── Dockerfile
 ├── compose.yml
@@ -128,8 +129,20 @@ Les commandes, conventions et modèles de front matter sont détaillés dans le
 L’image est construite en trois étapes :
 
 1. validation des fiches avec Python ;
-2. génération du site avec Zola 0.23.1 ;
-3. copie des seuls fichiers publics dans un serveur HTTP statique.
+2. génération du site avec Zola 0.23.6 ;
+3. copie des seuls fichiers publics dans static-web-server 2.44.0.
+
+Créer la configuration locale à partir de l’exemple :
+
+```sh
+cp .env.example .env
+```
+
+Le seul réglage nécessaire est le port HTTP publié sur l’hôte :
+
+```dotenv
+FRONTEND_PORT=8002
+```
 
 Vérifier puis démarrer le service :
 
@@ -138,12 +151,14 @@ docker compose config
 docker compose up -d --build
 ```
 
-Le conteneur est exposé uniquement sur l’interface locale de l’hôte :
+Par défaut, le conteneur est exposé uniquement sur l’interface locale de l’hôte :
 
 ```text
 http://127.0.0.1:8002
 ```
 
+Le port peut être changé dans `.env`. Si Caddy est utilisé, adapter alors aussi le port de `reverse_proxy` dans `Caddyfile.example` ou dans la configuration de l’hôte.
+
 Pour mettre à jour le déploiement :
 
 ```sh
@@ -163,10 +178,11 @@ Caddy prend en charge le domaine public, HTTPS, les en-têtes de sécurité et l
 
 [`Caddyfile.example`](Caddyfile.example) fournit le bloc correspondant au port publié par `compose.yml`. Il applique :
 
+- la compression `zstd` ou `gzip` selon le client ;
 - `Cache-Control: no-cache` aux documents ;
 - un cache navigateur d’une journée aux feuilles de style, images et polices ;
 - une CSP compatible avec les ressources locales du site ;
-- HSTS, `Referrer-Policy`, `X-Content-Type-Options` et `X-Frame-Options`.
+- HSTS, `Referrer-Policy`, `Permissions-Policy`, `X-Content-Type-Options` et `X-Frame-Options`.
 
 Le fichier peut être importé au niveau principal du Caddyfile de l’hôte ou servir de modèle pour un bloc existant. Sa syntaxe peut être contrôlée avec :