Les révisions 13719 et 13741 introduisent une API un peu plus fiable
pour la gestion d'URLs (tout en conservant la compatibilité
ascendante). Cette API sera présente dès la prochaine release stable
(SPIP 2.0.4), à venir bientôt.
Avec cette API, la fonction urls_propres_dist() [par exemple] peut
dire à public/assembler.ph que telle URL correspond a tel objet, sans
qu'on se trouve sur l'URL en question ; ni se voir rediriger lorsqu'il
s'agit d'une vieille URL.
C'est pratique pour analyser des lots d'URLs pointant vers soi (ex:
plugin Yagloo, analyse des liens entrants, trackbacks).
Désormais pour etre moderne une fonction urls_xxxx() retourne un
array(contexte, type, redirect, fond). Aucun de ces arguments n'est
obligatoire.
* contexte : indiquer le contexte (ex: id_article => 12)
* type : indiquer le type d'objet (ex: c'est un 'article')
* redirect : si on est sur cette page, rediriger vers la nouvelle URL
* fond : modifier le fond demandé à priori. (pas utilisé dans les urls/ du core)
Le nouveau système respecte un ?page=xxx qui serait indiqué dans le
.htaccess : ainsi si dans la partie "personnalisation" du .htaccess on
indique :
RewriteRule ^rss/?$ spip.php?page=backend [QSA,L]
l'adresse URL_SITE_SPIP/rss/ donnera bien le backend, même si un
article s'intitule 'rss'
Au passage on se debarrasse enfin de l'affreux ?page=type_urls (mais
compat ascendante assuree)
Le nouveau système respecte un ?page=xxx qui serait indiqué dans le
..htaccess : ainsi si dans la partie "personnalisation" du .htaccess on
indique :
RewriteRule ^rss/?$ spip.php?page=backend [QSA,L]
l'adresse URL_SITE_SPIP/rss/ donnera bien le backend, même si un
article s'intitule 'rss'
Super !
J'ai ceci dans un .htaccess :
RewriteRule ^@(.*)([^@])\.html$ spip.php?page=$1$2 [QSA,L] # Permet des url du type @monsquelette.html
Je suis en url_propre2.
Malheureusement, je ne peux pas utiliser la syntaxe #URL_PAGE{monsquelette} parce que c'est la seule balise d'URL qui n'est pas personnalisable (sauf erreur de ma part)...
Un espoir ?
Malheureusement, je ne peux pas utiliser la syntaxe #URL_PAGE{monsquelette}
parce que c'est la seule balise d'URL qui n'est pas personnalisable (sauf
erreur de ma part)...
Un espoir ?
Le problème des #URL_xx c'est que ce sont des balises gérées de
manière dérogatoire par une fonction unique. Mais si tu l'appelles
autrement tu peux la programmer comme tu veux.
Avec cette API, la fonction urls_propres_dist() [par exemple] peut
dire à public/assembler.ph que telle URL correspond a tel objet, sans
qu'on se trouve sur l'URL en question
j'avoue ne pas très bien comprendre ce que signifie cette phrase
oups en fait elle mélange deux trucs :
1) assembler.php a besoin de savoir quel est l'objet sur la page en
cours de consultation, afin de régler correctement le contexte et le
squelette (et donc calculer la page "article" avec id_article=12, si
on appelle l'URL 'Mon-article'). Ca c'est l'utilisation de
urls/propres.php (et autres) depuis le début.
2) Nouvelle utilisation rendue possible : si par exemple tu as une
liste d'urls de ton site (récupérée depuis un moteur de recherche,
disons, en réponse à une requête particulière), tu peux demander à
urls_propres_dist() de te renvoyer, pour chaque url, l'objet
correspondant (i.e. : 'Mon-article' est l'article 12). Auparavant, ça
ne marchait pas.