How to make SEO friendly urls
Il y a bien sûr plusieurs façon de faire cela, et je n'ai pas la prétention de dire que celle présentée ici est la meilleure est unique solution, mais c'est celle que j'aime utiliser dans mes projets personnels car elle est facile à utiliser, robuste, et dynamique.
Cette méthode mets en scène un fichier .htaccess qui va réécrire les urls, une fonction php qui va réarranger les paramètres, et un manageur de contenu qui affichera le contenu approprié en fonction de ces derniers.
Avant de commencer, je voudrais remercier Josh Moont pour l'aide apportée.
Démonstration
Implémentation
Étape 1: Le fichier .htaccess
Comme annoncé dans l'introduction, le premier élément rencontré dans le processus de réécriture est le fichier .htaccess. Si vous n'en avez pas déjà un à la racine de votre site, il suffit d'y créer un fichier sans nom dont l'extension est .htaccess.
Ouvrez ce fichier et copiez y le code suivant.
RewriteEngine On ## ERRORDOCUMENTS ### ErrorDocument 206 /Error/206 ErrorDocument 301 /Error/301 ErrorDocument 400 /Error/400 ErrorDocument 401 /Error/401 ErrorDocument 403 /Error/403 ErrorDocument 404 /Error/404 ErrorDocument 500 /Error/500 ErrorDocument 503 /Error/503 ## Page rewrite ## RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?path=$1 [NC,QSA]
Ok mais qu'est ce que ce code veut dire exactement? Très simple. Ligne 1, on spécifie qu'on veut utiliser une fonctionnalité Apache appelée Mod_Rewrite. C'est cette fonction qui permet d'utiliser la réécriture d'url. Elle n'est pas activée par défaut, voila pourquoi nous l'activons ici.
Les lignes 3 à 12 sont en fait un peu éloignée du sujet étant donné qu'elles ne servent pas à réécrire les urls mais à remplacer les pages d'erreurs http (comme 404) par une page d'erreur personnalisée. Je les ai donc laissée même si elles sont utiles pour une autre raison.
Ensuite, lignes 16 et 17, nous avons 2 expressions qui spécifient que les urls qui ciblent des fichiers existants sur le serveur, comme les images, les fichiers JavaScript, ou les feuilles de style, NE SERONT PAS réécrites. Du coup, nous allons uniquement redirigé les pages car c'est bien plus efficace ainsi comme vous pourrez le constater par la suite.
Finalement, la dernière ligne du .htaccess, spécifie que chaque url, qui ciblera donc une page, sera envoyé au fichier index.php pour analyse sous le nom "path". NC veut dire que ce n'est pas sensible à la casse, et QSA que les paramètres $_GET seront conservés et donc disponibles. Du coup, dans les urls futures, il sera possible d'utiliser des slashs, mais aussi les paramètres $_GET (ce qui n'est pas vraiment le but mais cela marche quand même...).
Voila donc pour ce qui est du fichier .htaccess. En résumé, il ne s'occupe pas des fichiers, que des urls qu'il redirige vers le fichier index.php sous le nom "path".
Étape 2: Les paramètres
Les urls sont à partir de ce point redirigées vers le fichier index.php, mais dans un format qui n'est pas compréhensible par défaut par les fichiers php. Voici pourquoi l'étape 2 du processus consiste à réorganiser les paramètres dans un format qui sera utilisable par la suite.
Pour cela, nous utiliseront la fonction get_url_params ci après:
public function get_url_params(){ //Get the query string made of slashes //Extract the asked page from those parameters case 0: $params['page'] = "home"; break; case 1: break; //odd break; default: //even break; } //Process the parameters by pairs $cpt=1;$param=""; switch($cpt){ }}} //Process the $_GET parameters if any }} return $params; }
Encore une fois, je rappelle que chacun est libre d'utiliser le code qu'il veut, ceci est seulement la façon que je trouve personnellement la plus pratique. Explication:
Premièrement, on récupère le "path" envoyé depuis le .htaccess et nous l'analysons, c'est à dire qu'on le découpe suivant les slashs, et on compte combien de paramètre différents cela donne. (ligne 4).
Voici le principe (il n'y a que 4 possibilités).
- Si ce "path" est vide, nous afficheront la page d'accueil (lignes 8-10).
- Si l'on ne trouve qu'un seul paramètre, ce sera la page à afficher. (lignes 11-13).
- Si nous avons un nombre impair de paramètres, le premier sera la page à afficher, et ensuite nous regrouperont les autres par paires {clé=>valeur} (lignes 14-17).
- Et finalement, si l'on a un nombre pair d'attributs, le premier sera la page à afficher, le second la catégorie, et ensuite on regroupe le reste par paires {clé=>valeur} (lignes 18-22).
Ce regroupement par paire se fait lignes 25 à 31.
Comme nous l'avons dis dans l'introduction, cette méthode est robuste car elle prends aussi en compte les paramètres $_GET. Du coup, s'il se trouve que certains ont été spécifié dans l'url, on les regroupe par paire lignes 33 à 36 de telle façon qu'on puisse les utiliser plus tard.
Par exemple, l'url /resource/param1/value1/param2=value2, mixant des slashs et des paramètres $_GET retournera $params=array("page"=>"resource","param1"=>"value1","param2"=>"value2")
Pour résumer, premièrement on découpe et analyse le "path" envoyé par le .htaccess. On y trouve la page à afficher, et on regroupe les autres paramètres par paires {clé=>valeur}. Les paramètres sont à partir de ce point prêt à être utilisé par un fichier.
Étape 3: Le Manageur de contenu
Maintenant que les paramètres ont été réordonné, l'étape suivante consiste à afficher la page demandée par l'url. Pour cela, j'utilise un manageur de contenu, dont la structure simplifiée est présentée ici:
require_once("Chemin_vers/Globals.php"); $params = Globals::get_url_params(); $module=$params['page']; { switch($module) { case "home": $page="Chemin_vers/home.php"; break; case "resources": $page="Chemin_vers/resources.php"; break; case "Error": $page="Chemin_vers/error.php"; break; . . . default: $page="Chemin_vers/home.php"; break; } } else { $page="Chemin_vers/home.php"; } require_once("Chemin_vers/header.php"); require_once($page); require_once("Chemin_vers/footer.php");
La fonction get_url_params() a été placé dans une classe appelée Globals, c'est pourquoi ce fichier a été inclus ligne 2. Il est donc maintenant possible de récupérer les paramètres voulu grâce à la fonction (ligne 3) et plus particulièrement la page désirée (ligne 4).
Nous avons ensuite un bloc switch/case dont la fonction est de trouver le fichier à inclure suivant le nom de la page donnée. C'est cette partie qui permet vraiment de faire la correspondance entre les noms de page et leur fichier.
Quand vous voulez ajouter une page à votre site, il suffit donc d'ajouter un bloc case dans le switch pour ajouter une correspondance.
Lignes, 34,35 et 36, on peut voir que le manageur va finalement inclure les différents fichiers pour afficher la page à l'utilisateur. J'aime utiliser des fichiers séparés header et footer contenant le code commun à toutes les pages, c'est plus facile à maintenir.
Et voila, 3 étapes simples à mettre en oeuvre pour réaliser votre propre système d'url. Donc plus d'excuses pour ces urls interminables et dénuées de sens!
















