Etendre le flux RSS a_suivre aux nouveaux objets #2978

Closed
opened 10 years ago by g0uZ · 12 comments
g0uZ commented 10 years ago

Le flux RSS ne semble pas fonctionner avec les URLS de type http://www.monsite/spip.php?page=rss&op=a_suivre&id=1&cle=XYZ alors que la liste en "HTML" affiche bien les éléments en attente de validation.

Peut être le même problème que http://core.spip.org/issues/2963

Le flux RSS ne semble pas fonctionner avec les URLS de type http://www.monsite/spip.php?page=rss&op=a_suivre&id=1&cle=XYZ alors que la liste en "HTML" affiche bien les éléments en attente de validation. Peut être le même problème que http://core.spip.org/issues/2963
Owner

Le flux RSS ne semble pas fonctionner...

Sans plus d'info sur ce que tu veux dire par "ne semble pas fonctionner" ça va pas être facile :p

Testé sur SPIP 3.0.7 SVN [20400] => aucun problème, le flux affiche bien les articles proposés à la publication chez moi.

On ferme ?

> Le flux RSS ne semble pas fonctionner... Sans plus d'info sur ce que tu veux dire par "ne semble pas fonctionner" ça va pas être facile :p Testé sur SPIP 3.0.7 SVN [20400] => aucun problème, le flux affiche bien les articles proposés à la publication chez moi. On ferme ?
Poster

J'ai oublié de préciser que les objets qui sont en attentes de validation chez moi sont des objets éditoriaux perso.

Le comportement observé est le suivant : le flux RSS est OK (syntaxe XML correcte) mais ne contient pas les objets éditoriaux perso qui sont en attente de validation, la liste est simplement vide si aucun objets natifs de spip n'est en attente de validation.

J'ai oublié de préciser que les objets qui sont en attentes de validation chez moi sont des objets éditoriaux perso. Le comportement observé est le suivant : le flux RSS est OK (syntaxe XML correcte) mais ne contient pas les objets éditoriaux perso qui sont en attente de validation, la liste est simplement vide si aucun objets natifs de spip n'est en attente de validation.
Owner

Ha ben oui, l'info est utile :p

En fait le squelette de ce flux n'est pas du tout "multi-objets", il ne gère pour l'instant que les articles, les brèves et les éléments de syndiquation :

http://core.spip.org/projects/spip/repository/entry/spip/prive/rss/a_suivre.html

Il faut adapter le squelette en conséquence, comme dans #2963

++

Ha ben oui, l'info est utile :p En fait le squelette de ce flux n'est pas du tout "multi-objets", il ne gère pour l'instant que les articles, les brèves et les éléments de syndiquation : http://core.spip.org/projects/spip/repository/entry/spip/prive/rss/a_suivre.html Il faut adapter le squelette en conséquence, comme dans #2963 ++
Owner

Et vu que Suske était motivé sur #2963, je lui assigne le ticket :D
Assigné à Suske

Et vu que Suske était motivé sur #2963, je lui assigne le ticket :D **Assigné à Suske**
Owner

Je ne sais pas si le flux natif a vocation a être étendu automatiquement, ou juste personnalisable... Peut-être juste ajouter un pipeline dans le flux RSS pour permettre aux nouveaux objets de s'y ajouter ?
Version cible mise à 3.1

Je ne sais pas si le flux natif a vocation a être étendu automatiquement, ou juste personnalisable... Peut-être juste ajouter un pipeline dans le flux RSS pour permettre aux nouveaux objets de s'y ajouter ? **Version cible mise à 3.1**
Owner

Salut,

Le point de départ, c'est "on a pas les nouveaux objets" (présents sur exec=accueil). Ce rss là il doit juste attirer l'attention du responsable de publication sur le fait que qq chose est prêt: articles, breves, sites, chats, objets à valider, ... (statut choisi par les auteurs).
Donc, en maintenance ou en version intermédiaire, je propose que si un objet suppl. a la même logique (prépa/prop/publie) que les articles, on tente de le joindre dans ce fil.

Je veux pas faire rentrer le monde entier dans ce fil RSS, il y en a déjà d'autres (forums...), juste y faire rentrer les chats et autres objets codés selon le principe prop par un rédac/publie par un admin, seulement les objets qui passent par une validation.

C'est dans cette idée que j'ai fait ces boucles (avec l'aide de l'équipe spéciale, merci à elle): http://spip.pastebin.fr/27232

