[spip-dev] #URL_PAGE renvoie des adresses absolues

Yop,

Il semblerait que le fonctionnement de la balise #URL_PAGE ne soit pas
cohérent avec celui de #URL_ARTICLE et ses amis. En effet, il renvoie
des URL absolues.

Y a t'il une raison pour appeler generer_url_public() avec la valeur de
$rel par défaut (à savoir false), ou est-ce que c'est juste un oubli ?

01/10/10, davux:

Il semblerait que le fonctionnement de la balise #URL_PAGE ne soit pas
cohérent avec celui de #URL_ARTICLE et ses amis. En effet, il renvoie
des URL absolues.

Y a t'il une raison pour appeler generer_url_public() avec la valeur
de $rel par défaut (à savoir false), ou est-ce que c'est juste un
oubli ?

D'ailleurs, je me dis qu'on pourrait même très bien passer la valeur par
défaut de $rel à true, plutôt que mettre l'appeler avec cette valeur
dans #URL_PAGE.

Les plugins appellent toujours generer_url_public() avec la valeur par
défaut car c'est plus simple (et moins moche que
generer_url_public(machin, '', false, true)), mais je ne vois pas de cas
où ce soit vraiment motivé. Ça fait même que dans plein de cas, les
plugins produisent un mélange d'URLs relatives et absolues suivant si
c'est un squelette de page ou un document statique qui sont appelés. Ce
changement apporterait donc plus de cohérence.

Par ailleurs, la différence d'impact entre mettre une URL absolue ou
relative dans une page est de toute façon très faible, voire nulle, car
le navigateur résoud l'URL relative en remettant le hostname. Dans les
rares cas où on veut explicitement avoir une URL absolue, il est très
simple d'ajouter un appel à |liens_absolus au bon endroit.

Comme c'est un changement de comportement, il faudrait bien sûr
l'introduire dans la future stable, et mentionner le changement.

01/10/10, davux:

D'ailleurs, je me dis qu'on pourrait même très bien passer la valeur
par défaut de $rel à true,

Le comportement de generer_url_public() a changé lors du commit
suivant : http://core.spip.org/trac/spip/changeset/5462

Auparavant, l'URL générée utilisait meta(adresse_site) si celle-ci
existait (donc une URL absolue), et _DIR_RACINE sinon (donc une URL
relative). Ça signifie donc que même si la forme relative n'est qu'un
fallback de la forme absolue, les deux sont viables.

Par ailleurs, avec ce commit, qui introduit l'utilisation de HTTP_HOST
(via la nouvelle fonction url_de_base()) plutôt que meta(adresse_site),
c'est la forme en URL absolue qui devient la forme unique, mais ça
n'est qu'un effet de bord.

Pour ces deux raisons, je pense qu'il est bénin de préférer l'URL
relative. Je le fais (branche de dev uniquement), sauf si quelqu'un a
des infos non-documentées en plus.

Comme dit dans le mail précédent, la raison de ce changement est
qu'il est beaucoup plus facile de passer d'une URL relative à une URL
absolue (avec en bonus le choix de la base grâce à |url_absolue{xxx},
pour les gens qui veulent quand même utiliser l'URL du site par
exemple) que l'inverse.