Modifier un slug sous Symfony ? Oui .. mais proprement

Cette semaine l’article concerne les développeurs, bah oui … il en faut pour tout le monde.
Ça va vous ? Lundi de Pentecôte tout ça tout ça … oui bon c’est pas une raison allez ! on bosse.

C’est quoi un slug ?

Pour les mecs au fond, on va rappeler ce qu’est un slug, c’est une "string" normalisée de sorte qu’elle puisse être insérée dans une URL, par exemple sur l’article que vous êtes entrain de lire dans votre barre d’adresse il n’y a pas de “index.php?article=49” parce que bah .... c’est moche (si c’est moche, c’est tout.), une belle URL qui permet juste en la regardant de savoir de quoi on parle … c’est mieux ! Jetez un oeil à la barre d’adresse sur cette page, juste en la lisant, vous savez que vous êtes sur un blog, et que vous allez lire un article qui parle de slug et symfo … voilà, là on est bien !

Le problème des slugs

Sur ce blog, le slug est généré à partir du titre de l’article, du coup si je change le titre de mon article, je crée un lien mort, lien qui a déjà été partagé...  du coup les personnes cliquant sur le lien auront un joli “404, page introuvable” (oui, ma page de 404 est jolie, mais ce n’est pas une raison …)
Personnellement; je n’ai pas le problème car je sais comment ça marche et j’évite de changer mes titres et si j’ai besoin de le faire je fais un “301 redirect” dans la config de mon serveur web (NGINX, pour les petits curieux).
Mais j’ai eu plusieurs fois le problème pour des projets clients, ils ont fait une erreur dans le titre du coup il faut le changer et modifier la config du serveur web a chaque fois est une mauvaise idée et c’est interdit de faire des liens morts alors on fait quoi ???

Stocker les anciens slugs dans un tableau

C’est la solution que j’ai choisie, j’aurais pu le faire avec une table à part et faire une relation, mais je n’aime pas cette idée, pourquoi me direz-vous ? Parce que ça fait plein de tables en plus (il n’y a pas que les articles de blog qui utilisent un slug).

Les prérequis pour notre affaire sont :
• Un serveur MariaDB 10.3 au minimum (les versions antérieures ne prennent pas en charge les tableaux JSON)

• L’extension “scienta/doctrine-json-function” pour Doctrine afin de pouvoir faire une requête DQL qui va chercher (composer install tout ça tout ça)

Modification de l’entité 

Vous avez tous les prérequis ? Eh bien … c”est parti alors ! (et si vous ne les avez pas … bah vous attendez quoi ? 😁)
On va déjà modifier notre entité qui contient notre slug en lui ajoutant un attribut, moi je l’appel oldSlug) et en en ajoutant un slug à notre tableau a chaque changement de titre (c’est dans mon cas là-dessus qu’est basé mon slug)

Très simple n’est-ce pas ? ici nous avons donc un tableau qui contiendra tous les anciens slugs

Requête DQL allant chercher un article basé sur un de ses anciens slugs

Maintenant on va ajouter une méthode à notre repository.

Modification du controller

Maintenant il faut faire une redirection 301, si on ne trouve pas notre article de base et qu’on le trouve via un old slug, nous ne pouvons pas directement renvoyer la page pour deux raisons : 

• Contenu dupliqué et c’est très très mal (les fans de SEO me comprendront)
• La requête que nous avons ajoutée dans le repository ne prend pas en compte d’autres paramètres (article activé ? Date de publication ? …)

Conclusion

Et voilà, vous pouvez modifier vos slugs sans casser les liens cela s’avère bien pratique dans certains cas pour garder une arborescence bien propre.
Je vous dis à la semaine prochaine 😊