Wikini:ReecritureDURL

Mettre en place une réécriture d'URL

La réécriture d'URL permet d'avoir des URL indépendantes de tout aspect technique relatif au moteur de Wiki. Concrètement :

les adresse de type http://www.xxx.zzz/wakka.php?wiki=PagePrincipale
deviennent http://www.xxx.zzz/PagePrincipale

Ainsi :

les adresses sont plus courtes, plus faciles à mémoriser, à communiquer, à écrire
la technologie utilisée pour générer les pages peut changer sans affecter les adresses (par exemple, on peut imaginer que, dans quelques années, l'adresse technique, avant réécriture, deviendra http://wikini.php5?page=PagePrincipale)

Ces liens réécrits sont appelés des URL signifiantes

Pré-requis : il faut que le serveur sur lequel vous effectuez l'installation, gère la réécriture d'URL. Si c'est un serveur Apache, il faut regarder s'il intègre le module mod_rewrite. (L'hébergeur free.fr, par exemple, ne permet pas la réécriture d'URL.)

1. Modifier le fichier /actions/header.php

2. Déplacer les fichiers CSS

Il faut déplacer les fichiers CSS dans le répertoire spécifique pour lequel les règles de réécriture seront différentes. Dans notre exemple, il s'agit du répertoire /style/.

3. Création d'un fichier .htaccess à la racine du site.

RewriteEngine on # N'applique aucune règle pour les fichiers contenus dans le répertoire /style/ RewriteRule ^style/(.*)$ style/$1 [L] # RewriteRule ^style$ wakka.php?wiki= [L] # http://xxx.zzz/NomWiki => http://xxx.zzz/wakka.php?wiki=NomWiki RewriteRule ^(.*)$ wakka.php?wiki=$1 [QSA,L]

4. Modification du fichier wakka.config.php

"base_url" => "http://xxx.zzz/racine/", "rewrite_mode" => "1",

J'ai eu des problèmes avec ces règles (placées dans mon cas dans le fichier de config du serveur Apache) : les paramètres [QSA,L] ne modifient pas le chemin du script et le test if (!eregi("wakka.php", $_SERVER['PHP_SELF'])) échoue. Je ne comprend pas bien la raison de ce test, mais il faut rajouter le paramètre "PT" (passthrough) pour qu'il passe. Attention, si l'on rajoute ce paramètre, la requète modifiée est soumise à nouveau au serveur, outre d'éventuels impacts sur les performances, il faut donc rajouter une règle de non réécriture de "wakka.php" pour éviter de boucler. En modifiant la règle sur les css, on peut également éviter de les déplacer... En fin de compte, les règles que j'utilise sont :

#Cherche les feuilles de style sous la racine
RewriteRule ([^/]*\.css)$ /$1 [L]
#N'applique aucune règle pour wakka.php
RewriteRule ^/wakka.php - [L]
#RewriteRule ^style$ wakka.php?wiki= [L]
#http://xxx.zzz/NomWiki => http://xxx.zzz/wakka.php?wiki=NomWiki
RewriteRule ^/(.*)$ /wakka.php?wiki=$1 [QSA,L,NE,PT]

-- EricVanDerVlist?

Et si le wakka.php n'est pas à la racine :
RewriteRule ^/titi/toto/(.*/)?([^/]*\.css)$ /titi/toto/$2 [L,PT]
RewriteRule ^/titi/toto/wakka.php - [L]
RewriteRule ^/titi/toto/(.*)$ /titi/toto/wakka.php?wiki=$1 [QSA,L,NE,PT]
-- DavidDecotigny

Personnellement j'utilise les règles suivantes avec succès (dans un .htaccess !) :
(les fichiers CSS sont dans le répertoire /_style)
- RewriteEngine on
- RewriteRule ^_style$ wakka.php?wiki= [L]
- RewriteRule ^_style/(.*)$ _style/$1 [L]
- RewriteRule ^(.*)$ wakka.php?wiki=$1 [QSA,L]
-- ProgFou
- Où est placé ton fichier .htaccess ? Dans quel répertoire est placé WikiNi ? -- CharlesNepote
  - Mon .htaccess est dans le répertoire principal de WikiNi, le même où se trouve le wakka.php. WikiNi peut lui être placé en principe n'importe où dans le site, mais j'avoue ne pas encore avoir testé ; pour le moment il est sous /wikiteki (à la fois sous-dossier physique de la racine du site et chemin d'accès dans l'URL). -- ProgFou

On pourrait simplifier le tout en faisant que les étapes 1 et 2 soient implémentées de base dans WikiNi, l'étape 4 étant déjà implémentée par calcul automatique de la valeur de ces options de configuration. Le fait d'avoir un répertoire /style/ permettrait d'ailleurs également de se préparer à la possibilité de donner à l'utilisateur le choix d'une feuille de style préférée. -- ProgFou
- Oui. Cela fait un moment que je pense à cette modification. Je crois qu'elle introduit un problème mineur mais qui me titille un peu : on ne peut plus utiliser le mot "Style" comme nom de page, non ? Il faudrait peut-être choisir le nom de répertoire /~style/ pour limiter le problème, le caractère "~" étant assez peu employé... Sinon, je suis d'accord sur le fond pour modifier l'emplacement des feuilles de styles : les avantages :
  - isole les feuilles de style dans répertoire : elles sont plus faciles à trouver
  - permet d'envisager la délégation de la fabrication/mise à jour des feuilles de style à un graphiste : soit via une interface à construire, soit en lui ouvrant le répertoire en FTP
  - permet de faciliter le travail sur plusieurs feuilles de style (on verra les suggestions que j'avais faite dans les SuggestionsInterfaceUtilisateur)
- -- CharlesNepote

Je viens de me rendre compte après quelques tests que la détermination automatique de l'option base_url est incorrecte. Il faudra donc corriger ce petit souci, cf les RapportsDeBogues. [OK. -- CharlesNepote] Pendant ces mêmes tests, je me suis aussi rendu compte que l'étape 1 n'est pas correcte dans le cas où on ne fait pas de ré-écriture d'URL. Ceci peut se corriger facilement en utilisant un chemin relatif style/... au lieu de passer par l'option de configuration base_url.
- Oui. Je me demandais d'ailleurs pourquoi on utilise pas systématiquement des adresses relatives dans le code généré, permettant une économie d'octet substantielle ainsi qu'une meilleure lisibilité du code. -- CharlesNepote
- Ahem ... Je retire la correction que je proposais car elle montre clairement pourquoi on a besoin du base_url ! ;-) En fait quand on fait un appel de page avec ré-écriture d'URL, par exemple .../wikini/ReecritureDURL/edit, l'URL de base au niveau du serveur web devient alors .../wikini/ReecritureDURL/ et il ne pourra donc pas trouver de sous-répertoire style/ sous le répertoire ReecritureDURL/ qui n'existe pas réellement ! On est donc obligé, dans le cas de la ré-écriture d'URL, de spécifier le chemin base_url pour pouvoir atteindre le répertoire de styles correctement. Néanmoins, la correction de bug que j'ai proposé permet de calculer correctement le base_url, et une petite modification du point 1 permet de l'intégrer définitivement au code source : il suffit de rendre l'affichage du préfixe de base_url conditionnel au mode de ré-écriture d'URL. En plus clair, dans le fichier actions/header.php, mettre <?php if ( $this->GetConfigValue("rewrite_mode") ) { echo $this->GetConfigValue("base_url"); } ?>style/ à chaque fois qu'il faut accéder à un fichier de styles. -- ProgFou

Le plus simple est de rajouter dans actions/header.php:
<base href="<?php echo $this->GetConfigValue("base_url");?>">
Comme ça, tous les répertoires relatifs seront basé sur l'URL de base, les /style marcheront donc meme pour /PageText/edit -- Laurent
- C'est une idée intéressante ! Mais est-ce que tous les navigateurs honorent bien cette balise ? -- ProgFou

Concernant le fait de perdre la possibilité d'utiliser un nom de page style, je dirais que c'est un faux problème. Effectivement, sous Windows il est probable que Style donne le contenu du répertoire style/ du fait que ce "système" ne tienne pas compte de la casse. Mais le problème serait alors le même pour Actions, Handlers, Formatters et Setup ! Et peut-on vraiment créer un répertoire commençant par un ~ sous Windows (je n'utilise pas, donc je sais pas ;-)). Quand je dis que c'est un faux problème, c'est parce que d'une part les "vrais" serveurs web sont normalement sous un système de type Unix qui lui tient bien compte de la casse et ne pose pas de problème à ce niveau, et que d'autre part il "suffirait" d'indiquer clairement que certains mots sont inutilisables dans le cas d'un serveur sous Windows (et paf, un truc de plus pour rammener les gens à la raison ! ;-)).
-- ProgFou
- Pour le caractère "~", on laisse en effet tomber puisqu'il est donné comme "unsafe" par la RFC:1738 (interwiki). Mais je maintiens qu'il faudrait choisir des noms de répertoires un peu spéciaux. Ce n'est pas un problème de casse, l'utilisateur pouvant actuellement utiliser "Style" ou "style" comme nom de page. On peut peut-être faire commencer le nom des répertoires par "_" ou bien "-" en interdisant explicitement leur emploi au début du nom d'une page. -- CharlesNepote
- Ah ? Je ne savais pas qu'on pouvait (sur le principe, pas techniquement) aussi créer des noms de pages en minuscule (je débute en Wiki Wiki moi ;-)) ... Dans ce cas, je suis aussi d'accord pour nomber les noms de répertoire de manière spécifique. Néanmoins, il faudra tester sous les différents serveurs web possibles (en fait surtout les OS qui les supportent) si les solutions proposées sont viables ; par exemple je ne suis pas certain que Windows accepte un "-" ou "_" en début de fichier, si ?? Si ça fonctionne, je suis 100% partant ! -- ProgFou

Réécriture chez OVH

Grrrrr... je n'arrive pas à mettre en oeuvre la réécriture chez OVH...
Il semble qu'OVH nécessite une mise en oeuvre particulière :
ORT (Ovh Redirect Technology) est un module développé par OVH qui nous permet d'héberger un nombre important de sites avec peu de RAM utilisée sur les machines. Mod_ort modifie l'URI de la page et vous pouvez donc avoir un problème si vous voulez utiliser mod_rewrite. La solution consiste à redefinir dans mod_rewrite la racine de reécriture: RewriteRule? ^/grp([0-9]+)\.php$ groupe.php?id=$1 [L] RewriteRule? ^/art([0-9]+)\.php$ article.php?id=$1 [L] RewriteRule? ^/age([0-9]+)\.php$ agenda.php?id=$1 [L] RewriteRule? ^/membre_([0-9]+)\.php$ membre.php?id=$1 [L] doivent être changés en RewriteRule? ^/grp([0-9]+)\.php$ /groupe.php?id=$1 [L] RewriteRule? ^/art([0-9]+)\.php$ /article.php?id=$1 [L] RewriteRule? ^/age([0-9]+)\.php$ /agenda.php?id=$1 [L] RewriteRule? ^/membre_([0-9]+)\.php$ /membre.php?id=$1 [L]

Mais je n'arrive à rien... Il faut dire que mon wikini est dans /dev2/1/wikini/
Peut-être que je cumule les difficultés... où dois-je mettre le .htaccess ? à la racine / ou bien dans /dev2/1/wikini/ ?
J'ai essayé la config suivante sans succès (avec le .htaccess à la racine comme dans /dev2/1/wikini/) :
RewriteEngine? on RewriteRule? ^/(.*)$ /dev2/1/wikini/wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? ^/(.*)$ /wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? /(.*)$ /dev2/1/wikini/wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? /(.*)$ /wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? ^/dev2/1/wikini/(.*)$ /dev2/1/wikini/wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? ^/dev2/1/wikini/(.*)$ /wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? /dev2/1/wikini/(.*)$ /dev2/1/wikini/wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? /dev2/1/wikini/(.*)$ /wakka.php?wiki=$1 [QSA,L,NE,PT] RewriteRule? ^/dev2/1/wikini/(.*)$ /dev2/1/wikini/wakka.php?wiki=$1 [QSA,L] RewriteRule? ^/dev2/1/wikini/(.*)$ /wakka.php?wiki=$1 [QSA,L] RewriteRule? /dev2/1/wikini/(.*)$ /dev2/1/wikini/wakka.php?wiki=$1 [QSA,L] RewriteRule? /dev2/1/wikini/(.*)$ /wakka.php?wiki=$1 [QSA,L]

Des idées ?
-- CharlesNepote

Au moins une : ajouter un RewriteBase, ça peut aider, grandement ! -- ProgFou

Solution alternative

Laurent Jouannau signale une autre solution pour gérer la réécriture d'URL, mais je ne la comprend pas :
http://ljouanneau.com/blog/2003/10/28/181-LusineAGazPhpwiki :
Le problème, c'est que vous vous basez sur le mod rewrite d'apache, ce qui est super chiant à configurer. Alors qu'il suffirait de le faire par vous même en php. Du genre, vous avez l'url monsite.com/wiki/truc/muche, et dans le fichier wiki.php, vous traitez vous même la partie truc/muche. C'est relativement simple, il y a plus de chance que ça passe chez les hébergeurs (il suffit juste qu'il y ait l'option Multiviews) et évite aux utilisateurs d'installer des fichiers compliqués, dur à adapter à ses propres besoins.
Que comprenez-vous ? (Je vais lui écrire pour en savoir plus.) -- CharlesNepote

Tout à fait d'accord avec Laurent, les Rewrite Rules ne fonctionnent pas sur les pages perso de Free, voici ce que je fais sur un site que je développe est qui à l'air de correspondre à ce que Laurent dit :
je met des .htaccess avec des "ErrorDocument? 404 /index.php" dedans qui renvoit vers index.php, et index.php analyse la variable $_SERVER["REQUEST_URI"] et voilà, je peux interpréter l'url comme bon me semble, l'utilisateur ne sait même pas qu'il a changé de page, l'url dans la barre d'adresse n'est pas modifiée
Avec cette façon de faire, il n'y a même pas besoin de l'option multiviews comme le dit Laurent sur sa page.
Un peu de code:


$page = $_SERVER['REQUEST_URI'];  # url demandée
$path_parts = pathinfo($page);
$pagevoulue = $path_parts["basename"];
$arborescence = $path_parts["dirname"];
$rep = split('/', $arborescence);

$rep est un tableau qui contient l'arborescence de la page demandée.

- JarodEvans

Personnelement pour que ca marche j'ai du modifier le .htaccess un peu plus délicatement.

Voici le contenu de ce fichier:
<IfModule? mod_rewrite.c> RewriteEngine? On RewriteOptions? MaxRedirects?=10 RewriteBase? /~pol/wiki/ # http://xxx.net/~pol/wiki/wakka.css => http://xxx.net/~pol/wiki/wakka.css RewriteRule? ([^/]*\.css)$ $1 [L] RewriteCond? %{REQUEST_FILENAME} !-d # http://xxx.net/~pol/wiki/PagePrincipale => http://xxx.net/~pol/wiki/wakka.php?wiki=PagePrincipale RewriteRule? ^([^\.\?/]+)$ /~pol/wiki/wakka.php?wiki=$1 [QSA] </IfModule?>

Voila ... n'oubliez pas de changer les repertoires ainsi que votre fichier de config. Pas besoin de changer les fichier de style. Ce fichier htaccess prend tout en compte.
-- TheTransporter

Ca fonctionne chez moi pour afficher une page, mais l'appel aux handlers ne fonctionne pas (Not found) : PagePrincipale/edit.
Pour que cela fonctionne, il faut corriger la dernière ligne de cette façon :
RewriteRule? ^([^\.\?]+)$ /w/wakka.php?wiki=$1 [QSA]
Je n'arrive cependant pas à comprendre pourquoi ça marche. Je comprends cette ligne comme voulant dire :

recherche toute suite de caractères contenant au moins caractère (+) et qui n'est pas (^) un point (\.) ou un point d'interrogation (\?)

Je n'utilise pas la ligne :
RewriteCond? %{REQUEST_FILENAME} !-d
-- CharlesNepote

Notez que le fichier .htaccess contenu dans le "package" n'est pas correct sur plusieurs aspects...

Il m'a fallut environ 2 minutes pour comprendre pourquoi je n'arrivais pas a la page d'installation du wiki...

Et ça pose encore des problèmes sur les pages d'édition... (a cause du "slash"...)

RobertKarpeles

Réécriture (très) facile

Je viens juste d'installer WikiNi sur un sous-domaine test afin de le comparer à WikiMedia? (et surtout comparer la facilité d'installation des deux sur Lycos... enfin c'est fait maintenant), et j'ai voulu mettre en place directement la réécriture d'url. Voici ce que j'ai fait, c'est très simple et ça marche !

Déjà, surprise: à l'installation on nous mâche le travail:
Pour la configuration de l'URL de votre WikiNi, enlevez la partie "wakka.php?wiki=". WikiNi créera donc des urls du type http://www.votredomaine.tld/votrerepertoire/PagePrincipale
Maintenant il faut mettre en place l'url rewriting. Très facile: créez un fichier .htaccess contenant les deux lignes suivantes:
RewriteEngine on RewriteRule ^([A-Z].+)$ /wakka.php?wiki=$1& [qsa]
(NB.: il serait peut-être bon d'exclure certains carractères plutôt que d'utiliser ".+". Par ailleurs cela rend inaccessible les fichiers se trouvant à la racine et dont le nom commence par une majuscule, mais il est peu probable que vous en ayez [à part les fichiers LICENSE etc.] et il est assez simple d'écrire des règles d'exclusion...)
Pour finir on constate que la feuille de style (et les images éventuelles) ne se chargent plus correctement lorsque l'on édite des pages :-( Mais qu'à cela ne tienne ! On va dire au navigateur wab où il doit aller les chercher !
Pour ce faire, éditez le fichier actions/header.php. Vers la ligne 39, juste après "<head>", vous n'avez qu'à ajouter la balise suivante:
<base href="http://www.votredomaine.tld/votrerepertoire/" />
Et le tour est joué ! Pas d'inquiétudes, ça reste du XHTML1.0 valide :-)

LordFarquaad

Très bonne idée !
TheTransporter-

Le <base href="..." /> empêcherait une lecture du site hors ligne, n'est-ce pas ? -- ProgFou

J'imagine que ça dépend de la technique que tu emploies pour le lire hors ligne... Par exemple si tu as sauvé la page avec ton navigateur, il est probable que le css ne soit pas sauvé, par contre si tu regardes la page en cache dans ce dernier, ou que tu as utilisé un aspirateur de site, alors normalement il le sera... de toute façon le seul problème sera au niveau de l'apparence (feuille de style et images) mais la page en elle-même restera lisible... Le problème vient de l'utilisation de la slash pour les handlers, et il faudrait l'enlever si on veut des urls de ce type. Comme je viens à peine de découvrir WikiNi, je n'ai aucune idée de la quantité de code à modifier pour ce faire, par contre à ce moment là il faudrait en profiter pour faire un url rewriting complet, supprimant définitivement les paramètres passés par GET, car les moteurs de recherche ne les aiment pas du tout (j'ai lu des notes sur WebRankInfo signalant que Google indexait difficilement les pages avec plus de deux paramètres - les robots ont en effet une "crainte" de tomber dans des boucles infinies)... LordFarquaad
- Ne pas utiliser de / (slash) irait à l'encontre de l'objectif d'une ré-écriture d'URL... Par contre je viens d'avoir une nouvelle piste : supporter la ré-écriture directement au niveau du script, via la variable d'environnement PATH_INFO qui semble être disponible autant sous Apache que sous MS-IIS. À prospecter ! -- ProgFou
  - A mon sens l'objectif de l'URL rewriting est de simplifier les urls, je ne vois pas en quoi cela force à utiliser la slash... curio propose d'ailleurs avec quelques exemples.
  - Par contre je n'avais jamais entendu parler de ce "PATH_INFO" et de la fonction Multiviews, à part en installant Wikimedia en local l'autre jour... J'ai fait quelques recherches mais je ne comprends pas trop comment ça marche (enfin ce que je ne comprends pas surtout c'est pourquoi le navigateur n'a pas besoin d'une balise <base>...). Par ailleurs en local, pour Wikimedia, index.php/Accueil fonctionne, mais pas index/Accueil ou même juste index (pourtant d'après ce que j'ai compris, ça devrait marcher, non ?)... Sinon il faudrait vérifier que l'option Multiviews est répendue sur les serveurs de production (et surtout sur ceux qui n'acceptent pas l'url rewriting...), mais de toute façon ça ne coute rien de la mettre en oeuvre :-). Ceci semble en fait assez facile, plusieurs personnes en parlent ici. En supposant qu'on n'a jamais de slash dans les valeurs passées en arguments, on peut remplacer le ?, les = et les & par des slash, et dès lors il suffit d'exécuter ce code en début de script (fortement inspiré d'un commentaire de pathinfo()):
    <?php if(isset($_SERVER['PATH_INFO'])) { $viewcode = explode('/', $_SERVER['PATH_INFO']); $num = count($viewcode); if($num % 2 == 1) { $viewcode[] = ''; $num++; } for($i = 1; $i < $num; $i += 2) $_GET[$viewcode[$i]] = $viewcode[$i+1]; } ?>
  - (NB.: en conservant le ? dans les urls, on peut appliquer la même technique en remplaçant $_SERVER['PATH_INFO'] par $_SERVER['QUERY_STRING'], ce qui ne nécessite dès lors plus aucune condition au niveau du serveur. Je ne sais pas si cela aurait un impact réel sur les moteurs de recherches, mais au moins cela rend les urls plus conviviales, surtout si on renomme wakka.php en index.php...)
  - Cela me parait donc être une piste intéressante :-). Sinon autre piste à laquelle j'avais songé: en comptant le nombre de slash qu'on a dans la query_string, on peut utiliser la balise <base> avec des "../", il faudrait vérifier si cela ne résoud pas le problème de consultation hors ligne... et puis il y a toujours la non-utilisation des slash...
  - Au final je me demande s'il n'y a pas une solution adaptée à chaque serveur...
  - LordFarquaad

