• Nous, lecteurs humains, avons du mal à lire ces adresses.
• Elles présentent peu d'informations qui nous intéressent : par exemple, il manque presque systématiquement les mots clefs qui pourraient indiquer le sujet traité par la page liée.
• Les paramètres peuvent être combinés à volonté et comporter autant de valeurs que l'on peut imaginer : les moteurs de recherche n'aiment pas trop s'amuser à enregistrer toutes les possibilités. Les discussions vont bon train quant à la limite (car il y a une limite) du nombre de paramètres que Google référence : trois, six, etc.
• De même, il est possible d'intervertir l'ordre des paramètres pour donner une liste presque infinie d'adresses qui sont par ailleurs totalement identiques (si l'on demande plusieurs pages au serveur et que l'on change uniquement l'ordre des paramètres -pas leur valeur-, toutes les pages envoyées en réponse seront 100% identiques).

Le gros de la question est lié au référencement et aux moteurs de recherche : ils ont tendance à laisser de côté les liens qui comportent trop de paramètres (plus de deux, par exemple). Par conséquent, ils ne référencent pas la totalité du site. De même, le manque de mots clefs est un manque à gagner considérable...

La forme des liens pose donc un problème.
La solution est simple : il faut modifier cette apparence. Cependant, techniquement, nous sommes contraints à l'utiliser.

http://g-rossolini.developpez.com/tutoriels/seo/url-rewriting/?page=2

Le principe est d'ajouter un paramètre, par exemple nommé "keywords", qui permet d'ajouter une chaîne de caractères servant de mots clefs. Le script ignore ce paramètre puisqu'il est inutile, mais le fait qu'il apparaisse permet aux bots d'analyser les mots clefs de la nouvelle URI.
Tant que l'on a un minimum de contrôle sur son serveur Web, il est préférable de porter son choix sur la solution suivante. Le paramètre inutile ne doit être qu'un dernier recours et utilisé avec précaution, dans la mesure où les moteurs de recherche pourraient l'interpréter comme une tentative de les tromper.

http://g-rossolini.developpez.com/tutoriels/seo/url-rewriting/?page=2&keywords=theorie-de-l-url-rewriting

C'est ici qu'entre en jeu la réécriture de liens (alias URL Rewriting), un procédé dynamique servant de compromis.
En effet, cette technique modifie l'apparence des liens pour l'utilisateur (vous et moi) sans pour autant modifier la structure du site du côté du serveur Web.

• Imaginons qu'un sujet de notre forum soit accessible par l'URL sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm
• En réalité, le lien que phpBB reçoit et analyse est : viewtopic.php?t=3678

Plus techniquement, il s'agit d'intervenir avant d'envoyer la page demandée par le client, c'est-à-dire un peu avant la fin de l'exécution du fichier de pied de page. Nous envoyons au navigateur les URLs (les liens) sous une certaine forme modifiée puis, lorsque le client clique sur ces liens, nous intervenons à nouveau avant PHP. Ainsi, nous traduisons l'adresse que le client a demandée dans un format que le serveur Web et PHP pourront interpréter.

http://g-rossolini.developpez.com/tutoriels/seo/url-rewriting/page-2-theorie-de-l-url-rewriting.html

1. Le navigateur demande la page viewtopic.php?t=3678
2. Le serveur Web ne sait pas traiter la page, il l'envoie donc à PHP
3. PHP traite le script et renvoie le résultat au serveur Web
4. Le serveur Web transmet ce résultat au navigateur

Il est clair ici que le serveur Web se contente de transmettre les requêtes de pages à PHP et les réponses au navigateur. Quel fainéant...

1. Le navigateur demande la page sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm
2. Le serveur Web se rend compte qu'il doit effectuer une opération : il remplace l'adresse demandée par une autre afin que PHP puisse s'en occuper correctement ==> viewtopic.php?t=3678
3. PHP traite le script et renvoie le résultat au serveur Web
4. Le serveur Web transmet ce résultat au navigateur

