Jour 3 - Créer un repository lisible et gérer les slugs proprement

Un bon repository évite de mettre des requêtes partout dans les controllers.

Un slug fiable protège ton SEO et empêche les liens cassés quand le contenu évolue.

Objectif d’apprentissage

Séparer proprement la logique de récupération de contenu, et garantir des URLs stables avec des slugs uniques.

Ce que tu vas pratiquer aujourd’hui

• Créer des méthodes métier explicites dans le repository.
• Trier par date de publication de manière stable.
• Gérer les collisions de slug proprement.
• Préparer le terrain pour la pagination des prochains jours.

1. Écrire une méthode findPublished() claire

Ta méthode doit retourner uniquement les articles publiés, triés du plus récent au plus ancien.

Ne mélange pas cette règle dans le controller.

public function findPublished(int $limit = 10): array
{
    return $this->createQueryBuilder('post')
        ->andWhere('post.status = :status')
        ->setParameter('status', BlogPost::STATUS_PUBLISHED)
        ->orderBy('post.publishedAt', 'DESC')
        ->addOrderBy('post.id', 'DESC')
        ->setMaxResults($limit)
        ->getQuery()
        ->getResult();
}

2. Générer un slug depuis le titre

La classe SluggerInterface donne une base fiable pour transformer un titre en URL lisible.

On applique la règle au moment de la création et lors des updates éditoriaux.

$slug = (string) $slugger->slug($title)->lower();

if ($this->blogPostRepository->findOneBy(['slug' => $slug])) {
    $slug = sprintf('%s-%s', $slug, date('His'));
}

$post->setSlug($slug);

3. Tester la stabilité des URLs

Crée deux articles avec un titre identique pour vérifier la stratégie de collision.

Ce test manuel évite des surprises après publication.

php bin/console doctrine:query:sql "SELECT slug, title FROM blog_post ORDER BY id DESC LIMIT 10"

Checklist de fin de session

• Repository métier en place.
• Tri par date cohérent.
• Slug généré automatiquement.
• Collision de slug gérée sans erreur SQL.

Erreurs fréquentes à éviter

• Sauter la vérification finale parce que “ça marche chez moi”.
• Mélanger trop de logique dans le controller au lieu de garder un flux clair.
• Oublier la cohérence entre la donnée, le template Twig et le comportement en production.

Pourquoi cette étape compte en conditions réelles

Dans un vrai projet client, chaque étape technique doit rester compréhensible par l’équipe, duplicable sur un autre environnement et fiable dans le temps. Ici, l’objectif est de transformer la théorie en un flux de travail concret, avec des décisions simples que tu peux défendre en revue de code.

Si tu appliques sérieusement les points du jour (créer des méthodes métier explicites dans le repository.), tu réduis la dette technique dès le départ et tu facilites la suite: SEO, publication, maintenance et déploiement. C’est exactement la différence entre un blog “démo” et un blog exploitable en production.

Mini plan de révision

• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Créer des méthodes métier explicites dans le repository.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Trier par date de publication de manière stable.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Gérer les collisions de slug proprement.

Exercice rapide

Ajoute une méthode findPublishedBySlug() qui ignore les brouillons.

Et demain ?

Demain, on branchera les routes et controllers pour afficher la liste et le détail des articles.