Je suis surpris (mais pas forcément désagréablement) de cet envoi sur la branche 2, laquelle était censée ne recevoir que des corrections de bug. Est-ce une fausse manip' ou décide-t-on effectivement de moderniser cet aspect de SPIP pour la sortie de la 2.0 ? Si oui, et je serais plutôt pour, il faudrait aller jusqu'au bout et supprimer la pesante pseudo action action/redirect.php dont l'existence, sauf erreur, n'est due qu'à la vétusté des types_urls actuels.
Chose en partie liée: je termine en ce moment la mise en squelette de l'autre pseudo action action/rss.php, ce qui permettrait de rationnaliser ce répertoire action qui actuellement est assez incohérent. Les deux mises en squelette pas encore finies sont celles appliquant au final la fonction PHP "trier_par_date" sur les résultats de plusieurs Select SQL. Cette opération n'est faisable qu'avec un squelette contenant du PHP (d'ailleurs c'est pas faisable en SQL pur non plus). Mais il apparaît que l'agrégateur RSS de Safari n'a pas besoin de ce tri, il réordonne comme il faut. Savez-vous si c'est effectivement superflu pour tous les agrégateurs ?
Je suis surpris (mais pas forcément désagréablement) de cet envoi sur la
branche 2, laquelle était censée ne recevoir que des corrections de bug.
Est-ce une fausse manip' ou décide-t-on effectivement de moderniser cet
aspect de SPIP pour la sortie de la 2.0 ? Si oui, et je serais plutôt pour,
il faudrait aller jusqu'au bout et supprimer la pesante pseudo action
action/redirect.php dont l'existence, sauf erreur, n'est due qu'à la vétusté
des types_urls actuels.
C'est une erreur, mais on peut aller au bout ; attends une minute tout
de même, je suis en train de gérer l'internationalisation des chaines,
en ce moment : je me suis remis sur la branche dev.
Pour propres-qs je n'ai pas compris pourquoi elle ne marche plus (à
part le fait que le tiret est interdit dans les noms de fonctions ??).
Chose en partie liée: je termine en ce moment la mise en squelette de
l'autre pseudo action action/rss.php, ce qui permettrait de rationnaliser ce
répertoire action qui actuellement est assez incohérent. Les deux mises en
squelette pas encore finies sont celles appliquant au final la fonction PHP
"trier_par_date" sur les résultats de plusieurs Select SQL. Cette opération
n'est faisable qu'avec un squelette contenant du PHP (d'ailleurs c'est pas
faisable en SQL pur non plus). Mais il apparaît que l'agrégateur RSS de
Safari n'a pas besoin de ce tri, il réordonne comme il faut. Savez-vous si
c'est effectivement superflu pour tous les agrégateurs ?
En théorie oui ; en pratique, il faut voir. Mais tu peux utiliser un #FILTRE{} final sur la page pour réordonner les <item> !!
Les deux mises en
squelette pas encore finies sont celles appliquant au final la fonction PHP
"trier_par_date" sur les résultats de plusieurs Select SQL. Cette opération
n'est faisable qu'avec un squelette contenant du PHP (d'ailleurs c'est pas
faisable en SQL pur non plus). Mais il apparaît que l'agrégateur RSS de
Safari n'a pas besoin de ce tri, il réordonne comme il faut. Savez-vous si
c'est effectivement superflu pour tous les agrégateurs ?
En théorie oui ; en pratique, il faut voir.
C'est assez Zarbi en fait. Devant un flux RSS non trié, Firefox semble s'arrêter au premier item postérieur au précédent, ou qqch de genre.
Je suis bon pour le squelette avec PHP.
Voilà, en ce qui me concerne ce programme de travail est terminé !
Emmanuel, si tu veux "aller au bout", c'est le moment.
Je finis d'abord le boulot sur les flux RSS et je regarde.
Chose en partie liée: je termine en ce moment la mise en squelette de
l'autre pseudo action action/rss.php, ce qui permettrait de rationnaliser ce
répertoire action qui actuellement est assez incohérent. Les deux mises en
squelette pas encore finies sont celles appliquant au final la fonction PHP
"trier_par_date" sur les résultats de plusieurs Select SQL. Cette opération
n'est faisable qu'avec un squelette contenant du PHP (d'ailleurs c'est pas
faisable en SQL pur non plus). Mais il apparaît que l'agrégateur RSS de
Safari n'a pas besoin de ce tri, il réordonne comme il faut. Savez-vous si
c'est effectivement superflu pour tous les agrégateurs ?
En théorie oui ; en pratique, il faut voir. Mais tu peux utiliser un #FILTRE{} final sur la page pour réordonner les <item> !!
C'est typiquement une boucle (POUR) qui serait ici la bonne réponse, non ?
En particulier si l'on veut ne ressortir que les 10 items les plus récents, sans savoir comment ils se répartissent entre les différentes boucles...
Cédric