La gestion des dates sous spip

Actuellement, trois types de dates sont définis sur les articles spip (voir [la page de la doc sur la gestion des dates->http://www.spip.net/fr_article1971.html]) :

• <code>#DATE</code> est la date de mise en ligne. (Modifiable après la mise en ligne de l’article, de la brève, etc. La date d’une rubrique est celle de son élément le plus récent.)

• <code>#DATE_REDAC</code> est la date de première publication. (Modifiable à volonté, disponible sur les articles seulement.)

• <code>#DATE_MODIF</code> est la date de dernière édition de l’article : précisément, il s’agit de la dernière date à laquelle cet article a été ouvert en édition qu’il ait été modifié ou pas. Pratique dans de nombreux cas, mais pas d’une rigueur scientifique... (Non modifiable, sauf si on veut la fixer à « maintenant » : il suffit alors... d’ouvrir l’article en édition.)

Quelques possibilités d’amélioration :

• (FrancoisSchreuer) Créer une date d’expiration (<code>#DATE_EXPIRATION</code> ?) (facultative) permettant de programmer la disparition d’un article à telle date. Il s’agit d’une fonction assez régulièrement demandée par les utilisateurs (par exemple [ici->http://thread.gmane.org/gmane.comp.web.spip.user/1326]). (problème : comment est-ce qu’on fait quand certaines pages pointant sur cette ressource ont une durée de cache longue) ;
  • (NicolasHoizey) Je ne pense pas qu’il faille se prendre la tête pour le cache dans ce cas là. L’article mettra un peu plus de temps pour disparaître, voilà tout.
    • (FrancoisSchreuer) Ok. Autre problème du même type à ne pas perdre de vue : avec une telle fonctionnalité, les liens internes peuvent être cassés et, sur un gros site, sans outils spécifique, ça peut vite devenir ingérable.
      • (NicolasHoizey) Avec le code que j’ai fourni pour gérer le référencement des LiensInternes, on doit pouvoir facilement avoir une liste des éléments publiés ayant des liens vers d’autres éléments qui ne le sont pas

• (FrancoisSchreuer) Différencier la date d’ouverture en édition (ouvrir la page <code>articles_edit.php3</code>), actuellement renvoyée par <code>#DATE_MODIF</code> de la date de dernière modification réelle (pousser sur le bouton "Valider" de la même page). Si je comprends bien, le fonctionnement actuel de <code>#DATE_MODIF</code> se justifie principalement pour gérer la travail à plusieurs et éviter que deux personnes n’ouvrent en même temps le même article en édition. Il serait sans doute intéressant de dédoubler cette date en a) une date à vocation purement interne permettant de gérer le travail collaboratif et b) une date à vocation publique (on récupérerait <code>#DATE_MODIF</code> à cette fin) permettant d’afficher la dernière modification réelle d’une ressource.
  • Oui ! (Antoine)

• (FrancoisSchreuer) Créer une balise (<code>#DERNIERE_MODIF</code> ?) permettant d’agréger au niveau du site ou d’un secteur les dates de dernières modifications des ressources. Actuellement, pour afficher la dernière modif d’un site, on peut utiliser une boucle du genre :
  
  <code><BOUCLE_derniere_modif(ARTICLES) par date_modif inverse 0,1>[Dernière mise à jour du site : (#DATE_MODIF|affdate)]</BOUCLE_derniere_modif></code>
  
  Si on veut agréger les dernières modifs de toutes les ressources, on doit récupérer la date de dernière modif de chaque type de ressource en php, les comparer, et afficher la plus récente, ce qui est quand même un peu fastidieux.

• (NicolasHoizey) Un besoin supplémentaire serait de pouvoir toujours disposer dans le contexte d’une date passée en paramètre en URL, même à l’intérieur d’une boucle...
  • (PiiF) Dans un critère de boucle, c’est faisable en l’appelant <code>debut_...</code>.
    • (NicolasHoizey) Oui, mais le paramètre <code>date</code> s’il est passé dans l’URL n’est utilisable que dans un premier niveau de boucle, d’où par exemple la bidouille dans mon agenda

• (FrancoisSchreuer) Faut-il prévoir la possibilité d’articles non datés ? Actuellement, on peut avoir un article sans jour, sans mois, mais pas sans année. Ca pourrait être utile dans différentes circonstances.

• (FrancoisSchreuer) Quid des articles datés de plus de dix ans ? Je viens d’encoder un article datant du XIXème siècle et je n’ai pas trouvé d’autre solution que d’aller éditer directement la date dans la base de données en courcircuitant spip. Ne serait-il pas plus simple, dans les formulaires gérant les dates, de remplacer le menu déroulant de l’année par un simple input texte ?

• Une contrib à signaler sur la question des dates : [Modifier l’heure d’un article->http://www.spip-contrib.net/ecrire/articles.php3 ?id_article=633]

• (jlgrellier) Je ne suis pas aussi "urluberlu" que cela finalement... dates. Ce qui m’inquiète plus, c’est que cette discussion à presque été abandonnée : POURQUOI ???? Vos demandes ci-dessus me semblent tout à fait raisonnables et raisonnées. Les raisons des cores-dev pour refuser certains dev me semblent parfois plus relever d’une position philosophique que techniques... et je trouve cela dommage. On préjuge trop de ce que pourrait faire un utilisateur... quand on me répond sur les dates, qu’il ne faut pas archiver : pb de place et de perf et qu’il ne faut pas supprimer : pb de liens : on fait quoi alors ??? Des sites statiques ??? Parfois j’ai vraiment l’impression de tourner en rond, et qd j’ai cette sensation, des projets comme Agora me font peur (si si, vraiment...).
  • (Antoine) Si une discussion semble "abandonnée", ça peut être tout simplement qu’il n’y a plus grand’chose à ajouter sur le sujet... Cela ne veut pas dire qu’aucun développement ne sera réalisé ;) D’ailleurs, il est possible de contribuer.