Je ne voulais pas toucher au moteur de wikini pour mes rewrite rules:

Et donc ne pas "Modifier le fichier /actions/header.php"

<link rel="stylesheet" type="text/css" media="screen" href="<?php echo $this->config["base_url"]?>style/wakka.basic.css" /> <style type="text/css" media="all"> @import "<?php echo $this->config["base_url"]?>style/wakka.css";</style>

G donc écrit les rewrites rules suivantes qui fonctionnent (en tous cas sous Apache 2.0):

RewriteCond %{REQUEST_URI} !^.*\.css [NC]
RewriteRule ^(.*)$ wakka.php?wiki=$1 [QSA,L]

Il faut toujours bien sur:

Modifier le fichier wakka.config.php

"base_url" => "http://xxx.zzz/racine/",
"rewrite_mode" => "1",

(quoique ça marchait très bien avec "rewrite_mode" => "0", ;-)

RoBert

Tiens en fait j'ai jamais changé ce "rewrite_mode" non plus moi... Euh sinon, tu as essayé d'éditer une page par exemple ? Je doute que le css soit pris correctement avec ta technique (qui est, somme toutes, la même que la mienne en fait...). -- LordFarquaad

Effectivement. Tu as raison.

Il faut en fait toujours modifier le fichier /actions/header.php

