`** : la colonne de lecture est plafonnée à `max-w-3xl`, où trois vignettes ne disposaient que de 224 px chacune quelle que soit la taille de l'écran. Posée sur `max-w-5xl`, la section rend ~309 px par carte. Le nombre de suggestions suit les colonnes — jamais de rangée orpheline : 2 empilées sous 640 px, 2 sur une rangée à partir de 640 px, 3 à partir de 1024 px. La troisième est masquée **en CSS**, le contrôleur ne connaissant pas la largeur de l'écran ; la faire dépendre d'un en-tête client rendrait la page non cachable pour une vignette. **Trois correctifs joints à ce lot**, trouvés en relisant l'ensemble avant déploiement : - **D-14 corrigé** (`config/backup.php`) — cf. le tableau de la dette ; - **les pages d'aperçu ne sont plus indexables.** En production le layout sert `index,follow` par défaut, et `blog/show.blade.php` ne posait `robots` que si `meta_robots` était renseigné — champ que ce lot vient justement de retirer du back-office. Un lien de relecture signé (7 jours) collé dans un fil public rendait donc un brouillon indexable, canonical auto-référent à l'appui. L'aperçu passe maintenant en `noindex,nofollow`, et un test le vérifie **en forçant l'environnement sur « production »** — hors production le layout désindexe tout, le test serait passé au vert quoi qu'on écrive dans la vue ; - **`MysqlTestCase::column()` ne sélectionnait pas `COLUMN_DEFAULT`.** L'assertion qui vérifiait le défaut `published` de la nouvelle colonne lisait donc une propriété inexistante et tombait en « Undefined property » — la suite MySQL était rouge, et le point le plus important de la migration n'était en réalité pas couvert. Le schéma, lui, était correct : vérifié en base (`varchar(20)`, défaut `published`, index `(locale, status)`). Fichiers créés : `database/migrations/2026_08_07_090000_add_status_to_post_translations.php`, `config/backup.php`, `tests/Feature/BlogLanguageStatusTest.php`. Fichiers modifiés : `app/Models/{Post,PostTranslation}.php`, `app/Filament/Resources/{PostResource,CategoryResource}.php`, `app/Support/BlogContentImages.php` (`duplicate()`), `app/Console/Commands/DatabaseBackup.php`, `lang/{fr,en,es}/{routes,menu,blog}.php`, `resources/views/blog/{_card,show}.blade.php`, `database/factories/PostTranslationFactory.php`, `deploy.sh`, `doc/{guide-back-office,deploiement,blog-schema,env,backups}.md`, `tests/Database/MysqlTestCase.php`, et les suites du blog, du back-office et des sauvegardes. --- --- ## Écarts au plan, assumés **1. Pinning Composer reporté du lot 0.1 au lot 3.1. ✅ résolu au 3.1a.** `config.platform` est comparé au `platform-overrides` du lock : le pinning exige donc un refresh du lock. Or trois versions verrouillées ont disparu de Packagist (`nette/utils 4.1.2`, `laravel-lang/actions 1.12.0`, `laravel-lang/attributes 2.15.2`) et un refresh ciblé déplace une vingtaine de versions, dont `guzzle 7.10 → 7.15` qui porte l'intégration Dolibarr. Faire ce brassage juste avant une bascule de base de production était le mauvais compromis : ce sera un changement unique et cohérent avec le `composer require` de Filament, suivi de la suite de tests complète. **2. `Mail::raw()` remplacé par un mailable dédié `QuotationNotArchived`.** `MailFake::raw()` est un no-op dans Laravel 10 : l'alerte technique n'était pas assertable. Le mailable est délibérément **sans** `ShouldQueue` ni `SerializesModels` et ne reçoit que des données brutes — même garantie à l'exécution (il part alors qu'aucune ligne n'existe en base), mais testable. **3. `publishedLocales()` retourne les langues dans l'ordre de `supported_locales`.** L'ordre des lignes en base n'est pas garanti, et cette sortie alimente les `hreflang`, le sitemap et le sélecteur de langue : il doit être stable. **4. `sitemap:generate` planifiée au 2.5 et non au lot 1. ✅ résolu.** Le plan la plaçait dans `Kernel::schedule()` dès le lot 1. La commande produisait alors des `` **relatives**, donc un sitemap invalide : la planifier aurait publié une erreur tous les jours. Elle a été réécrite au 2.5 (URLs absolues, gabarits écartés, articles ajoutés par langue traduite) puis planifiée à 04:15. **5. Le contrôle d'archive et la rétention vivent dans `App\Support\SqlDumpArchive`, pas dans la commande.** Sans cette séparation, rien n'était testable sans un MySQL joignable — et c'est justement la partie qu'il faut avoir vérifiée avant de dépendre d'une sauvegarde. --- ## Prérequis production — bloquants pour la mise en production À relever sur `gocap-mostiglass-2`. Les commandes correspondantes sont regroupées en tête de `doc/mysql.md`, § « Prérequis » : un seul copier-coller donne les points 1 à 3, 6, 9 et 10. 1. ✅ **Extensions PHP — vérifié le 01/08/2026, CLI et FPM.** PHP **8.2.32**, une seule version installée (`/etc/php/8.2`), **PHP-FPM 8.2** derrière nginx (pas d'Apache). Présents côté CLI : `intl`, `gd`, `imagick`, `exif`, `fileinfo`, `zip`, `pdo_mysql`, `mysqli`, `pdo_sqlite`. Et `intl` est bien chargé par le SAPI web : `/etc/php/8.2/fpm/conf.d/20-intl.ini → mods-available/intl.ini`. **`ext-intl` ne bloque donc plus le lot 3** — l'exigence était réelle, `filament/support` v3.3 déclare `"ext-intl":"*"`. ⚠️ Piège rencontré : `diff <(php -m) <(php-fpm -m)` échoue en tant que `www-data`, le binaire étant dans `/usr/sbin`, hors PATH. Le diff renvoie alors un **faux négatif silencieux** (tout le CLI apparaît comme « supprimé »). Contrôler les liens de `fpm/conf.d/` est plus fiable : c'est le mécanisme réel. 2. 🚨 **MySQL n'est PAS encore installé** (01/08/2026) — installation prévue par l'hébergeur. **À cadrer avant qu'il n'agisse** : sur Debian 12, « MySQL » depuis les dépôts officiels donne **MariaDB** (`default-mysql-server` → `mariadb-server`, il n'existe pas de `mysql-server` officiel). Recommandation : **Oracle MySQL 8**, la suite y est verte à 43/43 contre 36/43 sur MariaDB 11.8. Les écarts mesurés et la marche à suivre si MariaDB est imposé sont dans `doc/mysql.md` § 0. Reste aussi à obtenir l'accès `root` pour créer la base et l'utilisateur. 3. 🚧 **`` = `/var/www/mostiglass`** (confirmé), application possédée par **`www-data`** qui dispose bien d'un shell. Reste `` : `command -v php`. 4. ⬜ La prod est-elle derrière un reverse proxy TLS ? (`TrustProxies` est vide → URLs signées et lien de reset de mot de passe cassés) 5. ⬜ `APP_URL` réel (impacte images, sitemap, URLs signées) 6. 🚨 **`crontab` : command not found** (01/08/2026). À lever d'urgence : ce n'est peut-être pas « la ligne manque » mais « cron n'est pas installé ». Sans planificateur, `db:backup` **et** `sitemap:generate` ne tourneront jamais — donc aucune sauvegarde. À trancher : ```bash ls -l /usr/bin/crontab; systemctl status cron; systemctl list-timers --all | head ``` Deux issues possibles, cf. `doc/backups.md` § Planification : un fichier `/etc/cron.d/mostiglass` (préférable — il nomme explicitement l'utilisateur) ou un timer systemd. 7. ⬜ Destinataire de `MAIL_ALERTS_RECIPIENT` 8. ⬜ Sauvegarde hors-machine de `storage/app/backups` et `storage/app/public` 9. ⬜ Volumétrie SQLite de prod et nombre de `total` non entiers (confirme l'ampleur de D1) 10. ⬜ Outil de dump — **absent** au 01/08/2026 (`mysqldump` et `mysql` : ABSENT), normal puisque MySQL n'est pas installé. Il viendra avec le serveur. Attention : selon le moteur, le binaire s'appelle `mysqldump` **ou** `mariadb-dump` — `db:backup` gère désormais les deux (cf. `doc/backups.md`). Bloquant pour les 3 tests de restauration de `tests/Database/DatabaseBackupRoundTripTest.php`, à jouer sur le serveur. 11. 🚧 **OPcache est actif** (vérifié le 01/08/2026). `./deploy.sh` recharge PHP-FPM — mais `www-data` ne pilote pas systemd : **une règle sudoers reste à poser**, restreinte à `systemctl reload php8.2-fpm`. Cf. `doc/deploiement.md` § 1.c. Sans elle, le premier déploiement s'arrête avant de rouvrir le site (à dessein). 12. ⬜ **Node et npm** — relevé au lot 4.1, jamais listé jusque-là. `public/build/` n'est pas versionné et ne l'a jamais été : sans build sur le serveur, le site est servi sans style ni JavaScript. Version attendue : celle de `.nvmrc` (Node 20). À défaut, construire ailleurs et `rsync public/build/`, puis déployer avec `--skip-assets`. --- ## Dette technique repérée, à arbitrer | # | Sujet | Statut | |---|---|---| | D-1 | `config/logging.php` code `stack` sur `['single']` → `LOG_STACK` ignoré, et le canal `nightwatch` du `.env` n'existe pas | ⬜ à corriger avec le niveau Discord, sinon flood | | D-2 | `config/app.php` : `locale`/`fallback_locale` en dur → `APP_LOCALE`/`APP_FALLBACK_LOCALE` ignorés | ⬜ à documenter (bénéfique pour le panneau FR) | | D-3 | `config/cache.php` lit `CACHE_DRIVER` alors que le `.env` définit `CACHE_STORE` ; `session.encrypt` en dur | ⬜ à documenter | | D-4 | URLs EN cassées : `Lang::uri('legale-notices')` / `('venturi')` vs `lang/en/routes.php` | 🚧 **confirmé et mesuré au 4.3** : `/en/legal-notices` et `/en/venturi-effect-and-application` en 404, pages servies sous slug français. Correctif prêt, **en attente d'arbitrage** — il change deux URLs publiques (+ deux 301) | | D-5 | `@error('lastname')` dans le formulaire de devis alors que les clés sont `user.lastname` → blocs jamais affichés | ⬜ lot UX | | D-6 | Webhook Discord en clair dans `.env`, `chmod 600 .env` en prod | ⬜ rotation recommandée | | D-7 | `vendor/` en avance sur `composer.lock` | ✅ **résorbé au 3.1a** : le refresh du lock a réaligné les deux | | D-8 | `composer audit` : 28 advisories sur 11 paquets | 🚧 **ramené à 10 sur 4** par le refresh du 3.1a, sans intervention ciblée. Le reste à arbitrer | | D-9 | `resources/views/layouts/theme.blade.php` : layout résiduel d'un autre projet | ✅ **supprimé au 2.6** — zéro référence, et il incluait des partials `theme.*` inexistants ; il portait les métadonnées SEO d'une autre agence. Récupérable dans l'historique git. | | D-10 | `build/` à la racine : vestige d'un ancien emplacement de sortie Vite | ✅ **supprimé au 4.1** — aucune référence dans le code, `public/build/` porte les assets réellement servis, vérifié après suppression. Récupérable dans l'historique git. | | D-11 | Les huit stubs `public/int/*.php` redirigent en **302** vers des URLs sans préfixe de langue, qui re-redirigent en 301 ; `contact.php` mélange `www.` et non-`www.` | ⬜ **repéré au 4.3**, non touché : fichiers hérités portant du référencement réel | | D-12 | `RemoveIndexMiddleware` : `strpos($uri, '/int/')` vaut `0` — donc **faux** — pour toute URL commençant par `/int/`. La branche ne se déclenche jamais pour les URLs qu'elle vise | ⬜ **repéré au 4.3**, non corrigé : la « corriger » ferait passer `/int/gocap.php` par l'accueil au lieu de `qui-sommes-nous`, écrasant les stubs plus précis. À traiter avec D-11, pas avant | | D-15 | Les images des blocs de contenu ne sont pas supprimées avec leur bloc : `storage/app/public/blog/content/` accumule des fichiers orphelins | ✅ **résolu au A.6** — suppression automatique dès qu'aucune traduction ne cite plus le fichier (article supprimé, langue retirée, bloc retiré, image remplacée), après commit et jamais hors de `blog/content/`. Commande `blog:prune-images` pour les orphelins d'avant | | D-14 | `app/Console/Commands/DatabaseBackup.php` appelait `env('BACKUP_PATH')`, `env('BACKUP_KEEP_DAYS')` et `env('BACKUP_MYSQLDUMP')` **hors d'un fichier de `config/`**. Avec `config:cache` — que fait `deploy.sh` —, `env()` ne lit plus `.env` et renvoie `null` : les trois variables étaient **silencieusement ignorées en production**, et la rétention retombait sur 14 jours quoi qu'indique le `.env` | ✅ **résolu au A.7** — `config/backup.php`, trois `config()` dans la commande, quatre tests : destination, binaire et rétention lus depuis la configuration (l'angle mort qui avait laissé passer le défaut : seul le chemin « la valeur vient de l'option » était couvert), plus un garde-fou qui refuse le retour d'un `env('BACKUP_*')` hors de `config/`. Documenté dans `doc/env.md` et `doc/backups.md` | | D-13 | `redirect(null, 301)->route(...)` répond **302** : sans destination, `redirect()` jette son second argument et `->route()` repart sur son défaut. Les six redirections héritées s'annoncent permanentes et sont temporaires | ⬜ **mesuré au 4.3**, non corrigé. Correctif d'un argument déplacé, mais il change le statut d'URLs publiques : à arbitrer avec D-4 et D-11, pour ne poser qu'une seule fois les 301 définitifs | ### D-14 — correctif appliqué au lot A.7 Consigné le 04/08/2026 pour être repris à froid, **appliqué le 08/08/2026** tel que décrit ci-dessous : `config/backup.php`, les trois `env()` remplacés par `config()`, le test « la valeur vient de la configuration » qui manquait, le garde-fou contre le retour d'un `env('BACKUP_*')` hors de `config/`, et l'entrée dans `doc/env.md`. Le compte rendu est conservé ici : c'est le raisonnement, pas seulement la retouche. **Où** — trois appels, tous dans `app/Console/Commands/DatabaseBackup.php` : | Ligne | Aujourd'hui | |---|---| | 47 | `$this->option('path') ?: env('BACKUP_PATH') ?: storage_path('app/backups')` | | 179 | `$this->option('binary') ?: env('BACKUP_MYSQLDUMP')` | | 250 | `$this->option('keep-days') ?: env('BACKUP_KEEP_DAYS', 14)` | **Pourquoi c'est un défaut** — `env()` ne lit `.env` que tant que la configuration n'est pas en cache, et `deploy.sh` fait `config:cache`. En production, ces trois appels renvoient donc `null` **sans rien signaler**, et la rétention retombe sur 14 jours quoi qu'indique le `.env`. Vérifié expérimentalement pendant le lot 4. Ce qui le rend particulièrement discret : les options de ligne de commande (`--path`, `--binary`, `--keep-days`) continuent, elles, de fonctionner. Un essai manuel avec une option passe donc parfaitement, pendant que la tâche planifiée de 03:15 ignore le `.env`. **Le correctif** — exactement le patron déjà retenu pour `config/admin.php` au lot A.1. 1. Créer `config/backup.php` : ```php return [ 'path' => env('BACKUP_PATH') ?: storage_path('app/backups'), 'keep_days' => (int) env('BACKUP_KEEP_DAYS', 14), 'mysqldump' => env('BACKUP_MYSQLDUMP'), ]; ``` 2. Remplacer les trois `env(...)` par `config('backup.path')`, `config('backup.mysqldump')` et `config('backup.keep_days')`. Dans un fichier de `config/`, `env()` est légitime : c'est précisément ce que `config:cache` évalue et fige. Ailleurs, non. **À ajouter autour du correctif** - un test qui fixe `config(['backup.keep_days' => 0])` et vérifie que la purge obéit : aujourd'hui, seul le chemin « la valeur vient de l'option » est couvert, jamais « la valeur vient de la configuration » — c'est exactement l'angle mort qui a laissé passer le défaut ; - un garde-fou qui échoue si `BACKUP_*` réapparaît dans un `env()` hors de `config/` ; - une entrée dans `doc/env.md`, section « variables lues autrement qu'on le croit », où l'on ira les chercher. **Effet de bord à connaître** — une fois en configuration, modifier `BACKUP_KEEP_DAYS` dans le `.env` de production n'aura d'effet qu'après un `php artisan config:cache`. `deploy.sh` le fait à chaque déploiement : sans conséquence en pratique, mais à savoir. C'est déjà documenté en tête de `config/admin.php`. Charge estimée : une demi-heure, tests et documentation compris. --- ## Repères pratiques Le détail fichier par fichier n'est plus recopié ici : tout est commité, `git show` et `git log --stat` sont à jour et ne peuvent pas diverger du code. Les commits de fond sont listés en tête de document. **Commandes ajoutées par le chantier** ```bash php artisan db:migrate-legacy-sqlite --dry-run # diagnostic de bascule, n'écrit rien php artisan db:migrate-legacy-sqlite # transfert + vérification php artisan db:migrate-legacy-sqlite --verify # comparaison seule php artisan db:backup # dump gzip + contrôle + purge php artisan sitemap:generate # sitemap.xml (pages + articles) php artisan mostiglass:admin # crée ou promeut un compte back-office php artisan mostiglass:admin --revoke # retire l'accès, conserve le compte php artisan blog:prune-images --dry-run # images de contenu orphelines, n'efface rien php artisan blog:prune-images # les supprime, après confirmation ``` **Déployer** ```bash sudo -u www-data ./deploy.sh --dry-run # déroule les contrôles, n'écrit rien sudo -u www-data ./deploy.sh --ref origin/main ``` **Lancer les tests** (toujours avec `-u sail` : cf. piège n° 2) ```bash docker compose exec -T -u sail laravel.test php artisan test # SQLite en mémoire docker compose exec -T -u sail -e DB_HOST=mysql -e DB_PORT=3306 -e DB_DATABASE=testing \ laravel.test php artisan test -c phpunit.mysql.xml # MySQL, référence docker compose exec -T -u sail -e DB_HOST=mysql -e DB_PORT=3306 -e DB_DATABASE=testing \ laravel.test php artisan test -c phpunit.mysql.xml --testsuite Database ``` **Où trouver quoi** | Sujet | Fichier | |---|---| | **Déploiement**, prérequis serveur, retour arrière | `doc/deploiement.md` | | Bascule SQLite → MySQL, pièges du moteur, suite de tests MySQL | `doc/mysql.md` | | Sauvegardes, planification, **restauration** | `doc/backups.md` | | Variables d'environnement, et celles qui sont lues autrement qu'on le croit | `doc/env.md` | | Intégration Dolibarr et ses deux pièges d'API | `doc/dolibarr.md` | | **Mode d'emploi éditorial** du back-office | `doc/guide-back-office.md` | | Le back-office côté technique | `doc/back-office.md` | | Les tables du blog et leurs contraintes | `doc/blog-schema.md` | --- ## Décisions actées Back-office **Filament v3.3** · traductions en **tables séparées** · médias via **medialibrary v11** · slug FR **`conseils`** (renommé au lot A.7, l'ancien n'a jamais été en ligne) · publication **par langue** (traduction présente **et** langue publiée, cf. A.7) · échec d'écriture → **le devis part quand même** · **suppression du 301 global** sur les 404 · éditeur **RichEditor** natif · assainissement HTML **à l'écriture** · **aucun thème Filament custom** · rôles via **`users.is_admin`**.