Re: ! A tester : SPIP 1.7.2 pr1

Fil wrote:
> Salut,
> 
> vous pouvez télécharger SPIP 1.7.2pr1, qui devrait déboucher très rapidement
> (après la traduction des dernières chaînes en attente) sur la version 1.7.2
> "officielle".
> 

J'avais noté un problème sur la version 1.7.1 à propos de 
"filtre_backend" et qui n'a apparament pas été relevé...

Lorsqu'un article contient un " & " dans une phrase (l'aile & la cuisse) 
il n'est pas transformé, ce qui plante en général les lecteurs rss.

A ce propos, quelqu'un avait noté aussi le problème du "oe" qui ne passe 
pas bien, mais je ne l'ai pas expérimenté.

M'enfin...

Re: Boucles forums : rapport d'utilisation

BoOz wrote:
> 
> Pour aller plus loin avec des boucles (FORUMS) :
> (attention : il ne s'agit pas dans ce qui suit des messages postés à la
> suite d'une rubrique, mais bien à la suite d'un article, ce que je raconte
> induit peut etre des problèmes avec les messages postés directement dans les
> rubriques)
> 
> 
> Dans le cadre d'un forum *isolé* du reste du site en utilisant les articles
> d'un *secteur* donné :
> Voir par exemple : http://bloog.net/rubrique.php3?id_rubrique=95
 >
> 1) Il me parait utile d'étendre la possibilité de limiter le tri d'une
> boucle forums à un *secteur* voire à une rubrique pour pouvoir afficher par
> exemple :
> 
> - les derniers messages postés à la suite d'un *article de ce secteur*
> <BOUCLE_nouveaux(FORUMS){id_secteur=5}{par date}{inverse}{0,10}>

Justement sur ce point la doc semble erronée, elle donne le critère 
"id_secteur" comme sélection possible :
http://www.spip.net/fr_article908.html

Or ca ne fonctionne effectivement pas !

Re: Re: ! A tester : SPIP 1.7.2 pr1

> J'avais noté un problème sur la version 1.7.1 à propos de 
> "filtre_backend" et qui n'a apparament pas été relevé...
> 
> Lorsqu'un article contient un " & " dans une phrase (l'aile & la cuisse) 
> il n'est pas transformé, ce qui plante en général les lecteurs rss.

Oui mais ton correctif n'était pas vraiment au point. Si je mets 2&3 par
exemple, ce n'est pas une entité html, il faut donc l'échapper. Du coup
c'est un peu plus subtil à gérer que de repérer '& '.

> A ce propos, quelqu'un avait noté aussi le problème du "oe" qui ne passe 
> pas bien, mais je ne l'ai pas expérimenté.

C'est un caractère problématique car il n'existe pas en iso-8859-1
(cf. http://www.uzine.net/article1785.html). En utf-8, normalement c'est
nickel. Il y a peut-être quelque chose à faire pour le passer en unicode, du
coup.

> M'enfin...

Il n'est pas trop tard pour régler ce genre de détails, hein.

-- Fil

Re: Re: ! A tester : SPIP 1.7.2 pr1

Le Sat, 1 May 2004 12:05:01 +0200, Fil <fil <at> rezo.net> a écrit:

>> J'avais noté un problème sur la version 1.7.1 à propos de
>> "filtre_backend" et qui n'a apparament pas été relevé...
>>
>> Lorsqu'un article contient un " & " dans une phrase (l'aile & la cuisse)
>> il n'est pas transformé, ce qui plante en général les lecteurs rss.
>
> Oui mais ton correctif n'était pas vraiment au point. Si je mets 2&3 par
> exemple, ce n'est pas une entité html, il faut donc l'échapper. Du coup
> c'est un peu plus subtil à gérer que de repérer '& '.

Ca me turlupine aussi, et c'est assez chiant, ce truc...

- trouver une règle "simple" pour transformer les "&" en "&amp;", sans  
toucher à ceux qui, justement, débutent des caractères spéciaux.

- je lis qu'en XML (et donc tout ce qui en dérive, j'ai eu le problème  
avec le format Wap), il faut remplacer les "&" dans les URI aussi. Ce qui  
nous refait une reprise assez pénible sur une tripotée d'automatismes de  
SPIP, par exemple
      "article.php3?id_article=1&recalcul=oui"
devrait devenir:
      "article.php3?id_article=1&amp;recalcul=oui"