et légèrement différement : le chemin vers les feuilles de styles doit être absolu, ce qui revient à ajouter un "/" (éventuellement un "/repertoire/") devant les "wakka" contenu dans /actions/header.php, ce qui donne ceci et ca marche:
<link rel="stylesheet" type="text/css" media="screen" href="/wakka.basic.css" /> <style type="text/css" media="all"> @import "<?php echo (!isset($_COOKIE["sitestyle"]))?'/wakka':'/'.$_COOKIE["sitestyle"] ?>.css";</style>
Merci de ta remarque.
RoBert

J'ai un petit soucis avec la première solution : lorsque je tape dans un navigateur http//xxx.www.ccc/racine au lieu de http://xxx.www.ccc/racine/ ca ne marche pas. Je crois que c'est le dernier Rewrite (RewriteRule ^(.*)$ wakka.php?wiki=$1 [QSA,L]) qui pose problème. Une idée ?
MaikoMou?
C'est que ton serveur ne prend pas en charge la redirection automatique de racine vers recine/. A mon sens c'est la seule possibilité, as-tu testé avant d'intsaller la redirection ? As-tu un message d'erreur qui s'affiche ? -- LordFarquaad

La solution de wikka (en)

Ils sont malins chez wikka, leur règles du module rewrite ne prennent pas en compte les répertoires à ignorer (comme style/ par exemple) mais ces répertoires contiennent simplement un petit .htaccess tout simple qui contient ceci :

<IfModule mod_rewrite.c> RewriteEngine off </IfModule>

Ainsi, on obtient le même fonctionnement qu'ici mais d'une façon un peu plus lisible. C'est aussi une bonne solution pour ceux qui veulent ajouter un autre répertoire contenant des fichiers à inclure (scripts, etc.) sans modifier les règles ReWrite. -- OlivierPoncin

<< FiltrerLeSpamDesReferrers

DocumentationAdministrateurTechnique

HeaderPhp >>