Bonjour,
Je ne comprend pas un truc dans l’URL rewriting
Que signifie : E=url_propre:$0 ?
Dans le .htaccess…
Apparement cela ne fonctionne pas chez mon hébergeur ?
Merci pour votre aide
–
Geraud Puechaldou
http://www.puechaldou.com
Salut,
Geraud Puechaldou wrote:
Bonjour,
Je ne comprend pas un truc dans l'URL rewriting
Que signifie : E=url_propre:$0 ?
Dans le .htaccess....
Apparement cela ne fonctionne pas chez mon hébergeur ?
Merci pour votre aide
Ça veut dire que apache va placer dans l'environnement ($_ENV pour le php) un élément 'url_propre'=>valeur , valeur déduite du match de la condition, ici l'ensemble de l'expression
$1, $2 ... référencerait les morceaux, dans l'ordre des parenthèses ouvrante dans l'expression regexp de la règle.
J'espère que c'est assez clair
--
toggg
très clair merci,
Il me semblait bien avoir compris cela et donc j’en arrive au fait que ca ne marche pas chez Online…
Tant pis…
Geraud
On 2/19/07, bertrand Gugger <bertrand@toggg.com> wrote:
Salut,
Geraud Puechaldou wrote:Bonjour,
Je ne comprend pas un truc dans l’URL rewriting
Que signifie : E=url_propre:$0 ?
Dans le .htaccess…
Apparement cela ne fonctionne pas chez mon hébergeur ?
Merci pour votre aide
Ça veut dire que apache va placer dans l’environnement ($_ENV pour le
php) un élément ‹ url_propre ›=>valeur , valeur déduite du match de la
condition, ici l’ensemble de l’expression
$1, $2 … référencerait les morceaux, dans l’ordre des parenthèses
ouvrante dans l’expression regexp de la règle.J’espère que c’est assez clair
toggg
–
Geraud Puechaldou
http://www.puechaldou.com
Geraud Puechaldou wrote:
très clair merci,
Il me semblait bien avoir compris cela et donc j'en arrive au fait que ca ne
marche pas chez Online....Tant pis...
Tss...
As-tu essayé le mode qs (query string) ?
Il ne nécessite pas .htaccess , on dit que ça marche moins bien, je suis intéressé pour savoir pourquoi moins bien ...
--
toggg
Euh, ça me paraît pas clair du tout 
Pourtant je sais de quoi ça cause...
Allez je mets mon grain de sel, pourtant je ne suis pas pédagogue pour 2 sous ! Je dirais qu'une ligne url_rewriting comporte une expression à gauche (l'url), une expression à droite et les paramètres. E=url_propre:$0 va stocker l'url (ici $0) dans une variable d'environnement "url_propre". (Voir le post de Bertrand pour les $X)
Ensuite Spip récupère la valeur de cette variable url_propre (donc l'url) pour déterminer à quel id (id_article, id_rubrique...) correspond cette url, afin de construire une nouvelle url à l'aide de l'expression de droite.
BMR
bertrand Gugger a écrit :
Salut,
Geraud Puechaldou wrote:Bonjour,
Je ne comprend pas un truc dans l'URL rewriting
Que signifie : E=url_propre:$0 ?
Dans le .htaccess....
Apparement cela ne fonctionne pas chez mon hébergeur ?
Merci pour votre aide
Ça veut dire que apache va placer dans l'environnement ($_ENV pour le php) un élément 'url_propre'=>valeur , valeur déduite du match de la condition, ici l'ensemble de l'expression
$1, $2 ... référencerait les morceaux, dans l'ordre des parenthèses ouvrante dans l'expression regexp de la règle.J'espère que c'est assez clair
BMR wrote:
Euh, ça me paraît pas clair du tout
Allez je mets mon grain de sel, pourtant je ne suis pas pédagogue pour 2 sous ! Je dirais qu'une ligne url_rewriting comporte une expression à gauche (l'url), une expression à droite et les paramètres.
correct
E=url_propre:$0 va stocker l'url (ici $0) dans une variable d'environnement "url_propre". (Voir le post de Bertrand pour les $X)
en fait $0 représente ce que l'expression aura matché, ici puisqu'el commence par ^ et finit par $ , elle matchera forcément l'url entière, enfin le path (entre l'hôte http://machin.truc/ et la partie query après ?)
Ensuite Spip récupère la valeur de cette variable url_propre (donc l'url) pour déterminer à quel id (id_article, id_rubrique...) correspond cette url, afin de construire une nouvelle url à l'aide de l'expression de droite.
disons pas une nouvelle url , mais sa forme canonique genre spip.php?page=machin
L'id est calculé en interne depuis la variable d'environnement, d'après sa syntaxe , les -, +- et autres hiéroglyphes et la recherche dans la table correspondante du texte au millieu, qui a lui-même été calculé et mémorisé lorsque cet url propre fut émise.
Le [QSA,L] demande à apache:
* QSA: Query string add , de remettre ce qu'il y avait après ? dans l'url demandée, mettons ?var_mode=calcul&autre=bidule
* L: de considérer la règle comme la dernière, soit arréter là tout rewriting
Hihi, on va arriver à décortiquer ça
En note, je prépare actuellement les urls libres qui devraient (je l'espère) remplacer en les assouplissant les urls "propres" et consorts à l'horizon spip2.
C'est pourquoi je m'intéresse fort à ce sujet.
Toute remarque est la bienvenue.
--
toggg
Plus précis y pas !
Mais puisque Spip récupère la forme canonique, pourquoi imposer les "-" en début et fin d'url propre pour les rubriques, par exemple ?
A quoi vont ressembler ces urls libres ?
BMR
bertrand Gugger a écrit :
Hihi, on va arriver à décortiquer ça
En note, je prépare actuellement les urls libres qui devraient (je l'espère) remplacer en les assouplissant les urls "propres" et consorts à l'horizon spip2.
C'est pourquoi je m'intéresse fort à ce sujet.
Toute remarque est la bienvenue.
BMR wrote:
Plus précis y pas !
Mais puisque Spip récupère la forme canonique, pourquoi imposer les "-" en début et fin d'url propre pour les rubriques, par exemple ?
A quoi vont ressembler ces urls libres ?
Voilà, nous y sommes
Ces "hiéroglyphes" qui encadrent (optionnel à la fin) l'url:
+- mot-clé
- rubrique
+ brève (donc pas +- qui a été capté avant)
_ auteur
@ site syndiqué
sinon article
sont là pour permettre au système .htaccess + ecrire/urls/propres.php de déterminer de façon sure, quelle page est demandée et donc dans quelle table chercher l'url "propre" pour déterminer l'id (id_rubrique ...) canonique de l'objet demandé. On sait donc grâce à .htaccess quelle page est demandée, puis grâce au php à quel élément cela correspond.
C'est évidemment pour éviter les collisions dues par exemple à une rubrique et un article qui seraient "nommées" identiquement (c'est évidemment pas rare, même par exemple mécanique sur spip-contrib).
Le système actuel a plusieurs limitations:
* bien que conçu pour aider les humains à mémoriser plus facilement une url (je ne suis pas un numéro ), ils introduisent ces "hiéroglyphes" extrèmement rébarbatifs pour qui ne connait pas la liste ci-dessus, qui ne connait pas spip,
* on ne gère pas les collisions entre objets du même type,
* selon les besoins/désirs de l'implémenteurs on doit coder ne serait-ce que choisir dans config/mes_options.php entre propre, propres2, page html ou standard et si on a d'autres voeux de coder son mespropres.php en reprenant .htaccess
* tout le monde n'a justement pas accès à ce .htaccess
* seul .htacces vérifie pour l'instant l'existance d'un fichier ou répertoire nommé pareil dans le système de fichier, c'est drôle, mets toi en urls propres, fait un article titré "ecrire", publies-le et essayes de le visiter du public
* l'url est forcée depuis le titre, de par les découpages et translitérations nécessaires, on arrive souvent à des trucs incompréhensibles ou pas beaux sans que le rédacteur n'y puisse, sauf changer son titre (souvent pas désirable). in short, on veut que cette url soit modifiable par l'utilisateur, et même "crayonnable" (lol)
* pour finir par le plus grave (amha), le stockage un a un objet-url empèche de se souvenir des anciennes valeurs. Une fois lancée dans la nature, si on change une url propre, on ne saura plus répondre au gens qui connaitraient l'ancienne.
Les urls libres se proposent de virer ces limitations.
La modification principale du schéma de donnée est de sortir les urls des tables objets. Pas une colonne dans spip_articles , spip_rubriques ... mais une table croisée spécifique spip_url:
* url, c'est l'identifiant unique
* type, c'est le type d'objet concerné par l'enregistrement comme article, rubrique ...
* id_objet, c'est la référence de l'objet dans ce type
* ...
On pourra donc avoir plusieurs urls pour le même objet, comme l'ancienne et la nouvelle, celle canonique du titre ou celle corrigée par le rédacteur, des pour les robots ou les humains...
Il y en aura de toute façon une unique pour un objet, le dernier choix, qui elle conservera les "hiéroglyphes".
Les homonymies inter-types seront gérées par une table de priorité.
Voilà, c'était extrèmemnt long, mais c'est un développement très long ... trop
http://trac.rezo.net/trac/spip-zone/browser/_contribs_/_urls_/libre (pas du tout fini)
Merci d'aider par cette discussion à constituer la doc.
http://toggg.com/spip/spip.php?article19
http://toggg.info/spip.php?rubrique6
Non, c'est pas idiot de faire la doc avant le code.
--
toggg
bertrand Gugger a écrit :
Hihi, on va arriver à décortiquer ça
En note, je prépare actuellement les urls libres qui devraient (je l'espère) remplacer en les assouplissant les urls "propres" et consorts à l'horizon spip2.
C'est pourquoi je m'intéresse fort à ce sujet.
Toute remarque est la bienvenue.
Bonsoir,
Je n’ai pas réellement de remarques, je trouve cela très utile le truc est que mon provider à savoir Online, ne permet d’ajouter les variables d’environnement à travers le .htaccess.
Donc à cause de ça, je ne peux pas les faire marcher.
Mais, bon, je crois que le mieux est de changer de provider…
Merci pour l’aide qui a dépassé ma demande…
Geraud
On 2/19/07, bertrand Gugger <bertrand@toggg.com> wrote:
BMR wrote:
Plus précis y pas !
Mais puisque Spip récupère la forme canonique, pourquoi imposer les « - »
en début et fin d’url propre pour les rubriques, par exemple ?A quoi vont ressembler ces urls libres ?
Voilà, nous y sommes
Ces « hiéroglyphes » qui encadrent (optionnel à la fin) l’url:
± mot-clé
- rubrique
- brève (donc pas ± qui a été capté avant)
_ auteur
@ site syndiqué
sinon articlesont là pour permettre au système .htaccess + ecrire/urls/propres.php de
déterminer de façon sure, quelle page est demandée et donc dans quelle
table chercher l’url « propre » pour déterminer l’id (id_rubrique …)
canonique de l’objet demandé. On sait donc grâce à .htaccess quelle page
est demandée, puis grâce au php à quel élément cela correspond.C’est évidemment pour éviter les collisions dues par exemple à une
rubrique et un article qui seraient « nommées » identiquement (c’est
évidemment pas rare, même par exemple mécanique sur spip-contrib).Le système actuel a plusieurs limitations:
- bien que conçu pour aider les humains à mémoriser plus facilement une
url (je ne suis pas un numéro
extrèmement rébarbatifs pour qui ne connait pas la liste ci-dessus, qui
ne connait pas spip,- on ne gère pas les collisions entre objets du même type,
- selon les besoins/désirs de l’implémenteurs on doit coder ne serait-ce
que choisir dans config/mes_options.php entre propre, propres2, page
html ou standard et si on a d’autres voeux de coder son mespropres.php
en reprenant .htaccess- tout le monde n’a justement pas accès à ce .htaccess
- seul .htacces vérifie pour l’instant l’existance d’un fichier ou
répertoire nommé pareil dans le système de fichier, c’est drôle, mets
toi en urls propres, fait un article titré « ecrire », publies-le et
essayes de le visiter du public- l’url est forcée depuis le titre, de par les découpages et
translitérations nécessaires, on arrive souvent à des trucs
incompréhensibles ou pas beaux sans que le rédacteur n’y puisse, sauf
changer son titre (souvent pas désirable). in short, on veut que cette
url soit modifiable par l’utilisateur, et même « crayonnable » (lol)- pour finir par le plus grave (amha), le stockage un a un objet-url
empèche de se souvenir des anciennes valeurs. Une fois lancée dans la
nature, si on change une url propre, on ne saura plus répondre au gens
qui connaitraient l’ancienne.Les urls libres se proposent de virer ces limitations.
La modification principale du schéma de donnée est de sortir les urls
des tables objets. Pas une colonne dans spip_articles , spip_rubriques
… mais une table croisée spécifique spip_url:
- url, c’est l’identifiant unique
- type, c’est le type d’objet concerné par l’enregistrement comme
article, rubrique …- id_objet, c’est la référence de l’objet dans ce type
- …
On pourra donc avoir plusieurs urls pour le même objet, comme l’ancienne
et la nouvelle, celle canonique du titre ou celle corrigée par le
rédacteur, des pour les robots ou les humains…
Il y en aura de toute façon une unique pour un objet, le dernier choix,
qui elle conservera les « hiéroglyphes ».
Les homonymies inter-types seront gérées par une table de priorité.Voilà, c’était extrèmemnt long, mais c’est un développement très long
… trop
http://trac.rezo.net/trac/spip-zone/browser/contribs/urls/libre (pas
du tout fini)Merci d’aider par cette discussion à constituer la doc.
http://toggg.com/spip/spip.php?article19
http://toggg.info/spip.php?rubrique6
Non, c’est pas idiot de faire la doc avant le code.toggg
bertrand Gugger a écrit :
Hihi, on va arriver à décortiquer ça
En note, je prépare actuellement les urls libres qui devraient (je
l’espère) remplacer en les assouplissant les urls « propres » et consorts
à l’horizon spip2.
C’est pourquoi je m’intéresse fort à ce sujet.
Toute remarque est la bienvenue.
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ
–
Geraud Puechaldou
http://www.puechaldou.com
Geraud Puechaldou wrote:
Bonsoir,
Je n'ai pas réellement de remarques, je trouve cela très utile le truc est
que mon provider à savoir Online, ne permet d'ajouter les variables
d'environnement à travers le .htaccess.
Donc à cause de ça, je ne peux pas les faire marcher.Mais, bon, je crois que le mieux est de changer de provider...
Merci pour l'aide qui a dépassé ma demande...
Nan, nan , c'était très bien , on a bien causé.
Mais pourrais-tu essayer d'enclencher qs comme je te le demandais, juste pour voir chez ce genre d'hébergeur ?
Dans tes mes_options.php , tu dis juste "qs" au lieu de "propres" et tu vires ou au moins commente l'url rewriting de .htaccess
rewrite engine off devrait suffire.
Sans rire, je voudrais bien voir si ça marche.
Merci
--
toggg
bertrand Gugger wrote:
> On pourra donc avoir plusieurs urls pour le même objet, comme
> l'ancienne et la nouvelle, celle canonique du titre ou celle
> corrigée par le rédacteur,
Très intéressant comme idée. Je n'ai jamais été tenté par les URLs "propres", car qu'est-ce que cela doit donner pour les articles en coréen ou en tamoul ? Mais pouvoir définir l'URL en publiant l'article - ça oui !
Paolo