j'ai apporté pas mal de modifs sur les critères d'age, de manière à ce que
{age} et {age_relatif} ne soient plus bêtement égaux à 0 quand les deux
articles que l'on compare ont été publiés le même jour.
Du coup une boucle comme
<BOUCLE_a(ARTICLES){par date}>
<br> #ID_ARTICLE : #DATE
<BOUCLE_b(ARTICLES){age_relatif<0}{par date}{0,1}>
(#ID_ARTICLE : #DATE)
</BOUCLE_b>
</BOUCLE_a>
indique bien, pour chaque article, celui qui a été publié juste après (son
successeur, donc), entre parenthèses. Ce n'était pas le cas avant si deux
articles ou plus avaient été publiés le même jour.
De plus, si une date=xxxx est passée dans l'URL, on l'analyse un peu avant
de l'envoyer dans MySQL. Du coup '2003' devient '2003-01-01', et '2003/02'
devient '2003-02-01' (il y a même mieux, si php>3.0.12, la date est analysée
à partir de la fonction strtotime, cf. http://php.net/strtotime )
Des critères supplémentaires {jour_relatif}, {mois_relatif} et
{annee_relatif} permettent du coup de sélectionner "tous les articles parus
le même mois que... l'article en cours / la date de l'URL" {mois_relatif=0}
etc.
Est-ce que ça fonctionne toujours avec les dates floues ("mai 2000",
"2000")? C'était la cause du comptage des dates en jours précédemment.
Euh oui, enfin je crois (quand on programme au milieu de la nuit à cause
d'une insomnie pétaradante, on peut craindre le pire mais la
normalisation des dates que j'impose à un autre endroit devrait même
permettre de ne plus avoir le LEAST(...) sur {age_relatif}
* le tag #DATE fonctionne en-dehors des boucles (cas des dates passées dans
l'URL)
* tous les critères {date_...} ou {age_...} sont disponibles en
{date_..._redac} ou {age_..._redac} -- mais attention c'est la date_redac
relative à la *date* courante, pas à la *date_redac* (donc ces critères ne
sont probablement utilisable qu'avec la date passée en URL ou en contexte
inclus) ; pour comparer à la date_redac courante, il faut doubler :
{age_relatif_redac_redac}... c'est un peu dingue, mais au moins ça sera
logique et mnémotechnique. Sauf si quelqu'un a plus simple ??
Non, je ne comprends pas un traitre mot. Est-ce que tu peux expliquer avec
les critères "date" et "age", tout de même plus simples et réellement
utilisés?
Bon, heu, la date_redac est une date, et l'âge est une difféérence entre la
date qde l'article ue tu cherches dans la base et la date du contexte (celle
de l'article courant ou celle passée en URL).
Donc que signifie : {age_relatif_redac<0} -- que je cherche un article dont
la date_redac est < à la _date_ du contexte (celle de l'article courant ou
celle passée en URL) ; ça n'a guère de sens, tu cen conviendras, que si la
date de référence en question (celle du contexte) provient d'un URL.
Mais on peut aussi vouloir comparer la date_redac d'un article à la
date_redac d'un autre article (celui qui donne le contexte). Du coup il faut
un autre critère, et c'est {age_relatif_redac_redac}...
Est-ce que le fonctionnement de age_relatif a changé?
Il est en fraction de jours au lieu d'être en jours entiers ; mais pour le
reste, il n'a pas changé : il compare toujours la date de l'article que tu
cherches dans la base à la "date du contexte" (celle de l'article courant ou
celle passée en URL) ; et il fonctionne toujours avec les dates floues.
L'ancien comportement de {age_relatif} (qui faisait que {age_relatif=0}
signifiait "publié le même jour que..." est maintenant le comportement de
{jour_relatif=0} ; {age_relatif=0} signifie maintenant "publié au même
moment exactement que...", ce qui se conçoit dans des cas limite ;^)
Des critères supplémentaires {jour_relatif}, {mois_relatif} et
{annee_relatif} permettent du coup de sélectionner "tous les articles parus
le même mois que... l'article en cours / la date de l'URL" {mois_relatif=0}
etc.
Et pour ceux qui veulent essayer lemois_relatif ( merci Fil) :