$controler_dates_rss, une variable de personnalisation

Quand on abuse de la syndication automatique de SPIP, on cherche rarement à lire dans le marc de café et, par voie de conséquence, savoir ce que le futur nous réserve. La syndication, c’est pour suivre l’acutualité.

De la même manière, les informations bien datées, appartenant à la préhistoire du web ne sont pas nécessairement l’objet des abonnements RSS.

C’est pourquoi le code de SPIP considère que si la date d’un élément de flux RSS et « très vieux » (plus d’un an, dans le web, c’est pour les archéologues de l’Internet) ou trop loin dans le futur (plus de 48 heures), c’est qu’il s’agit probablement d’une erreur. Il inscrit donc la date du jour à la place de celle qu’il a trouvé.

À la marge de l’usage courant, on pourrait avoir besoin, parfois, de syndiquer des informations qui, à dessein, fournissent une date située à plus de 2 jours dans le futur. Par exemple, dans la mesure ou le format iCal n’est pas vraiment utilisé en tant que format d’échange entre deux sites SPIP, on peut se servir de RSS pour annoncer des évènements qui auront lieu dans le futur. C’est le cas, dans la galaxie SPIP, du site SPIP Party. Si vous syndiquez ses rendez-vous via le flux RSS dédié, vous verrez qu’ils sont tous référencés à la date du jour... Certes, les dates sont inscrites dans le descriptif, mais si vous cherchez à faire des tris par date, c’est foutu.

Or donc, SPIP a caché dans son code, une petite variable de personnalisation nommée $controler_dates_rss, qui vaut vrai par défaut et qui fait le test dont je viens de parler.

Si dans votre fichier config/mes_options.php, vous dites qu’elle est fausse, le test n’est plus effectué et les dates du futur, pour ne parler que d’elles, seront bien prises en compte.

Alors oui, c’est un cas rare et en plus, c’est un traitement global pour tous les sites syndiqués. Comme écrit dans le code :

// controle de validite de la date

// pour eviter qu’un backend errone passe toujours devant

// (note : ca pourrait etre defini site par site, mais ca risque d’etre

// plus lourd que vraiment utile)

En attendant, on s’en contentera. :)