(pour les visiteurs du site, ça se pose notamment pour les adresses des  
forums).
Et au passage tester sur de "vieux" butineurs qu'un site public reste  
accessible avec ce genre d'URI.

C'est assez marrant, parce que ça renvoie aux incohérences des normes  

$multilang=false pas pris en compte?

J'ai l'impression qu'un réglage à:
$multilang=false
dans spip_login ne fait pas disparaître le menu déroulant.

A*

J'ai l'impression qu'un réglage à:
$multilang=false
dans spip_login ne fait pas disparaître le menu déroulant.

A*

Re: xml

[...]
> - trouver une règle "simple" pour transformer les "&" en "&", sans  
> toucher à ceux qui, justement, débutent des caractères spéciaux.

J'en ai un peu marre de voir ces discussions sans fin sur un bug qui
avait été corrigé il y a des mois.

La méthode est simple : le filtre entites_html() est intégré à
texte_backend() (il l'est toujours mais il y a une scorie derrière).
Cela donne par exemple :

- un & deux -> un & deux
- é    -> é
- »    -> »

C'est *exactement* ce qu'il faut faire pour imbriquer du HTML dans du
XML valide. Cela marche dans tous les lecteurs RSS et CMS dignes de ce
nom, y compris dans SPIP. Faites des tests si vous n'êtes pas convaincus
(sous Linux il y a Straw et Liferea).

Le problème actuel dans texte_backend() est la ligne suivante, qui doit
être virée puisqu'elle produit volontairement du XML invalide :

	$texte = str_replace("&", "&", $texte);

Voilà, il y a une ligne à supprimer.

> - je lis qu'en XML (et donc tout ce qui en dérive, j'ai eu le
problème  

Re: $multilang=false pas pris en compte?

En effet, je n'avais pas prévu ça, mais oui, on pourrait le faire.

> J'ai l'impression qu'un réglage à:
> $multilang=false
> dans spip_login ne fait pas disparaître le menu déroulant.

-- Fil

à tester : comment passer son site en utf-8

Salut,

je viens de mettre sur spip-contrib une documentation et un outil
permettant de convertir son site du jeu de caractères iso-8859-1 vers utf-8.

A tester, donc :
http://www.spip-contrib.net/ecrire/articles.php3?id_article=503

Je pense qu'à terme SPIP pourrait ne plus gérer d'autres jeux de caractères,
en interne du moins, que l'utf-8.

-- Fil

Re: $multilang=false pas pris en compte?

En fait, le seul soucis, c'est de pouvoir ne pas avoir le menu déroulant  
dans les sites qui ont fait leur propre interface de connexion, et qui ne  
veulent pas que ce nouveau menu apparaisse et perturbe leur mise en page.  
Parce que sinon, au niveau de spip_login lui-même, introduire cette modif  
n'est pas très grave. Le seul "hic", dans ce cas, c'est d'avoir une  
variable $multilang qui ne sert à rien )

A*

Le Sat, 1 May 2004 15:28:43 +0200, Fil <fil <at> rezo.net> a écrit:

>
> En effet, je n'avais pas prévu ça, mais oui, on pourrait le faire.
>
>> J'ai l'impression qu'un réglage à:
>> $multilang=false
>> dans spip_login ne fait pas disparaître le menu déroulant.
>
> -- Fil
>

--

-- 
Le Scarabée http://www.scarabee.com
uZine http://www.uzine.net
SPIP http://www.spip.net

En fait, le seul soucis, c'est de pouvoir ne pas avoir le menu déroulant  

Re: $multilang=false pas pris en compte?

> En fait, le seul soucis, c'est de pouvoir ne pas avoir le menu déroulant  
> dans les sites qui ont fait leur propre interface de connexion, et qui ne  
> veulent pas que ce nouveau menu apparaisse et perturbe leur mise en page.  

Le menu est appelé par #FORMULAIRE_LANG_ECRIRE, pas par #FORMULAIRE_LOGIN,
donc ça résoud ton problème.

> Parce que sinon, au niveau de spip_login lui-même, introduire cette modif  
> n'est pas très grave. Le seul "hic", dans ce cas, c'est d'avoir une  
> variable $multilang qui ne sert à rien )

Mais je crois quand même que c'est mieux de désactiver le menu quand
$multilang==false, indépendamment de la présence ou pas de
#FORMULAIRE_LANG(_ECRIRE) - sinon on aura des incohérences, menus de langue
qui ne changent rien à la page.

-- Fil