Archi perf : ne pas charger le contenu Markdown dans getAll() #35

New Issue

2026-05-08T21:33:24Z

cedricAbonnel commented

2026-05-08 21:33:24 +00:00

Problème

Dans ArticleManager::loadArticle(), le contenu Markdown (index.md) est lu et chargé dans le tableau pour chaque article, même quand seules les métadonnées sont nécessaires (page liste, slug lookup, unicité de slug).

// src/ArticleManager.php — loadArticle(), ligne ~249
$meta['content'] = file_exists($contentPath) ? (string)file_get_contents($contentPath) : '';

Sur un blog avec 50 articles de 5 Ko chacun, getAll() lit 250 Ko de Markdown inutilement à chaque chargement de la page d'accueil.

Solution proposée

Introduire un paramètre $withContent = false dans loadArticle() et getAll() :

private function loadArticle(string $dir, bool $withContent = false): ?array
{
    // ... lecture meta.json ...
    if ($withContent) {
        $meta['content'] = file_exists($contentPath) ? (string)file_get_contents($contentPath) : '';
    }
    return $meta;
}

public function getAll(bool $withContent = false): array { ... }

Seuls getByUuid() et getBySlug() (appelés depuis la vue article ou l'édition) ont besoin du contenu. La liste et les lookups de slug n'en ont pas besoin.

Impact

Appel	Avant	Après
Page liste (N articles)	N lectures `index.md`	0 lectures `index.md`
Vue article	1 lecture `index.md`	1 lecture `index.md` (inchangé)
`uniqueSlug()` via `getAll()`	N lectures `index.md`	0 lectures `index.md`

Critères d'acceptation

getAll() ne lit plus index.md par défaut
getBySlug() et getByUuid() passent withContent: true ou font une lecture ciblée
La page liste ne régresse pas (le contenu n'y était de toute façon pas affiché)
PHPStan passe sans erreur de type

Note

Ce ticket est indépendant du ticket #26 (cache de la liste) mais les deux se complètent : le cache évite les scans répétés entre requêtes, ce ticket réduit le coût de chaque scan.

## Problème Dans `ArticleManager::loadArticle()`, le contenu Markdown (`index.md`) est lu et chargé dans le tableau pour **chaque article**, même quand seules les métadonnées sont nécessaires (page liste, slug lookup, unicité de slug). ```php // src/ArticleManager.php — loadArticle(), ligne ~249 $meta['content'] = file_exists($contentPath) ? (string)file_get_contents($contentPath) : ''; ``` Sur un blog avec 50 articles de 5 Ko chacun, `getAll()` lit 250 Ko de Markdown inutilement à chaque chargement de la page d'accueil. ## Solution proposée Introduire un paramètre `$withContent = false` dans `loadArticle()` et `getAll()` : ```php private function loadArticle(string $dir, bool $withContent = false): ?array { // ... lecture meta.json ... if ($withContent) { $meta['content'] = file_exists($contentPath) ? (string)file_get_contents($contentPath) : ''; } return $meta; } public function getAll(bool $withContent = false): array { ... } ``` Seuls `getByUuid()` et `getBySlug()` (appelés depuis la vue article ou l'édition) ont besoin du contenu. La liste et les lookups de slug n'en ont pas besoin. ## Impact | Appel | Avant | Après | |---|---|---| | Page liste (N articles) | N lectures `index.md` | 0 lectures `index.md` | | Vue article | 1 lecture `index.md` | 1 lecture `index.md` (inchangé) | | `uniqueSlug()` via `getAll()` | N lectures `index.md` | 0 lectures `index.md` | ## Critères d'acceptation - [ ] `getAll()` ne lit plus `index.md` par défaut - [ ] `getBySlug()` et `getByUuid()` passent `withContent: true` ou font une lecture ciblée - [ ] La page liste ne régresse pas (le contenu n'y était de toute façon pas affiché) - [ ] PHPStan passe sans erreur de type ## Note Ce ticket est indépendant du ticket #26 (cache de la liste) mais les deux se complètent : le cache évite les scans répétés entre requêtes, ce ticket réduit le coût de chaque scan.

cedricAbonnel referenced this issue

2026-05-08 21:34:12 +00:00

Archi perf : index slug→uuid pour éviter le scan complet à chaque vue article #36

cedricAbonnel referenced this issue from cedricAbonnel/folio

2026-05-13 22:09:39 +00:00

Archi perf : ne pas charger le contenu Markdown dans getAll() #24

cedricAbonnel closed this issue

2026-05-13 22:09:39 +00:00

cedricAbonnel commented

2026-05-13 22:09:39 +00:00