` et des classes de mise en page dans un contenu saisi par l'équipe éditoriale —
donc d'ouvrir l'assainissement, et de laisser la mise en page casser en responsive au
premier copier-coller. Un bloc porte une **intention** (« image à gauche, texte à
droite ») ; le gabarit Blade décide de la traduire en une grille qui s'empile sur mobile.
Un type inconnu est **écarté à l'écriture** (`App\Support\BlogBlocks`), et le rendu
revérifie l'existence du gabarit : une donnée injectée par un autre chemin ne peut pas
faire inclure une vue arbitraire.
Gabarits : `resources/views/blog/blocks/*.blade.php`, distribués par `blog/_blocks`.
### Trois colonnes, parce qu'elles n'ont pas le même besoin d'échappement
| Colonne | Rôle | Échappement |
|---|---|---|
| `content` | source de vérité | JSON ; le texte riche des blocs est assaini |
| `search_text` | LIKE de `Post::scopeSearch()` | texte **décodé** — `l'atelier` ne correspondrait pas à une recherche sur « l'atelier » |
| `body` | rendu des articles hérités ou importés | HTML échappé, rendu en `{!! !!}` |
Réutiliser `body` comme texte de recherche a été essayé puis abandonné : une colonne ne
peut pas être à la fois du HTML sûr à rendre et du texte décodé à chercher. Les séparer
garantit en prime qu'un texte de recherche ne sera jamais rendu par erreur. L'écriture des
blocs ne touche donc **jamais** `body`.
Deux pièges de l'aplatissement, tous deux trouvés en relisant la sortie réelle et
désormais couverts par des tests :
- `strip_tags()` **colle** les blocs : `
Intertitre
Du texte` devenait
« IntertitreDu texte », et chercher « intertitre » ne remontait rien. Les balises sont
remplacées par une espace, pas supprimées ;
- les **entités survivent** à l'assainissement. Elles sont décodées avant stockage.
### `body` est assaini à l'écriture, pas à l'affichage
`PostTranslation::setBodyAttribute()` passe systématiquement par `App\Support\BlogHtml`.
Le HTML stocké est donc sûr par construction, quel que soit le chemin qui l'a produit
(back-office, import, tinker). Assainir à l'affichage aurait laissé du HTML hostile en
base, prêt à ressortir par le premier chemin qui oublierait de filtrer — flux RSS, export,
aperçu, API.
Conséquence assumée : **ce qui est retiré est perdu.** Le compromis est le bon pour un
back-office interne dont l'éditeur ne produit qu'un sous-ensemble restreint de balises.
Deux détails que seule l'écriture des tests a révélés :
- le sanitizer Symfony **tronque à 20 000 caractères sans erreur** ; `BlogHtml::MAX_LENGTH`
relève la limite à 500 000 ;
- `blockElement()` conserve le texte de la balise retirée — un ``
ressortait en « alert(1) » affiché en clair. C'est `dropElement()` qu'il faut.
---
## `categories` / `category_translations`
Les catégories sont **facultatives** : un article sans catégorie est publié normalement.
`position` (entier, indexé) donne l'ordre du filtre sur le listing ; il est réordonnable
à la souris dans le back-office. Le tri ne dépend donc pas d'un nom traduit, qui
changerait d'ordre selon la langue.
`category_translations` porte `name`, `slug`, `description` et deux champs SEO. Le `slug`
est ce qui apparaît dans `/{locale}/conseils?category=`, résolu **dans la langue
courante** : un slug d'une autre langue rend 404, pas la liste complète (un « soft 404 »
serait indexé puis pénalisé).
---
## Médias
Deux collections à fichier unique sur `Post`, via medialibrary :
| Collection | Usage |
|---|---|
| `cover` | illustration éditoriale : listing et article |
| `og` | image de partage, facultative — vide, `cover` est utilisée |
Deux collections et non une : un visuel cadré en 16/9 se fait couper la tête sur les
1200 × 630 qu'attendent Facebook et LinkedIn.
Conversions WebP, **toutes en `nonQueued()`** : `thumb` 400×250, `card` 800×500,
`hero` 1600×900, `og` 1200×630. Il n'y a pas de worker sur ce serveur
(`QUEUE_CONNECTION=sync`) : une conversion mise en file ne serait jamais exécutée et
l'article s'afficherait sans image, sans la moindre erreur. Le prix est de quelques
secondes à l'enregistrement.
Les fichiers vivent sur le disque `public` (`storage/app/public`), servis par le lien
symbolique `public/storage`.
---
## Ce que le schéma garantit, et qui est testé
`tests/Database/BlogConstraintTest` (suite MySQL) le vérifie sur un vrai moteur, parce
que SQLite est trop permissif pour prouver quoi que ce soit ici :
| Garantie | |
|---|---|
| `unique(locale, slug)` et `unique(post_id, locale)` réellement appliquées | ✅ |
| suppression d'un article ⇒ ses traductions partent en cascade | ✅ |
| suppression d'une catégorie ⇒ `category_id` passe à `null`, l'article survit | ✅ |
| référence orpheline (`category_id` inexistant) refusée | ✅ |
| `published_at` relu sans décalage de fuseau | ✅ |
`tests/Database/MysqlSchemaTest` vérifie en plus les types réels côté MySQL : `body` en
`longtext`, slugs en `varchar(191)`, tables en InnoDB/utf8mb4, index présents.
---
## Requêtes utiles
```php
// Articles en ligne et traduits dans la langue courante
Post::publishedIn()->with('translations')->latest('published_at')->get();
// Langues réellement accessibles d'un article, dans un ordre stable
$post->publishedLocales(); // ['fr', 'en'] — ordre de supported_locales
// Traduction d'une langue, sans repli
$post->translationFor('es'); // null si non traduit
```
```sql
-- Articles publiés mais sans date : invisibles, et rien ne le signale côté base
SELECT id FROM posts WHERE status = 'published' AND published_at IS NULL;
-- Articles incomplets (moins de 3 langues) — le filtre « traduction manquante »
SELECT p.id, count(t.id) AS langues
FROM posts p LEFT JOIN post_translations t ON t.post_id = p.id
GROUP BY p.id HAVING langues < 3;
```
---
## Voir aussi
- `doc/back-office.md` — comment ces tables sont éditées
- `doc/mysql.md` — bascule et pièges du moteur