Cette fois j'hésite pour les coupables qui buggent le flux xml de la zone, à priori c'est sur un plugin xml, ou theme.xml modifié aujourd'hui ou hier, peut etre
- "http://zone.spip.org/trac/spip-zone/changeset/13682" ?
- ou ... ?
Je rappelle qu'il ne s'agit pas ici d'embeter le monde pour le plaisir, mais ce flux est la pointe émergée d'un ensemble qui devrait (espérons le, toggg nous manque aussi sur ce coup la) faciliter l'accès aux plugins et à leur mises à jour depuis la Zone. A court terme il doit générer une liste à jour sur SPIP-Contrib. En attendant d'améliorer la chose, ce flux xml qui récupère les contenus de tous les plugins.xml et theme.xml de la zone, dépend de la bonne rédaction xml de chacun d'entre eux, cf. "http://www.spip-contrib.net/refxml2rss". Si nous laissons accumuler les non conformités xml cela deviendra de plus en plus pénible à reprendre.
Merci d'avance à tous les rédacteurs d'y prêter attention.
Si quelqu'un à des liens pour une bonne syntaxe xml (pour usage rédaction plugin.xml), je suis preneur pour pouvoir les coller quelque part
Le 20 juil. 07, à 23:48, nicolasriq@free.fr a écrit :
Cette fois j'hésite pour les coupables qui buggent le flux xml de la
zone, à priori c'est sur un plugin xml, ou theme.xml modifié
aujourd'hui ou hier, peut etre
- "Connexion · GitLab; ?
- ou ... ?
Je rappelle qu'il ne s'agit pas ici d'embeter le monde pour le plaisir,
mais ce flux est la pointe émergée d'un ensemble qui devrait (espérons
le, toggg nous manque aussi sur ce coup la) faciliter l'accès aux
plugins et à leur mises à jour depuis la Zone. A court terme il doit
générer une liste à jour sur SPIP-Contrib. En attendant d'améliorer la
chose, ce flux xml qui récupère les contenus de tous les plugins.xml et
theme.xml de la zone, dépend de la bonne rédaction xml de chacun
d'entre eux, cf. "http://www.spip-contrib.net/refxml2rss"\. Si nous
laissons accumuler les non conformités xml cela deviendra de plus en
plus pénible à reprendre.
Merci d'avance à tous les rédacteurs d'y prêter attention.
Si quelqu'un à des liens pour une bonne syntaxe xml (pour usage
rédaction plugin.xml), je suis preneur pour pouvoir les coller quelque
part
je m'excuse d'insister, mais c'est toujours cassé, et je ne sais pas résoudre... si une bonne âme pouvait jeter un oeil merci d'avance.
pour cy_altern ou N_K, ou qui veut ... y'a t-il un moyen plus efficace de repérer l'origine de la casse qu'actuellement ? Les indications données comme ici "http://files.spip.org/spip-zone/ref.rss.log.txt" sont un peu cryptiques si l'on a pas accès au code associé ; exemple (extrait) :
******************************
-:15610: parser error : Opening and ending tag mismatch: multi line 15610 and code
onctionnement est basé sur l'utilisation des balises <code><multi></code>
^
-:15615: parser error : Opening and ending tag mismatch: code line 15610 and description
</description>
^
-:15640: parser error : Opening and ending tag mismatch: description line 15602 and plugin
</plugin>
^
-:15655: parser error : Opening and ending tag mismatch: plugin line 15588 and zone_elt
</zone_elt>
^
-:15790: parser error : xmlParseEntityRef: no name
JP, Amaury & Fred
^
-:18939: parser error : Opening and ending tag mismatch: zone_elt line 15587 and zone
</zone>
^
-:18940: parser error : Premature end of data in tag zone line 3
******************************
> Merci d'avance à tous les rédacteurs d'y prêter attention.
Il y a un hiatus ans la conception de ce plugin.xml, puisque le
contenu est censé être du xml tout en permettant de coller des
raccourcis SPIP (qui ne sont pas forcément xml, exemple
<code><multi></code> ) ; tant qu'on n'aura pas résolu ça on aura ce
problème.
pour cy_altern ou N_K, ou qui veut ... y'a t-il un moyen plus efficace
de repérer l'origine de la casse qu'actuellement ? Les indications
données comme ici "http://files.spip.org/spip-zone/ref.rss.log.txt"
sont un peu cryptiques si l'on a pas accès au code associé ; exemple
Une piste serait de vérifier chaque plugin.xml ou theme.xml avant de
les mettre tous ensemble dans le fichier final ; comme ça un fichier
mal formé ne tuerait pas l'ensemble du RSS. Et c'est crucial pour la
nouvelle facililté de chargement des plugins à partir d'une liste.
Une piste serait de vérifier chaque plugin.xml ou theme.xml avant de
les mettre tous ensemble dans le fichier final ;
Une solution consisterait à passer les fichiers /_plugins/*/plugin.xml
dans un valideur, et refuser le commit s'ils ne passent pas.
Ça peut être mis dans un "pre-commit hook", d'après ce que je viens de
voir dans la doc, mais de là à le coder ...
J'vais potasser le sujet vite fait mais j'vous promet rien ...
go go go et depeche toi sinon tu auras pas ton tshirt
Le 23 juil. 07 à 21:33, pif a écrit :
On Sun, 2007-07-22 at 17:19 +0200, Fil wrote:
Une piste serait de vérifier chaque plugin.xml ou theme.xml avant de
les mettre tous ensemble dans le fichier final ;
Une solution consisterait à passer les fichiers /_plugins/*/plugin.xml
dans un valideur, et refuser le commit s'ils ne passent pas.
Ça peut être mis dans un "pre-commit hook", d'après ce que je viens de
voir dans la doc, mais de là à le coder ...
J'vais potasser le sujet vite fait mais j'vous promet rien ...
> > Merci d'avance à tous les rédacteurs d'y prêter attention.
Il y a un hiatus ans la conception de ce plugin.xml, puisque le
contenu est censé être du xml tout en permettant de coller des
raccourcis SPIP (qui ne sont pas forcément xml, exemple
<code><multi></code> ) ; tant qu'on n'aura pas résolu ça on aura ce
problème.
Y'a effectivement un couac à ce niveau.
Même en intégrant la dtd html dans une mini DTD plugin, on n'arrive pas
à valider les <code>, <multi> et autres.
Soit on dit "c'est html" ou "c'est raccourcis spip" point, soit ça ne
sera jamais du xml.
On peut très bien considérer que c'est du spip et permettre des blocs
<html> dedans. le seul défaut, c'est que <html> c'est déjà pris dans la
dtd html, ça facilite rien ...
une dtd plugin existe déjà dans _dev_/paquets/dtd/common.dtd, mais
beaucoup de fichiers ne la respectent pas.
Une piste serait de vérifier chaque plugin.xml ou theme.xml avant de
les mettre tous ensemble dans le fichier final
voir r13774 : le test au commit marche, mais le xmllint doit être fait
avec les bons arguments.
> <code><multi></code> ) ; tant qu'on n'aura pas résolu ça on aura ce
> problème.
Y'a effectivement un couac à ce niveau.
Même en intégrant la dtd html dans une mini DTD plugin, on n'arrive pas
à valider les <code>, <multi> et autres.
Soit on dit "c'est html" ou "c'est raccourcis spip" point, soit ça ne
sera jamais du xml.
<code><multi></code> ) ; tant qu'on n'aura pas résolu ça on aura ce
problème.
Y'a effectivement un couac à ce niveau.
Même en intégrant la dtd html dans une mini DTD plugin, on n'arrive pas
à valider les <code>, <multi> et autres.
Soit on dit "c'est html" ou "c'est raccourcis spip" point, soit ça ne
sera jamais du xml.
> > <code><multi></code> ) ; tant qu'on n'aura pas résolu ça on aura ce
> > problème.
> Y'a effectivement un couac à ce niveau.
> Même en intégrant la dtd html dans une mini DTD plugin, on n'arrive pas
> à valider les <code>, <multi> et autres.
> Soit on dit "c'est html" ou "c'est raccourcis spip" point, soit ça ne
> sera jamais du xml.
On devrait utiliser CDATA, non ?
cdata interdit des tags imbriqués a moins de les collers dans les blocs
<![CDATA[ ... ]]> ceux qui est particulièrement illisible
* Fil tapotait, le 23/07/2007 23:18:
>>> <code><multi></code> ) ; tant qu'on n'aura pas résolu ça on aura ce
>>> problème.
>> Y'a effectivement un couac à ce niveau.
>> Même en intégrant la dtd html dans une mini DTD plugin, on n'arrive pas
>> à valider les <code>, <multi> et autres.
>> Soit on dit "c'est html" ou "c'est raccourcis spip" point, soit ça ne
>> sera jamais du xml.
>
> On devrait utiliser CDATA, non ?
+1
Heu .. vous parliez de déclaration #PCDATA dans la DTD, ou de blocs
<