L'URL Rewriting intercale un niveau (d'abstraction) avant PHP.
Il est clair que le serveur Web intervient davantage dans la transaction, il ne se contente plus de simplement servir de courtier.
Concrètement, l'URL Rewriting permet d'avoir des liens en français quelle que soit la technologie du site que nous utilisons (DotClear, phpBB, fait maison, etc.) et sans toucher à sa structure.
Lorsque nous cliquons sur un lien, un dispositif que nous avons mis en place du côté du serveur modifie le lien sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm (qui fait référence à un fichier fictif) en viewtopic.php?t=3678 (qui fait référence à un fichier bien réel) avant que PHP commence à traiter la demande.

Je viens de mettre en évidence les deux étapes nécessaires pour mettre en place la réécriture de liens : d'une part, modifier les pages en sortie du serveur Web vers le client (elles ne doivent plus être de la forme viewtopic.php?t=3678 mais sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm) et, d'autre part, modifier les demandes du client au serveur Web (c'est la procédure inverse).
Dès lors, une question fondamentale surgit : quelle forme doivent avoir mes nouveaux liens ?
Si nous n'avons pas la réponse, nous n'irons pas bien loin... Il est temps de se creuser la tête pour trouver les solutions les plus adéquates !

Il s'agit ici de trouver un moyen d'intercepter les requêtes du client avant qu'elles parviennent à PHP. Ce moyen s'appelle ".htaccess" si l'on a un serveur Apache ou bien "HTTPHandlerFactory" si l'on utilise le moteur ASP .NET. Je me concentrerai ici sur la solution d'Apache.
Il s'agit d'un fichier nommé ".htaccess", un simple fichier texte qui va donner des ordres à Apache. Parmi ces ordres, plus communément appelés "directives", figureront les changements à effectuer.

Voici ce que doit contenir le fichier .htaccess pour nos besoins :

RewriteEngine on
RewriteRule ^profil-([0-9]+).* /phpBB2/profile.php?mode=viewprofile&u=$1 [L]
RewriteRule ^editer-profil.* /phpBB2/profile.php?mode=editprofile [L]
RewriteRule ^sujet-([0-9]+).* /phpBB2/viewtopic.php?t=$1 [L]
etc.

L'option L en fin de ligne indique à Apache qu'il peut s'arrêter de comparer dès qu'il trouve le résultat. Pour plus de détails, consulter le fichier complet inclus dans l'archive à télécharger.
La directive RewriteEngine est fondamentale car elle active le moteur de réécriture. Les directives suivantes, RewriteRule, sont généralement très nombreuses.
Le principe des directives RewriteRule est d'utiliser les expressions régulières. Je n'ai pas l'intention de rentrer dans les détails sur les regexp ici car le chapitre est trop long et car ce n'est pas l'objet de mon article.

• [0-9]+ fait référence à un ou plusieurs chiffres à la suite
• [a-z]+ fait référence à une ou plusieurs lettres à la suite
• [a-z0-9]+ fait référence à un ou plusieurs caractères (lettres et chiffres confondus)
• .* fait référence à n'importe quelle suite de caractères (quantité nulle jusqu'à l'infini)
• Les "lettres" font référence à l'alphabet anglais (aucun accent)
• Les parenthèses permettent de "capturer" ce qui se trouve à l'intérieur afin de le rappeler dans la suite de la directive : le contenu du premier couple de parenthèses sera appelé par $1, le second par $2 etc.
• Lorsque plusieurs règles gèrent des chaînes similaires, il faut toujours mettre de la règle la plus précise à la plus générale. Exemple :

RewriteRule ^chercher-([a-z]+).* /phpBB2/search.php?mode=$1 [L]
RewriteRule ^chercher.* /phpBB2/search.php [L]

Une fois ce fichier placé à la racine du forum, il s'occupera de traduire les adresses que nous lui enverrons plus tard en adresses classiques de phpBB.
Si une adresse réécrite (donc fictive) ne figure pas dans la liste des règles du fichier .htaccess, alors elle ne sera pas traduite, résultant en une erreur 404 ("page non trouvée").

Cette étape est terminée : passons maintenant à la suivante.

Ici, c'est déjà plus fun.
En fait, c'est simple à imaginer. La complexité vient de la grande quantité de tests à faire...

Il y a deux manières de modifier les liens : dynamiquement et statiquement.

• Statiquement
  Les premières versions de l'URL Rewriting que j'ai mises en place sur le Forum Cinéma sont de la méthode statique, celle que je trouve trop peu pratique à mettre en place pour être viable... Il m'a fallu un moment pour intégrer tous les concepts et pour me motiver à refaire tout ça à ma sauce !
  La méthode statique est la plus facile et la plus longue, voire la plus frustrante à mettre en place. C'est aussi la moins informatisée et, par conséquent, la plus complexe à maintenir. Il s'agit de parcourir le code source du site complet et de modifier chaque lien à la main. C'est fastidieux et on en oublie toujours :/
  En plus, c'est aussi long à chaque fois que l'on effectue l'installation du Mod...
  L'inconvénient principal est que les mises à jour sont une vieille galère ! On oublie toujours un ancien lien quelque part, ou bien une mise à jour nous restaure un lien à l'ancienne...
  
  
• Dynamiquement (que nous allons utiliser)
  Cette méthode est largement plus simple à mettre en place mais également largement plus complexe à concevoir : pas de souci, je m'en suis chargé pour vous.
  Il faut penser à tous les cas de figure, chose qu'il aurait fallu faire avec la méthode statique de toute manière : ils peuvent varier d'un forum phpBB à l'autre, suivant les Mods installés et/ou l'humeur de l'administrateur.
  L'idée est de laisser phpBB produire l'intégralité de son code HTML, puis d'intervenir en remplaçant d'un seul coup la totalité des liens de la page.
  
  Pour y parvenir, nous allons utiliser la mise en tampon du code HTML (utilisation d'un "buffer"). En effet, PHP met à disposition quelques fonctions qui permettent de manipuler le contenu destiné au navigateur, avant de l'envoyer au navigateur. C'est exactement comme si nous mettions dans une variable tout le HTML produit par PHP : rien n'est envoyé au navigateur tant que nous ne faisons pas echo de cette variable.
  
  Je le répète : je ne compte pas expliquer ici en détail la procédure de développement, simplement donner des points de repère.
  L'idée générale est d'appliquer une recherche à base d'expression régulière à la totalité du code HTML qui est sur le point d'être envoyé au client : cela nous permet de récupérer les liens, de les modifier et enfin d'envoyer au client le code HTML modifié.
  

Voici l'expression régulière que j'utilise :

#<a(.+)href="([^"]+)"([^>]*)>(.*)</a>#Usi

1. d'éventuelles options comme class="..." et style:"..."
2. l'adresse complète de la cible du lien
3. d'autres éventuelles options comme class="..." et style:"..."
4. le texte, l'ancre du lien (ce que l'on voit affiché dans la page Web)

Ici, les # sont les délimiteurs de l'expression régulière.
Seul le deuxième couple de parenthèses est vraiment important. Les trois autres sont là uniquement pour conserver des paramètres existants, rien de vraiment fondamental. En fait, pour extraire d'autres types de liens à l'aide de mon script final, il y a principalement besoin du 2° couple de parenthèses (logiquement, le 1° est également nécessaire afin de conserver l'ordre).

• U demande à PHP de trouver autant de résultats que possible (sans quoi le .+ au centre de l'expression pourrait inclure des balises HTML, ce qui nous donnerait une page finale avec un contenu complètement ésotérique - obliger PHP à ne pas être "avare" à l'aide du modificateur Ungreedy permet d'éviter ces éventuels désagréments).
• s demande au point d'inclure les sauts de ligne.
• i force l'expression à ne pas tenir compte de la casse (minuscules et majuscules).

Voilà, nous avons notre expression régulière qui nous permettra d'obtenir un joli tableau PHP des liens à modifier.
Il reste le gros du travail, à savoir énumérer tous les cas possibles de combinaisons de paramètres dans l'URL...

J'ai dit plus haut que cela pouvait aller à l'infini. C'est partiellement vrai : dans le cas de phpBB (comme de la quasi totalité des sites), il y a une limite au nombre de paramètres combinés à chaque page. En outre, nous ne nous occuperons pas toujours du contenu de ces paramètres, ce qui réduit encore la charge de travail.
Il reste néanmoins une belle quantité de situations à déterminer !
Le travail ici est similaire à ce qui a été fait pour le fichier .htaccess, seulement à l'envers : il faut constuire la chaîne sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm à partir de viewtopic.php?t=3678. On peut également imaginer d'ajouter des informations comme le nom de l'auteur du message, la date... Puisque le nom final sera considéré comme un nom de fichier tout ce qu'il y a de plus normal (j'entends par là que cela ne se verra pas qu'il puisse y avoir des paramètres), nous pouvons ajouter des informations sans avoir peur que le moteur de recherche abandonne, au contraire : cela ajoute des mots clés dont il a tendance à être friand !
Attention hein, je vous vois venir... N'ajoutez pas le message complet au lien : cela n'aurait pas d'intérêt et cela finirait par vous coûter cher en bande passante, sans parler de l'impossibilité de poster un tel lien quelque part sans déformer affreusement la mise en page ! De plus il y a une limite...

Voici comment j'ai procédé.
J'ai pris individuellement chaque fichier de phpBB (profile, viewtopic, etc.) et je me suis demandé quels paramètres GET chacun d'eux admet.
Ensuite, c'est du cas par cas. La seule opération commune à tous les fichiers est de récupérer un titre cohérent en fonction du paramètre principal.

Dans le code, j'utilise des switch imbriqués. Oui, je sais : bouh, pas beau. Il m'arrive même d'en utiliser 3 niveaux (plus des if/else)... J'ai trouvé ça à la fois plus rapide à exécuter et plus clair à relire que de mettre uniquement des if/else.
Comme dans le reste du code source d'un forum phpBB, j'utilise la fonction sprintf() et un fichier de langue (lang_urlrewrite.php). Cela permet de définir des traductions pour ce Mod et, ainsi, d'adapter automatiquement la réécriture de liens selon les préférences définies dans le profil de chaque membre (un membre allemand pourra voir des URLs en allemand) !

Il ne reste plus qu'à mettre la touche finale en convertissant les mots clefs en caractères simples (les lettres de l'alphabet anglais, les chiffres et le trait d'union) avant de les ajouter au lien.
Note : j'ai encore utilisé les expressions régulières dans cette fonction.
Consommer chaud.

Nous avons modifié toutes les adresses affichées dans toutes les pages Web produites par un forum phpBB.

• Les paramètres des liens sont un problème simplement par leur présence
  Solution apportée : les paramètres sont toujours présents mais cachés au sein du lien. Le moteur de recherche n'a pas vraiment de moyen de se rendre compte de leur présence et le lecteur humain a moins de difficultés à les lire et à les reconnaître, voire à les ignorer.
  
  
• Il arrive que phpBB introduise des paramètres vides dans les liens
  Solution apportée : uniquement les paramètres utiles sont introduits dans les nouveaux liens. Cela permet d'éviter le problème du duplicate content.
  
  
• Il manque des mots clefs
  Solution apportée : nous avons ajouté au texte du lien le sujet (ou le titre, le nom d'utilisateur, etc.) de la page liée.
  
  
• L'ordre des paramètres n'est pas très pratique
  Solution apportée : cela n'est plus un problème, dans la mesure où les paramètres sont cachés. Nous les avons également réorganisés afin qu'ils soient toujours présentés dans le même ordre pour un même type de lien. Dans une certaine mesure, cela facilite encore la lecture.
  
  
• Certains moteurs de recherche ont des règles draconiennes à propos du duplicate content
  Solution apportée : les doublons ont été supprimés (i.e. viewtopic.php?p=502#502 est remplacé par viewtopic.php?t=43#502 puis réécrit).
  Rappel : le # n'indique pas un paramètre. Il est destiné au navigateur de l'internaute car il lui permet de positionner verticalement l'affichage de la page.