Suite à un message de Fil, je vous propose en attachement un squelette
pour backend RSS 1.0. Les backend obtenus passent le validateur RSS1.0
donc je ne pense pas avoir complétement merdé...
Malheureusement, SPIP n'arrive pas à syndiquer un tel backend. C'est
sans doute dû à son "parseur" de backend. J'ai mis des guillemets vu que
c'est un parseur de XML codé en quelques lignes PHP pur, vous voyez le
tableau (mais c'est le prix à payer pour que SPIP tourne sans module XML
pour PHP, et je suis 100% d'accord avec ça).
Le problème est qu'un fichier backend RSS1.0 contient une liste d'items
dans un <items>...</items> puis chaque item est décrit dans un
<item>...</item> qui lui est propre.
Mon génial patch que je vais faire brevetter rapidement tellement il est
superbe est de flinguer la liste <items>.*</items> qui ne nous sert à
rien. Enfin disons que vu le code du parseur, je me suis dit qu'au point
où on en était, c'était encore la décision la plus simple. Cela permet
de rendre le backend RSS 1.0 quasi compatible avec RSS 0.9x, ce qui nous
arrange bien.
J'ai trouvé deux endroits à modifier (désolé, le patch sera surement
coupé-bousillé par mon mailer) :
où on en était, c'était encore la décision la plus simple. Cela permet
de rendre le backend RSS 1.0 quasi compatible avec RSS 0.9x, ce qui nous
arrange bien.
Si je comprends bien, le backend que tu proposes ne sera pas lu par les SPIP
en version 1.4.2 ou précédentes... ? Problème non ? Rendre spip compatible
avec les standards OK, mais il doit rester comatible avec lui-même.
Ce qu'on peut faire, au départ, c'est de mettre la date de publication dans
le backend par défaut, d'enlever les tags des descriptifs/titres etc., et de
rendre le aprseur plus intelligent. Mais il faut tout de même éviter de
faire canner les anciens parseurs.
Le problème est qu'un fichier backend RSS1.0 contient une liste d'items
dans un <items>...</items> puis chaque item est décrit dans un
<item>...</item> qui lui est propre.
Si je comprends bien, il suffit d'ignorer <items quand on cherche <item :
> où on en était, c'était encore la décision la plus simple. Cela permet
> de rendre le backend RSS 1.0 quasi compatible avec RSS 0.9x, ce qui nous
> arrange bien.
Si je comprends bien, le backend que tu proposes ne sera pas lu par les SPIP
en version 1.4.2 ou précédentes... ? Problème non ? Rendre spip compatible
avec les standards OK, mais il doit rester comatible avec lui-même.
Les RSS1.0 (ceux qui passent la validation) doivent avoir ces <items>.
Comme les anciennes versions de SPIP ne pigent pas de <items> et le
confondent avec un <item>, on est foutus. SPIP 1.4.2 et précédents ne
sont donc pas compatibles avec RSS 1.0.
C'est pas super grâve
Si je comprends bien, il suffit d'ignorer <items quand on cherche
<item :
remplacer
Ca marche top moumoute. Je voulais faire comme ça mais n'étant pas accro
à PHP, je ne connaissais pas ce coup-là.
Ceci dit, ça reste un peu de la bidouille. On pourrait plus joliment
passer par un parseur 1.0 spécifique quand on détecte la chaine
xmlns="http://purl.org/rss/1.0/" dans $le_retour, afin de ne pas
mélanger les deux parseurs.
Cette semaine j'aurais trop de boulot pour m'occuper de ça, désolé
PS: attention, ton CVS n'est apparemment pas à jour, car
syndic_edit.php3 ne devrait plus s'y trouver
Ma bidouille était pour 1.4.2, je ne bosse pas sur le CVS actuellement.
Mille excuses.
Ben non, suffit de faire deux backends, un backend.php3, et un
backend-rss.php3 en rss1.0
Ou encore, passer la version de rss en commande, si on fait un
backend.php3?rss=1.0 on sort un vrai rss 1.0
Pour ça y'a aucun problème, mais ce que je voulais dire c'est que SPIP
version<=1.4.2 ne comprendra pas le backend-rss.php3 d'un autre site
SPIP.
C'est typiquement le genre de problèmes que l'on a lorsqu'on ne colle pas scrupuleusement aux STANDARDS : on se retrouve avec 2 versions d'un meme truc.
