D'origine le logiciel propose des flux pour :

  • les derniers billets du blog
    rss.php
  • les derniers billets d'une catégorie
    rss.php?cat=catégorie
  • les derniers commentaires du blog
    rss.php?type=co
  • les derniers commentaires d'une catégorie
    rss.php?type=co&cat=catégorie
  • les derniers commentaires d'un billet
    rss.php?type=co&post=billet

Pour l'ensemble de ces flux, il est possible de restreindre la génération aux seules informations disponibles dans une langue données en ajoutant dans l'URL le paramètre lang ( codification sur deux lettres ISO639 ).

Quelques idées d'améliorations

J'avais il y a quelques temps ajouté la possibilité de générer un flux par tag. Ce mécanisme permet aux utilisateurs de suivre un sujet en fonction d'un tag défini. Alexandre Passant à repris l'idée en l'améliorant. Il propose une simplification de l'URL en distinguant les flux générant des items de type 'commentaire' de ceux générant des items de type 'article'. Là ou j'introduisais un type 'tag', il ne reprend cette notion de tag que pour assurer la sélection des items de type 'article'. Sa démarche est plus juste que la mienne, je l'adopte.

Aujourd'hui David semble un peu perdu, lors de l'adaptation de ces codes sur sa nouvelle version de Dotclear, la 1.2.4. Alors je fais le ménage pour présenter un joli code tout propre adapté à cette version.

A la réflexion, pour compléter le mécanisme de génération des flux RSS dans Dotclear, il faut explorer plusieurs pistes.

  • La possibilité d'étendre la sélection des items par des combinaisons variées. Le mécanisme devrait pouvoir combiner des sélections d'ensembles d'items intégrant union, intersection, exclusion. Ces sélections devrait pouvoir être faite sur la base des catégories, des tags définis, de l'auteur. En langage simple pouvoir générer le flux RSS des articles portant les tags 'truc' et 'machin', ou générer le flux RSS des articles de la catégorie 'truc' et portant le tag 'machin', ou encore générer le flux RSS des articles rédigé par 'untel'
  • La meilleur prise en compte des ajouts de plugin lors de l'exécution du fichier rss.php. En effet si Dotclear dans sa version 1.x, intègre un mécanisme permettant d'étendre ses fonctionnalités par plugin, ceux-ci ne sont actifs que lors de la génération des pages visibles par les visiteurs. Cela peut poser des problèmes pour les plugins de type Spamplemouse, ou gestion de droit d'accès.
  • L'utilisation plus complète des spécifications de RSS. En effet actuellement si des flux sont générés en sélectionnant un tag particulier, rien ne l'indique dans le flux. Le champ dc.subjet est systématiquement rempli avec l'intitulé de la catégorie auquel appartient le billet. Nulle trace des tags dans le flux RSS. Or l'utilisation des balises adéquat, combinées à la définition du vocabulaire via des extrait RDF, permettrai d'attacher les items entre eux.
    Autre exemple d'utilisation partiel du format, les informations de syndication définisant la frequence de lecture du flux sont fixées en dur dans le code.
  • L'amélioration de la publication des informations permettant la découverte automatique des flux par les navigateurs. Et oui à force de tout changer, et de permettre la génération de flux divers et varié, la publication des informations n'est plus vraiment à jour. De plus avec la multiplication des flux, je m'interroge sur l'opportunité de publier la liste de ces flux sous un format OPML (Outline Processor Markup Language).

Bref il reste encore beaucoup à faire.

Comment implanter ces améliorations

Avant de proposer des solutions clef en main, je vais détailler le fonctionnement actuel.

La génération du flux est déclenchée par l'appel au fichier rss.php, lors de cet appel les opérations suivantes sont successivement exécutées :

( Désolé, je n'ai pas fait un joli dessin en couleur, mais vous pourrez en trouver sur la cinématique de Dotclear chez Franck )

  1. appel de /inc/prepend.php pour le chargement des classes génériques de base et de la configuration
  2. initialisation du cache
  3. Chargement des classes class.xblog, class.xblogpost, class.xblogcomment
  4. Analyse de l'URL
  5. vérification du cache
  6. connexion à la base de données
  7. création de l'objet $blog
  8. Génération de la liste des items :
    • Si il s'agit d'un flux de commentaires
      • recherche des nouveaux commentaires via $blog->getComments()
      • Parcourt de ces commentaires et génération des items via $comments->getRSSItem()
    • Si il ne s'agit pas d'un flux de commentaires
      • recherche des nouveaux articles via $blog->getLastNews()
      • Parcourt de ces articles et génération des items via $news->getRSSSeq()
  9. Fermeture de la connexion à la base de données
  10. Génération du flux encodé

Alors comment, et où, insérer les modifications souhaitées ?

Les modifications touchent plusieurs points :

  • l'analyse de l'URL.

    Il est possible comme je l'ai fait en introduisant les flux par tag de modifier seulement le fichier rss.php. Faut-il introduire des tests sur les paramètres passé, pour les nettoyer et pour éventuellement renvoyer un code erreur ( « catégorie inexistante » par exemple ) ? Pour garder un cohérence avec l'ensemble du logiciel, il faut penser à adapter les fonction de publication des liens RSS dans la partie visible du site.

  • la recherche des nouveaux commentaires et des nouveaux articles.

    Ces fonctions étant normalement définies dans la classe blog ( inc/classes/class.blog.php ), si il est possible de modifier ce source, cela n'est pas souhaitable pour des raisons de maintenance. Il est par contre possible de définir une classe étendant les possibilité de la classe blog en redéfinissant uniquement les deux fonctions incriminées et en héritant de l'ensemble des autres fonctions ainsi que des attributs.

  • la génération des items 'commentaire' et 'article'.

    Ces fonctions font appel aux classes class.xblogpost ou class.xblogcomment. Je ferais la même suggestion que précédemment, et je préconise une surcharge de ces classes.

  • l'amélioration de la découverte des flux

    Cette partie concernant la partie visible du site, je la traiterai séparément plus tard.

  • La prise en compte des plugins.

    Déjà petite remarque : je pense qu'il faut faire le tri. Soit le plugin est utile à la génération du flux, dans ce cas la question ne se pose pas il faut l'intégrer. Soit le plugin n'est pas utile à la génération du flux mais introduit un nouvel usage du fichier rss.php (c'est le cas de spamplemouse, qui permet la génération de flux de type 'spam'). Et là j'aurai tendance à considérer que si l'usage n'est pas à vocation publique, ces modification n'ont pas à être prises en compte. Mais ce n'est que mon avis et certains voudrons quand même voir sur leur agrégateur la longue litanie des spam.

    Donc si tous les plugins ne sont pas utiles, il faut pouvoir distinguer ceux à prendre en compte et ceux à ignorer. Ensuite il faut lister les plugins à intégrer et lancer leur script d'initialisation. Enfin utiliser les fonctions dans la génération du flux.

La suite, et le code des modifications

J'ai des idées sur ce sujet, vous n'en doutez pas, mais je les développerai plus tard.

Quelques lectures complémentaires