Bug dans l'envoi des nouveautés signalé dans spip-user:
http://comments.gmane.org/gmane.comp.web.spip.user/139156
il est dû au fait qu'auparavant toutes les actions étaient exécutées à la racine,
et donc une action calculant un squelette traitait les #URL_xxx comme référençant l'espace public.
Avec le laxisme d'accepter les actions à tous les étages, ça fabrique les Urls de l'espace privé.
Solution ?
Committo,Ergo:Sum
J'ai mentionné le meme probleme avec les squelettes d'interface qui produisent une url privée pour #URL_ARTICLE, et on a convenu ensemble que les #URL_xx ne produiraient que des urls publiques 
Mais je n'ai pas encore corrigé.
Cédric
peut-être comme sur les patrons de spip-liste :
[(#REM|generer_url_public{page=article&id_article=#ID_ARTICLE})]
pierre
Oui, mais la question qui se pose est la suivante: on se retrouve contraint à réduire une fonctionnalité de ces balises, au motif qu'on a élargit un cas d'utilisation d'autre chose, mais est-ce que le bilan global est positif ? Et la question est peut-être même encore plus grave car rien ne garantit que cet élargissement ne provoque pas encore d'autres bugs qui va nous contraindre à encore d'autres restrictions de fonctionnalité.
Le pb de fond est que cet élargissement introduit une ambiguité (suis-je à la racin ou non), et une telle introduction n'est jamais bonne par principe: ça facilite le codage dans certains cas, mais on ne peut plus rien affirmer sur le code écrit, ici par exemple que le squelette d'envoi de nouveautés sera exécuté dans le bon contexte. Pour moi ce serait obéir au principe de précaution que de renoncer à ça.
Committo,Ergo:Sum
oui mais ce n'est pas la question: on ne va pas demander à tout ceux qui ont écrit un squelette de nouveautés de les réécrire.
Committo,Ergo:Sum
il est dû au fait qu'auparavant toutes les actions étaient exécutées à la racine,
et donc une action calculant un squelette traitait les #URL_xxx comme référençant l'espace public.J'ai mentionné le meme probleme avec les squelettes d'interface qui produisent une url privée pour #URL_ARTICLE, et on a convenu ensemble que les #URL_xx ne produiraient que des urls publiques
Oui, mais la question qui se pose est la suivante: on se retrouve contraint à réduire une fonctionnalité de ces balises, au motif qu'on a élargit un cas d'utilisation d'autre chose, mais est-ce que le bilan global est positif ?
On ne réduit pas la fonctionnalité de la balise, on la précise, étant entendu que jusqu'il y a encore peu les squelettes étaient du domaine du site public exclusivement et qu'à ce titre le comportement de ces balises n'avait pas été défini en cas d'évaluation depuis ecrire/
Dans ce contexte il faut fixer la signification de ces balises qui a de plus été modifiée au changement des formalismes d'url (les balises ont eu produit des url publiques depuis l'espace privé, mais ce n'est plus le cas).
Et la question est peut-être même encore plus grave car rien ne garantit que cet élargissement ne provoque pas encore d'autres bugs qui va nous contraindre à encore d'autres restrictions de fonctionnalité.
Le pb de fond est que cet élargissement introduit une ambiguité (suis-je à la racin ou non), et une telle introduction n'est jamais bonne par principe: ça facilite le codage dans certains cas, mais on ne peut plus rien affirmer sur le code écrit, ici par exemple que le squelette d'envoi de nouveautés sera exécuté dans le bon contexte. Pour moi ce serait obéir au principe de précaution que de renoncer à ça.
Justement, les modifications sur les actions ont eu pour objectif premier et essentiel de pouvoir écrire des squelettes qui fonctionnent à l'identique si il sont executés depuis ecrire/ ou depuis la partie publique. Les redirections post action posaient à ce titre tout un tas de problème.
La précision du comportement des #URL_xx vise au même résultat.
Je fais toutes les nouvelles interfaces en squelette depuis un petit moment, et je n'ai pas rencontré d'autres points bloquants à ce jour.
C'est un résultat très important, car cela signifie que toutes les nouvelles interfaces en squelette pourront être utilisées depuis l'espace publique sans aucune modification, ce qui nous rapproche toujours plus d'une dé-particularisation de ecrire/
Cédric
Pierre Fiches wrote:
peut-être comme sur les patrons de spip-liste :
[(#REM|generer_url_public{page=article&id_article=#ID_ARTICLE})]
Ah ben je la connaissais pas celle là !
BoOz
peut-être comme sur les patrons de spip-liste :
[(#REM|generer_url_public{page=article&id_article=#ID_ARTICLE})]
Non car sur un site en urls propres on veut l'url propre, et pas un URL ad hoc
-- Fil
oui.
D'ailleurs perso avec propre2 j'utilise plutôt ça
[(#REM|generer_url_public{article#ID_ARTICLE})]
Qui a l'avantage de fournir l'url propre à l'arrivée mais ça reste du dépannage.
pierre
Cette histoire était tout de même mentalement tordue, car #URL_ARTICLE renvoyait toujours l'url publique pour une base distante, et il n'y avait que sur la base locale que l'url était celle de l'espace privé lorsque le squelette était évalué depuis ecrire/
http://trac.rezo.net/trac/spip/changeset/13689
corrige donc cela, et j'ai pris le parti que #URL_ARTICLE référence toujours l'url publique relative à la racine du site, donc produit un résultat indépendant de l'endroit où est évalué le squelette.
Consécutivement, si on veut afficher un lien vers l'url publique du site depuis l'espace privé, il faut écrire
[#EVAL{_DIR_RACINE}(#URL_ARTICLE)]
qui marchera quel que soit l'endroit où est évalué le squelette.
Cédric
Cette histoire était tout de même mentalement tordue, car #URL_ARTICLE renvoyait toujours l'url publique pour une base distante, et il n'y avait que sur la base locale que l'url était celle de l'espace privé lorsque le squelette était évalué depuis ecrire/
Mais ça n'a rien de tordu: l'espace privé de la base locale n'est pas l'espace privé d'une base distante, c'est quoi ce faux argument
Consécutivement, si on veut afficher un lien vers l'url publique du site depuis l'espace privé, il faut écrire
[#EVAL{_DIR_RACINE}(#URL_ARTICLE)]
je comprends rien à cette formulation: "#URL_ARTICLE" donnera un lien vers l'URL du SITE ? quel rapport ? et pourquoi à nouveau "publique" alors que tu viens de dire que c'est le comportement par défaut ?
Committo,Ergo:Sum
