L'action
{{redirect page="PagePrincipale"}} permet d'être redirigé vers une autre page lorsqu'une page est demandée (ici vers la
PagePrincipale). Cela permet de faire des "alias" de page, plusieurs noms différents pour une même page.
Synthèse des cas où cette action peut être utile :
- dans le cas où certains termes sont d'orthographe variable, comme justement Persistance of Vision - qui devient PoV, POV, PovRay, POV-Ray... et certains Wiki voient donc deux pages apparaitre pour la même chose, avec du contenu trop élaboré pour être facilement reconciliable en une seule page. [Gniarf]
- en cas de renommage d'une page (en fait le déplacement d'une page vers une autre page), l'ancien nom peut rediriger vers le nouveau nom ; ceci peut être particulièrement utile dans le cas où de très nombreuses pages pointe sur la page originelle, évitant ainsi de changer les liens dans chaque page
- redirection d'une page au nom wiki disgracieux vers une page au nom wiki plus lisible ; exemples :
- SpIp => Spip, DelPhine => Delphine, etc. FAUX: la recherche d'une page dans la base de données est insensible à la casse. Vous pouvez par exemple accéder à cette page-ci avec AcTiOnrediRecT
- Un cas plus correct serait peut-être une redirection de ce genre: UnHommeTué => UnHommeTué ou UnHommeTue
Une différence notable entre une inclusion et une redirection : lors d'une inclusion, le contenu de la page incluant une autre page peut être modifé, donc utiliser l'inclusion pour faire des alias de page ne me parait pas très sûr car il risque d'apparaitre des divergences de contenu si c'est la page incluant une autre page qui est modifée. Par contre, une redirection
impose qu'une seule page est éditable et la cohérence de contenu est donc correcte.
--
GarfieldFr
Paramètres
Cette action accepte un seul paramètre :
- page : paramètre obligatoire pour désigner la page vers laquelle la page est redirigée.
Modification d'une page contenant l'action redirect
Il faut entrer manuellement dans la barre d'adresse du navigateur l'adresse de la page + le "handler" désiré ; par exemple :
Pour la modifier :
Pour la supprimer :
Bugs
J'ai remarqué un bug: si on essai de faire une redirection vers une URL absolue (comme un site internet quelconque),
WikiNi interpréte cela comme un nom de page et popose sa création.
Explication par l'exemple:
ExempleBugActionRedirect (avec l'utilisation du code
{{redirect page="http://www.google.com"}}). On pourrait peut-être envisager de limiter la redirection vers une page qui existe déjà.
--
Nicephore17
- L'action redirect ne prend actuellement pas en charge les urls absolues. Par contre je pense que la redirection vers une page inexistante ne pose pas de problème: une fois la personne redirigée, elle atterrira sur un message lui demandant si elle veut la créer (comme si elle avait donné le nom directement dans l'url, ou cliqué sur un lien direct vers cette page - normalement WikiNi fait un lien d'édition pour les pages inexistantes) -- LordFarquaad
09/02/2005
Lorsqu'on a activé la prévisualisation obligatoire des pages avant enregistrement des modifications, il est impossible d'enregistrer une page qui est une redirection vers une autre. En effet cliquer sur
Aperçu n'affiche pas la page éditée mais la cible de la redirection, qui n'est pas en cours d'édition. Il n'y a alors pas de bouton
Sauver (il n'y a pas de boutons du tout) et il est impossible d'enregistrer cette page. --
JmPhilippe
- Ah oui tiens, pas bête ça, normalement le bug est toujours présent dans la version actuelle... Je pense que le mieux c'est que l'action vérifie si la page est en cours de prévisualisation ou si c'est un affichage normal. Je vois deux techniques pour se faire:
- soit l'action vérifie que le handler actuel est "edit". Si oui, elle affiche un message (pour indiquer sa présence), sinon elle redirige vers la page en question
- soit l'action vérifie que le handler actuel est "show". Si oui elle redirige, sinon elle affiche le message.
- L'inconvéniant des deux techniques est que si un autre handler exécute l'action, le comportement dépendra de ce choix... Il y a des handler pour lesquels la redirection devrait être effectuée (notemment slide_show) et d'autres pour lesquels il ne faut pas (notemment diff). Ecrire en dur le comportement risque de poser quelques problèmes (surtout pour les contributions apportant de nouveaux handlers...)
- Par ailleurs je me demande s'il ne serait pas bon que l'action redirect appèle la page cible avec le même handler que la page courante. Par exemple si on est en mode slide_show et qu'il y a une redirection, la page vers laquelle on sera redirigée sera automatiquement vue en mode slide_show. -- LordFarquaad
Ailleurs
Discussions
Je découvre des possibilités d'usages imprévues de l'action redirect, moyennant des modifications de l'action.
Nous avons mis en oeuvre sur websemantique.org une redirection vers la date du jour : pour l'utiliser {{redirect page="NomDePage" suffix="today"}} qui va donner une redirection vers NomDePage20040205 pour aujourd'hui ; {{redirect page="NomDePage" prefix="today"}} s'utilise pour préfixer plutôt que suffixer. Cette fonctionnalité peut servir par exemple pour créer la CitationDuJour ou bien l'AgendaDuJour ou bien encore OccupationDeLaSalle4AujourdHui ou autres.
Par ailleurs, on peut imaginer beaucoup d'autres applications :
- les news d'hier : {{redirect page="Actualites" suffix="yesterday"}} ;
- ça c'est passé il y a un an : {{redirect page="Actualites" suffix="pastyear"}} ;
- au programme de demain : {{redirect page="Actualites" suffix="tomorow"}} ;
- les anniversaires du jour : {{redirect page="Anniversaires" suffix="anniversary"}} (redirrige vers Anniversaires0502?) ;
- l'agenda de la semaine : {{redirect page="Agenda" suffix="week"}} (redirrige vers Agenda2004Semaine5?).
Je pense qu'il y a encore beaucoup d'autres applications. Pourriez-vous me dire ce que vous en pensez et s'il y a des catégories temporelles que vous voudriez vous ajouter ?
Si tout le monde est d'accord, je souhaite intégrer cette modification quand le CVS sera à nouveau opérationnel.
Ci-dessous le premier code qui gère la date du jour :
<?php
# Permet de faire une redirection vers une autre pages Wiki du site
#
# Parametres : page : nom wiki de la page vers laquelle ont doit rediriger (obligatoire)
#
# exemple : {{redirect page="BacASable"}}
#
# Copyrigth Eric Feldstein 2003 mailto:garfield_fr@tiscali.fr
# Complétée par Charles Népote. mailto:charles02@nepote.org
#
# Licence GPL, vous etes libre d'utiliser et de modifier ce code a condition de
# laisser le copyright d'origine. Vous pouvez bien sur vous ajouter a la liste
# des auteurs.
#
# Installation : copier le fichier dans le repertoire "actions" de WikiNi
// Récuperation des parametres
$redirPageName = $this->GetParameter("page");
if ($this->GetParameter("suffix") == "today") $redirPageName .= date("Ymd");
if ($this->GetParameter("prefix") == "today") $redirPageName = date("Ymd").$redirPageName;
if (!$this->GetParameter("page")){
echo $this->Format("//Le paramêtre \"page\" est manquant.//");
}else{
if (eregi("^".$redirPageName."$",$this->GetPageTag())){
echo $this->Format("//Impossible à une page de se rediriger vers elle même.//");
}else{
$fromPages = array();
$fromPages = explode(":",$_COOKIE['redirectfrom']);
if (in_array($this->GetPageTag(),$fromPages)){
echo $this->Format("//Redirection circulaire.//");
}else{
$fromPages[] = $this->GetPageTag();
SetCookie('redirectfrom', implode(":",$fromPages), time() + 30, "/");
$this->Redirect("wakka.php?wiki=$redirPageName");
}
}
}
?>
Attention la ligne
$this->Redirect("wakka.php?wiki=$redirPageName");, bien que fonctionnelle, est à aménager pour ceux qui utilisent la réécriture d'URL.
--
CharlesNepote
C'est en effet une modification amusante, mais je me demande si il faut l'intégrer telle qu'elle car, après tout, la valeur du suffix/préfix pourrait être n'importe quoi d'autre que "today". Ou alors mettre un tableau de configuration qui à chaque nom de sufix/préfix associe une expression php à évaluer ( fonction eval() ). Mais ça veux dire qu'il faut connaitre PHP pour faire ce que l'on veux --
GarfieldFr
Oui, je comprends ta remarque et je suis d'accord, mais je ne vois pas bien d'autres solutions... La solution eval() complique pas mal et comporte des risques.
- Faut-il créer une action spécialisée par type : {{redirect_today}} (crée des redondances de code)
- Faut-il créer des macros, évaluées dans une autre action et appelées dans cette action : suffix="$macro_today" (c'est peut-être trop compliquer l'architecture de WikiNi)
Je conçois que ma proposition n'est pas idéale mais elle a le mérite d'être simple : peut-être à intégrer dans "contrib" ?
--
CharlesNepote
Je voyais un truc du genre (à la vérification de la syntaxe pré et de l'utilisation correct de eval ) :
<?php
//un tableau dans wakka.config.php :
$aSuffixPrefix = array('today' => 'date("Ymd")',
'agedemagrandmere'=>'unefonction()');
//et dans le code de redirect :
if (!empty($this->GetParameter("suffix"))) $redirPageName .= eval($aSuffixPrefix[$this->GetParameter("suffix")]);
if (!empty($this->GetParameter("prefix"))) $redirPageName = eval($aSuffixPrefix[$this->GetParameter("suffix")]) . $redirPageName ;
?>
C'est vrai que ce n'est pas très simple, mais en fournissant un ensemble de prefix/suffix correct, on ne touche pas au code de l'action et il est facile de rajouter des préfixes/suffixes ... à condition de maitriser à peu prés la fonction eval() --
GarfieldFr
J'aime bien cette idée bien que je n'en ai pas du tout besoin :-j. En fait on pourrait tout simplement donner un accès direct à la fonction php
date() ou alors
strftime() (mais ça pourrait être fort compliqué si on veut pouvoir faire des lastyear etc. car alors il faudrait faire des combinaisons avec
strtotime(), ce qui signifie deux paramètres...)
Mais en fait pour éviter d'avoir à modifier ce fichier on pourrait imaginer un système modulaire, ça devrait être assez aisé... De plus si les modules sont de simples fichiers (et non des fonctions), ils auront accès à GetParameter, et pourraient éventuellement utiliser d'autres paramètres de l'action. Par exemple un module pourrait faire simple date('Ymd') tandis qu'un autre pourrait faire une date au format voulu par l'utilisateur ou encore calculer l'age que ma grand mère avait le jour spécifié par un autre paramètres de l'action.
(A vrai dire je préfère quand les modules sont des fonctions car ça permet de n'inclure qu'une seule fois le fichier même si on n'en a besoin plusieurs fois, et cela permet aussi de déclarer n'importe quelle fonction à l'intérieur de ce fichier sans se soucier de leur existance au préalable. Pour accéder à la
ClasseWiki, les fonctions peuvent soit utiliser la variable globa
$wiki soit on peut la leur fournir via un paramètre) --
LordFarquaad
Lors d'une redirection, j'avais besoin que l'
ActionRedirect retienne des paramètres passés à l'url.
Le cas de figure est que je voulais pouvoir changer le titre de la page de recherche dans le cadre d'un site multilingue, sans toucher au code de footer. Je propose donc deux pages qui redirigent toutes vers une seule:
RechercheTexte et
ZoeKen? redirigent sur
SearCh?. Cela me permet d'afficher un lien vers la page de recherche dans chacune des langues proposées par mon site. Dans mon cas, au moment de la redirection, le paramètre phrase nécessaire à l'action textsearch était perdu.
Quoiqu'il en soit, cette modification du code de redirect a sans doute d'autres applications.
Dites-moi si ça pose des problèmes auxquels je n'ai pas pensé. --
AureLie
<?php
//récupération de critères envoyés par GET
$criteres = "";
$variables = $_GET;
reset($variables);
while (list($key, $val) = each($variables)) {
if($key!="wiki") $criteres .="&".$key."=".$val;
}
//recuperation du parametres de page
$redirPageName = $this->GetParameter("page");
// élaboration de l'adresse de redirection
$redirection = "wakka.php?wiki=$redirPageName$criteres";
// ... et plus bas, modifier la ligne $this->Redirect(...
$this->Redirect("$redirection");
?>
Je vois une application, qui pourrait fonctionner en aménageant un peu ton code, c'est de pouvoir mémoriser en paramètre le nom de la page source pour éviter les redirections circulaires ! On pourrait ainsi concevoir un système plus propre évitant les redirections circulaires, sans cookies (cf. tes commentaires ci-dessous).
Peux-tu mettre ton code en ligne sur ton site pour qu'on le teste ? Je ne vois pas d'inconvénients pour intégrer ton code à
WikiNi, mais le mieux serait d'avoir l'avis de
GarfieldFr qui est le "père" de cette fonction sur
WikiNi...
--
CharlesNepote
Pour moi, si le code marche correctement, il n'y a pas de problèmes, les modifs d'
AureLie peuvent être ajoutées. --
GarfieldFr
Problème des redirections circulaires
L'idée d'Aurélie pour éviter les redirection circulaire est une bonne idée à tester, mais il y a un problème concernant la taille de l'URL en fin de parcour. En effet, le cookie que j'utilise stock la liste de toutes les pages parcourus et pas seulement la première, dans un requète GET, cela va poser le problème de la taille de la requète qui est limité en longeur à quelque chose comme 1024 ou 512 caractères. La je n'ai pas le temp de me pencher dessus, je m'attaque à la réécriture de l'action
{{attach}} et à l'accès CVS auquel je n'arrive pas à accéder. --
GarfieldFr
Je ne comprends pas bien le principe de redirection circulaire... Le but est de stocker toutes les pages parcourues? Quel rapport avec la page redirigée?
De toute façon, la liste des pages parcourues en 30 secondes peut-elle être très longue? (cf. commentaire)
+ Mon code est en ligne: choisissez le néerlandais, cliquez sur le titre de la page
QuilomBo?, ceci lance l'url: "
http://quilombo.collectifs.net/wakka.php?wiki=ZoeKen&phrase=QuilomBo". Or,
ZoeKen? redirige sur
SearCh?. On arrive bien sur la page
SearCh? et le paramètre de recherche "
QuilomBo?" a bien été conservé. Est-ce que je réponds à la question?--
AureLie
Le code de l'action
redirect évite les redirection circulaire. Par exemple, une pageA redirige vers pageB qui redirige vers pageC qui redirige vers pageD, si pageD redirige vers une des pages précédente, on a une redirection circulaire et donc une boucle infini. Pour évité cela, il faut stocker le nom de toutes les pages visitées pour s'assurer que la page courante n'a pas déjà été visité. Quand je dis visité, je ne parle pas par l'utilisateur mais par l'action, seule la dernière page est affichée. Le temp de 30secondes pour le cookie, c'est simplement que je considère que l'envois et la lecture par l'utilisateur de la page finale devrait prendre au moins 30 secondes et donc le cookie devient obsolète et n'est pas renvoyé par le navigateur. C'est une manière assez peu élégante de supprimer la liste des pages parcouru lors de la redirection. Pour répondre à ta question, ce n'est pas le nombre de page qui importe mais la longeur totale du nom des pages parcourus en tenant compte des séparateur, cela peut devenir rapidement très long dans le cas d'une page avec un nom du style
LeNomDUnePageTresLong? qui redirige vers une page avec un nom aussi long.
Il faut bien comprendre que le cas de redirection circulaire est marginal mais en vertu du principe "si c'est pas prévu, c'est sur que l'utilisateur va le faire et ca va planter" (vieille adage de développeur) il faut traiter le cas. --
GarfieldFr
Ooooooook! Bon, j'ai pas encore de solution, mais j'y réfléchis... --Aurélie
La gestion des redirections circulaire est tout à fait buggée actuellement:
- L'utilisation des cookies est une mauvaise idée pour des périodes trop courtes, à cause de leur durée de vie: lorsqu'on envoie le cookie, on doit spécifier ses dates et heures de destruction, or nous ne disposons habituellement que de la date du serveur et non celle du visiteur (NB.: le problème n'est pas une question de fuseau horaire, je suppose d'ailleurs que la date doit être envoyée avec le fuseau GMT) ! Ce qui signifie que si l'heure du serveur est en avance sur celle de l'utilisateur il n'y a pas de problème, mais si elle est en retard (dans le cas présent, de plus de 30 secondes) alors le cookie mourra à l'instant de sa réception. Ex.:
- sur votre serveur installé en local, aucun problème puisque l'heure est exactement la même
- sur wikini.net je n'ai pas de problème puisque j'ai environ 3 minutes de retard
- sur mon site perso, les redirections circulaires font tourner mo navigateur en rond ! Eh oui: il a deux minutes de retard sur moi...
- L'utilisation des cookies pose un autre problème: il est impossible de suivre deux fois la même redirection tant que le cookie n'est pas mort... (à moins qu'on change la redirection temporaire en redirection permanente, auquel cas le navigateur ne devrait pas rappeler la page mais demander directement la page de redirection)
Je pense que l'idéal est d'utiliser une variable de session, celles-ci étant stockées même si le script est arrêté avant sa fin (par exemple dans le cas d'une redirection...)
La technique:
- On stocke dans une variable de session 'redirects' la liste de toutes les pages par lesquelles l'utilisateur a été redirigé: à chaque appel de l'action redirect on y ajoute la page courante.
- On vérifie si la prochaine redirection mène vers une page par laquelle l'utilisateur est déjà passé.
- Si oui: on affiche un message d'erreur permettant d'éditer la page vers laquelle on devrait normalement être redirigé. Ceci permet de facilement corriger le problème. (il est aussi possible de corriger la page courante puisque le message est affiché sur celle-ci. NB.: s'il y a autre chose que l'action redirect dans la page en question, ce sera affiché)
- Si aucune redirection n'est subite, on efface la variable de session 'redirects'. Ceci se fait soit à la fin de la méthode Run(), soit à la fin du script, c'est à dire comme dernière instruction de wakka.php (ce qui revient au même puisque l'appel de Run est actuellement le dernier appel...).
Le code que je propose:
<?php
//recuperation du parametres
$redirPageName = $this->GetParameter('page');
if (!$redirPageName) {
echo '<em><strong>Erreur ActionRedirect</strong>: Le paramètre "page" est manquant.</em>';
} else {
if(!isset($_SESSION['redirects'])) $_SESSION['redirects'] = array();
$_SESSION['redirects'][] = strtolower($this->GetPageTag());
if(in_array(strtolower($redirPageName), $_SESSION['redirects'])) {
echo "<em><strong>Erreur ActionRedirect</strong>: redirection circulaire depuis la page $redirPageName ("
. $this->ComposeLinkToPage($redirPageName, 'edit', 'cliquez ici pour l\'éditer') . ')</em>';
} else {
$this->Redirect($this->Href('', $redirPageName));
}
}
?>
--
LordFarquaad
- Je n'ai pas testé l'histoire des différences d'heures entre serveur et client mais cela semble logique. Pour ce qui est de la variable de sessions j'avais déjà envisagé son utilisation mais comme pour la supprimer il fallait intervenir sur le coeur de WikiNi j'ai préféré utiliser un cookie. Effacer une variable de sessions spécifique à une action dans le coeur de WikiNi est contraire à la logique des actions qui sont des plugins. Par contre, il doit être possible de mettre un cookie de session ( date d'expiration = 0 ) et d'utiliser un autre cookie avec la date/heure de la dernière redirection, cette date serait donc celle du serveur. Ensuite il suffirait de tester cette date pour voir si c'est un residu d'une redirection antérieure ou si elle concerne la redirection courante. Je n'ai pas le temp de la faire en ce moment mais je verais ca la semaine prochaine si j'ai le temp. --GarfieldFr
- Il n'y a pas le choix: pour supprimer les traces des redirections précédentes, il faut modifier le coeur de WikiNi étant donné que l'action redirect n'est, forcément, pas appelée sur la page où on aboutit. Je pense que cela ne pose aucun problème puisque cette action est fournie de base avec WikiNi et qu'il n'y a aucune perte de performance ni aucun problème si on supprime l'action que je propose: la modification à faire dans le noyeau est vraiment minuscule: session_unregister('redirects'); (normalement cela ne devrait pas poser de problème dans les cas où 'redirects' n'existe pas dans les variables de session - cette fonction devrait retourner false pour dire que la variable n'a pu être supprimée - mais rien n'empêche d'en vérifier d'abord l'existance). De plus ce ne serait pas la première action qui nécessite ce genre de modification...
- Note que pour ta solution avec le cookie et la date résoud le problème de durée de vie, mais pas celui empêchant de suivre deux fois la même redirection:
- quelle est le temps au bout duquel on peut considérer qu'il s'agit d'une redirection antérieure ? C'est exactement la même chose que les 30 secondes...
- combien de temps peut prendre une suite de redirections au maximum ? Cela peut être long pour des utilisateurs ayant de lentes connexions (ou utilisant beaucoup leur ligne pour faire autre chose), ou pour des hébergeurs plus lents où saturés (il ne faut pas oublier qu'avant d'appeler l'action redirect, wikini s'est déjà connecté à la base de données, a fait plusieurs requêtes - notemment pour vérifier si l'utilisateur était connecté ou non, a généré l'entête etc.)
- n'y a-t-il pas un conflit entre ces deux durées ? Par exemple l'utilisateur pourrait demander une actualisation au bout d'à peine quelques secondes (notamment le cas où il se dit "la page ne semble pas se charger correctement, je relance" alors qu'il y a en fait simplement plusieurs redirections: il a déjà reçu le cookie...)
- Il ne me semble donc pas mieux d'appliquer cette technique, ou alors il faut faire la même chose que ce que je propose supprimer ton cookie en fin de script...
- Une autre solution (que je n'aime pas du tout mais je l'expose tout de même) serait peut-être d'utiliser un unquid dans l'url:
- Lorsque l'action redirect est déclenchée, après avoir vérifié que la redirection ne pointe pas vers la page courante, elle vérifie s'il y a un unquid dans les paramètres GET:
- Si non:
- elle crée un nouvel unquid $id
- elle envoie un nouveau cookie pour le stockage des redirections, avec comme données un tableau du type "array($id => array(page courante))" (sérialisé ou autre)
- elle ajoute aux paramètres de l'url de redirection le $id et redirige
- Si oui (disons $id):
- elle vérifie dans le cookie des redirections s'il y a un élément du type array($id => tableau contenant la prochaine page de redirection)
- si oui, elle affiche un message d'erreur et s'arrête ici.
- elle renvoie le nouveau cookie avec comme données le même tableau mais avec en plus le nom de la page courante
- elle ajoute aux paramètres de l'url de redirection le $id et redirige
- C'est fort compliqué et en plus ça donne l'illusion aux navigateurs (et robots) d'avoir affaire à des pages différentes... mais je doute qu'il y ait autre chose de possible. Je préfère nettement ma solution qui est très simple et non moins efficace... -- LordFarquaad
- En effet, ta solution est la plus simple mais ce qui me gène c'est d'intervenir dans le coeur de WikiNi. C'est un principe de programmation, quand tu écris un plugins, tu n'as pas à modifier le coeur de l'application pour que celui ci fonctionne. De plus, ce genre de modification impose à tous ceux qui veulent upgrader leur action Redirect d'upgraper aussi leur fichier wakka.php et de perdre d'éventuelles modifications qu'ils ont apportés (ou de les réécrire). --GarfieldFr
- La solution est pourtant idéale... On pourrait peut-être s'attaquer aux choses par un autre bout à ce moment là: réécrire la méthode redirect pour qu'elle s'occupe elle-même des redirections circulaires. Ce serait donc une évolution de WikiNi et non de l'action redirect. Ensuite l'action redirect pourrait suivre l'évolution en ne se souciant plus des redirections circulaires...
- Mais en fait ma façon de voir les choses est différente: l'action redirect fait partie de la version officielle de WikiNi, et la version qu'on aimerait développer dans cette page devrait être intégrée à une prochaine version de WikiNi. Il n'y a pas de raison pour qu'un plug-in compatible avec la version 0.5.0 de WikiNi soit obligatoirement compatible avec les version antérieures... Et pour moi d'ailleurs l'action redirect est plutôt un module indissociable de WikiNi (de par le fait qu'elle est fournie avec), et on a "le droit" d'effectuer des modifications sur le choeur en fonction des demandes de la part des modules fournis de base... WikiNi n'est pas qu'un noyau c'est aussi un ensemble de modules; sans cela, WikiNi n'est plus rien !
- Pour finir, dans le cas présent, la modification à effectuer au noyeau est vraiment des plus minimes, si quelqu'un veut effectuer la mise à jour il n'aura qu'à ajouter la ligne en question et ce sera bon. [mais c'est tout de même étrange de ne vouloir faire les mises à jour que des modules je trouve... quand on fait ce genre de chose il faut accepter d'avoir à modifier le coeur.] Inversément, les anciennes versions de l'action redirect seront toujours compatibles avec la nouvelle version du noyeau... -- LordFarquaad
- Bon, ok, fais les modifs dans le CVS alors --GarfieldFr