Cela se base sur un critère "prop" et une détection à base de [statut_textes_instituer], pour exclure les objets comme les documents, qui ont un statut "prop" mais ne sont pas "proposés" à publication (s'il y a 300 documents en réserve sur mon site, j'ai pas envie de les avoir sur ce fil et je n'ai pas de moyen de les faire sortir). Si on veut un rss sur les documents, on le met dans médiathèque, comme celui des forums.

Donc ici, si l'objet a divers statuts sélectionnables par clic, dont un "prop", on affiche les lignes qui ont ce statut là, avec une date, le titre d'objet et le titre spécifique... Donc l'idée c'est un lien, une date, une courte description si possible. Cela fait régression par rapport aux objets historiques qui diffusent des données "complètes" mais par rapport à l'extensibilité "nouvelle" de SPIP, que ce soit automagique me parait franchement intéressant pour ces cas précis.

Pour le reste, et/ou pour ne pas renoncer aux infos diffusées jusqu'ici, on peut vouloir personnaliser par un pipeline, cela ne me parait pas contradictoire. Si un objet utilise le pipeline on l'exclus de ceci... Pour SPIP4, tout ça mérite peut-être une réflexion, mais bon, c'est autre chose ça ;-)

`Guillaume: tu peux tester le fichier joint pour voir si dans ton cas, ce système fonctionnerait ? (à placer ds prive/rss/a_suivre.html)

++

Salut, Le point de départ, c'est "on a pas les nouveaux objets" (présents sur exec=accueil). Ce rss là il doit juste attirer l'attention du responsable de publication sur le fait que qq chose est prêt: articles, breves, sites, chats, objets à valider, ... (statut choisi par les auteurs). Donc, en maintenance ou en version intermédiaire, je propose que si un objet suppl. a la même logique (prépa/prop/publie) que les articles, on tente de le joindre dans ce fil. Je veux pas faire rentrer le monde entier dans ce fil RSS, il y en a déjà d'autres (forums...), juste y faire rentrer les chats et autres objets codés selon le principe prop par un rédac/publie par un admin, seulement les objets qui passent par une validation. C'est dans cette idée que j'ai fait ces boucles (avec l'aide de l'équipe spéciale, merci à elle): http://spip.pastebin.fr/27232 Cela se base sur un critère "prop" et une détection à base de [statut_textes_instituer], pour exclure les objets comme les documents, qui ont un statut "prop" mais ne sont pas "proposés" à publication (s'il y a 300 documents en réserve sur mon site, j'ai pas envie de les avoir sur ce fil et je n'ai pas de moyen de les faire sortir). Si on veut un rss sur les documents, on le met dans médiathèque, comme celui des forums. Donc ici, si l'objet a divers statuts sélectionnables par clic, dont un "prop", on affiche les lignes qui ont ce statut là, avec une date, le titre d'objet et le titre spécifique... Donc l'idée c'est un lien, une date, une courte description si possible. Cela fait régression par rapport aux objets historiques qui diffusent des données "complètes" mais par rapport à l'extensibilité "nouvelle" de SPIP, que ce soit automagique me parait franchement intéressant pour ces cas précis. Pour le reste, et/ou pour ne pas renoncer aux infos diffusées jusqu'ici, on peut vouloir personnaliser par un pipeline, cela ne me parait pas contradictoire. Si un objet utilise le pipeline on l'exclus de ceci... Pour SPIP4, tout ça mérite peut-être une réflexion, mais bon, c'est autre chose ça ;-) `Guillaume: tu peux tester le fichier joint pour voir si dans ton cas, ce système fonctionnerait ? (à placer ds prive/rss/a_suivre.html) ++
Owner

En fait, c'est "simple" (?) ^^: dans le core, il faut un code pour les ARTICLES, un pipeline (pour les brèves et les sites déjà), puis un code générique pour les autres objets à statut éditable 'prop'/'publie'

Oui ?

En fait, c'est "simple" (?) ^^: dans le core, il faut un code pour les ARTICLES, un pipeline (pour les brèves et les sites déjà), puis un code générique pour les autres objets à statut éditable 'prop'/'publie' Oui ?
Owner

Oui.

Techniquement on pourrait le faire avec un simple inclure, dans le style (en bouclant sur la liste des objets de l'API de déclaration) :

[(#CHEMIN{prive/rss/a_suivre-#OBJET}|oui)
[(#INCLURE{fond=prive/rss/a_suivre-#OBJET,env})]
]

C'est peut être moins bon qu'un pipeline côté perfs, mais ça évite aux nouveaux objets une déclaration d'utilisation de pipeline...

Oui. Techniquement on pourrait le faire avec un simple inclure, dans le style (en bouclant sur la liste des objets de l'API de déclaration) : <pre> [(#CHEMIN{prive/rss/a_suivre-#OBJET}|oui) [(#INCLURE{fond=prive/rss/a_suivre-#OBJET,env})] ] </pre> C'est peut être moins bon qu'un pipeline côté perfs, mais ça évite aux nouveaux objets une déclaration d'utilisation de pipeline...
Owner

b_b : cette solution est un bon compromis. Il faut utiliser |trouver_fond` au lieu de chemin.

`Suske : non pour une usine à gaz automagique, d'autant plus que ça a toutes les chances d'intégrer des objets qui n'ont rien à y faire et d'en oublier d'autres qui devraient, et ça rendra encore plus difficile l'intervention (et DATA pour faire du SQL n'est pas portable, il ne faut jamais l'utiliser dans le core)

`b_b : cette solution est un bon compromis. Il faut utiliser `|trouver_fond` au lieu de chemin. `Suske : non pour une usine à gaz automagique, d'autant plus que ça a toutes les chances d'intégrer des objets qui n'ont rien à y faire et d'en oublier d'autres qui devraient, et ça rendra encore plus difficile l'intervention (et DATA pour faire du SQL n'est pas portable, il ne faut *jamais* l'utiliser dans le core)
b_b commented 9 years ago
Owner

Assigné à b_b

**Assigné à b_b**
b_b commented 9 years ago
Owner

Suske est chaud comme la braise, je lui recolle le ticket :p
Assigné à Suske

Suske est chaud comme la braise, je lui recolle le ticket :p **Assigné à Suske**
Owner
Voir aussi r21717 et http://zone.spip.org/trac/spip-zone/changeset/85617 et http://zone.spip.org/trac/spip-zone/changeset/85618 **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.