Côté sommaire, pour filtrer nous utilisions le filtre {age>=0}. Seulement, les articles apparaissent quand même sur la page mais génèrent une erreur lorsqu’on tente de les consulter. En examinant la requête effectuée pour récupérer les article de ma boucle je me suis rendu compte que le filtre age ajoutait cette condition à la requête MySQL : (TIMESTAMPDIFF(HOUR,articles.date,‹ 2024-11-25 15:20:00 ›)/24 >= 0)
Et le soucis vient de là, en effet les articles prorammés pour dans moins d’une heure apparaissent alors qu’ils ne sont normalement pas encore publiés.
Ya t’il un moyen de remplacer (par le biais d’un plugin, ou d’un morceau de code dans mes options) le HOUR par SECOND afin que les articles ne soient visibles qu’une seconde avant leur publication ?
Mouais, je ne crois pas que des plugins faisant cela existe.
Pour ce que j’en vois en première approche du reste, on pourrait considérer cela comme un bug, mais si on modifie par seconde, le risque est qu’un article publié dans l’heure qui précède n’apparaisse pas, car le cache sera toujours valide.
Donc peut être ouvrir un ticket, et on en discute là bas ?
Avec plaisir, mais je ne sais pas où se trouvent les tickets
En soit, que l’article n’apparaissent pas pile à l’instant T ne me pose pas spécialement de problèmes, le tout est qu’il soit publié après l’heure de publication et pas avant
Ticket créé, cependant, s’il faut attendre la prochaine release pour avoir le correctif, ça risque de me compliquer la tâche… les équipes SEO bossent déjà sur notre contenu.
Y aurait-il un moyen « en attendant » de hardcoder cette modif ?
Il y a d’autres manières SPIP d’écrire {age>=0} avec la précision que tu veux.
Voici 2 pistes :
avec un critère {date_redac<=NOW()}
sinon, avec un critère {WHERE ...} et justement, il y a un exemple qui utilise une fonction MYSQL de date : {where} - SPIP
Selon le contenu visé, il est parfois nécessaire, ou plus facile en tout cas, de préparer le contenu du critère avant, dans un #SET.
Par exemple : #SET{where,#GET{" spip_articles.date_redac < "}|concat{" NOW() "}}
ou #SET{where,#GET{" spip_articles.date_redac < "}|concat{#VAL{' "Y-m-d H:i:s" '}|date}}
puis {where #GET{where}} en critère de ta boucle à la place de {age>=0}
Je ne pense pas avoir assez de légitimité pour proposer un correctif je suis trop noob sur spip pour me le permettre. =) Je préfère faire confiance aux choix de l’équipe de développeurs chevronnés qui maintiennent SPIP. Et peut-être que ce choix de précision est prévu pour des raisons bien définies et que mon cas est trop particulier pour que je puisse le proposer comme solution « universelle ».
J’aime bien l’idée de la requête en direct, est ce que cela peut influencer les performances ? L’idée de le préparer en amont me serait judicieussement utile car j’ai besoin de ce critère à plusieurs endroits dans la page d’accueil (plusieurs boucles d’articles)
Dans le code comme dans la vie, exprime ce que tu veux exprimer et choisit donc pour cela l’expression qui correspond à ton besoin (date, date_redac ou autre) .
Là sur ces écritures, il n’y a pas d’impact sur les performances car c’est pré-compilé une seule fois et les calculs doivent se faire de toute manière à peu près pareil ensuite.
Si tu dois employer ce test en plusieurs endroits, tu peux te créer un filtre (fonction PHP) pour renvoyer dans les squelettes SPIP l’expression calculée à partir de l’argument passé et ainsi le code de calcul sera proprement rangé dans le fichier de fonctions PHP et le squelette sera visuellement allégé.
Si tu dois employer ce test en plusieurs endroits, tu peux te créer un filtre (fonction PHP) pour renvoyer dans les squelettes SPIP l’expression calculée à partir de l’argument passé et ainsi le code de calcul sera proprement rangé dans le fichier de fonctions PHP et le squelette sera visuellement allégé.
Je vais voir comment je peux réaliser cela via la documentation SPIP, je ne maîtrise pas encore bien le fonctionnement des fonctions « homemade ».
