L’URL Rewriting pour XOOPS (partie 1)
Cela fait maintenant quelque temps que j’utilise le système de gestion de contenu (CMS pour les intimes) XOOPS. C’est lui que j’ai préféré à d’autres (Joomla, SPIP, Drupal…) pour la simple et bonne raison que c’est celui que j’ai découvert en premier, que son mode de fonctionnement me convient, et qu’il y a une grosse communauté derrière (voir la communauté française). Comme tous les CMS, ses fonctionnalités peuvent être étendues par l’ajout de modules, et de ce côté-là, XOOPS n’en manque pas. Mais je ne vais pas m’attarder plus longtemps sur la présentation de XOOPS, de nombreux sites font déjà cela très bien…
Ce que je reproche à XOOPS, c’est qu’il ne gère pas l’URL Rewriting nativement. Qu’est-ce que l’URL Rewriting ? C’est une astuce utilisable sur un serveur Apache et qui permet de réécrire une URL. C’est ce qui se passe avec WordPress : l’adresse du post sur Silverlight (/2007/09/06/silverlight-1/) fait en fait référence à /index.php?p=132. Grâce à un fichier à la racine du site, le serveur est en mesure de faire une redirection correcte (sans donner une erreur 500).
Quel est l’intérêt d’un tel système ? C’est tout simple, les moteurs de recherche comme Google indexent bien mieux les sites qui ont de belles adresses que les autres. Ainsi, un tel site peut être très présent sur les moteurs de recherche, et ce, sans aucun travail de référencement. Il faut juste bien choisir les mots-clés qui apparaissent dans l’URL. Le second avantage, c’est qu’en réécrivant bien les URL, il est possible de cacher l’architecture du site. Néanmoins, les personnes un peu curieuses pourront la deviner.
Sous XOOPS, le problème, c’est qu’aucun module à ma connaissance, mis à par SmartSection, ne permet de générer d’adresse idéale. Il reste alors deux solutions : modifier manuellement le module afin qu’il génère une adresse esthétique ou utiliser une fonction qui va réécrire toutes les URL à la volée. La première solution serait parfaite, s’il ne fallait pas répéter l’opération à chaque mise à jour du module. Par manque de temps ou de volonté, certaines mises à jour comblant une faille critique peuvent être ignorées. La seconde solution, si elle s’avère plus simple à mettre en œuvre, a tout de même un impact sur les performances. Ajoutez ensuite le fait que le serveur doit vérifier la présence d’un fichier de mapping (”.htaccess” en l’occurrence) pour chaque requête, et tout cela peut finir par se ressentir.
Pour des soucis de mise en place rapide et facile du système, j’ai opté pour la seconde solution, même si je n’exclue pas d’étudier la première dès que j’aurai plus de temps. Dans un prochain billet, j’expliquerai comment j’ai procédé.
Je parle aussi de :
Ce billet vous a plu ? Votez sur 
Laisser un commentaire