97 lines
4.9 KiB
Markdown
97 lines
4.9 KiB
Markdown
---
|
||
title: "Les dates avec hugo"
|
||
date: 2019-08-25T13:11:00+02:00
|
||
publishdate: 2019-08-26
|
||
draft: false
|
||
categories: ["publication numérique"]
|
||
tags: ["hugo", "dates", "configuration"]
|
||
slug: les-dates-avec-hugo
|
||
---
|
||
|
||
Ces derniers jours, je me suis un peu cassé la tête avec la manière dont
|
||
[*hugo*](https://gohugo.io/) conçoit et traite les dates. Ce que je cherchais à
|
||
réaliser ne me semblait pourtant pas si exotique. Lorsque l'on crée un nouveau
|
||
contenu, par exemple un nouveau billet de blog, à l'aide de la commande `hugo
|
||
new` (et en utilisant l'`archetype` par défaut), *hugo* ajoute dans les
|
||
métadonnées (le *FrontMatter*) une valeur au champ date. Ce qui donne pour le
|
||
fichier du texte que je rédige à l'instant : `date: 2019-08-25T13:11:00+02:00`.
|
||
|
||
Dans le *template* qui permet d'afficher la date du billet de blog une fois le
|
||
site généré, on peut trouver du HTML simplissime :
|
||
|
||
```
|
||
<li>Publié le : {{ .date.Format "2006-01-02" }}</li>
|
||
```
|
||
|
||
Jusqu'ici, tout va bien. Pourtant, le plus souvent cette date ne correspond pas
|
||
à la date effective de publication du billet, parce qu'entre le moment où je
|
||
crée le fichier et le moment où il est suffisamment prêt pour être publié, il
|
||
peut se passer plusieurs jours. Ça tombe bien, *hugo* propose une autre
|
||
variable à ajouter, manuellement, dans les métadonnées, `publishdate`. Enfin,
|
||
il peut également arriver qu'après la publication, il soit nécessaire de
|
||
modifier un billet. Là aussi, il existe une variable, `lastmod`. Celle-ci
|
||
peut-être ajoutée à la main ou renseignée par la date du dernier
|
||
[*commit*](https://fr.wikipedia.org/wiki/Commit) de modification du fichier, si
|
||
`enableGitInfo` est activé dans le fichier de configuration du site.
|
||
|
||
Tout va bien dans le meilleur des mondes ? Presque. Assez logiquement, je
|
||
trouve, je voulais afficher d'abord une date de publication, par exemple `date`
|
||
ou `publishdate` si cette dernière date existe, et, le cas échéant, la date de
|
||
la dernière modification. Ce faisant, j'ai été confronté à deux difficultés. La
|
||
première était que toutes mes méthodes de tests logiques (si `publishdate`
|
||
existe, alors affiche cette date, sinon affiche `date`, par exemple),
|
||
provoquaient des erreurs lors de la génération du site. Pour avancer quand
|
||
même, chaotiquement comme c'est mon habitude, j'ai fait abstraction des tests
|
||
et tenter d'afficher toutes les dates.
|
||
|
||
D'abord, j'ai été surpris de constater que si l'une d'elle n'existe pas, elle
|
||
n'est simplement pas affichée. Il y a là un mécanisme qui m'échappe, mais
|
||
pourquoi pas. L'autre point déroutant, est que les valeurs des dates affichées
|
||
ne correspondaient pas à ce que j'avais imaginé. Souvent, `date` et
|
||
`publishdate` étaient identiques, parfois `lastmod` également, parfois
|
||
`lastmod` avait bien la valeur du dernier *commit* correspondant à la dernière
|
||
modification du billet concerné, mais pas lorsqu'il s'agissait du premier
|
||
*commit*.
|
||
|
||
J'ai essayé de nombreuses choses, tenté de comprendre la documentation de
|
||
*hugo*, fouillé dans les forums… de m'arracher mes cheveux, de jurer et
|
||
d'insulter le Web, en vain. Avant de tomber sur une discussion sur le forum de
|
||
*hugo* dans laquelle était signalée la section suivante de la documentation :
|
||
[*Configure
|
||
dates*](https://gohugo.io/getting-started/configuration/#configure-dates). Je
|
||
l'ai lue attentivement et j'ai fini par comprendre ce qui se passait, à défaut
|
||
de tout à fait comprendre la logique à l'œuvre. Pour obtenir un comportement
|
||
qui correspond à ce que je voudrais, il faut que dans le fichier de
|
||
configuration de mon site (`config.toml`), je redéfinisse à ma guise la manière
|
||
dont les variables de dates sont renseignées.
|
||
|
||
```
|
||
[frontmatter]
|
||
date = ["date", "publishDate"]
|
||
lastmod = [":git", "lastmod"]
|
||
```
|
||
|
||
Avec cette méthode, j'évite que le champ `date` puisse récupérer la valeur de
|
||
`lastmod` et que celui-ci puisse obtenir la valeur de `date` ou `publishdate`.
|
||
Du coup, je peux les distinguer, pour avoir une date de publication et/ou une
|
||
date de dernière mise à jour. Si la date de publication est différente de la
|
||
date de création du fichier, je dois manuellement, soit modifier la valeur de
|
||
`date` dans le *FrontMatter*, soit y ajouter la variable `publishdate`.
|
||
`lastmod` par contre, peut-être inférée de l'historique `git`, pour autant que
|
||
`enableGitInfo` soit bien à `true` dans la configuration.
|
||
|
||
Au niveau des *template*, ça peut donner ceci :
|
||
|
||
```
|
||
<li>Publié le : {{ dateFormat "2006-01-02" (default .Date (.PublishDate)) }}</li>
|
||
{{ if isset .Params "lastmod" }}
|
||
<li>Dernière mise à jour : {{ .Lastmod.Format "2006-01-02" }}</li>
|
||
{{ end }}
|
||
```
|
||
|
||
Il n'est pas du tout invraisemblable que cette solution puisse être améliorée.
|
||
Ce que je retiens de cette aventure, c'est que *hugo* est décidément très
|
||
puissant, le résultat d'une réflexion plutôt poussée et que j'ai encore
|
||
beaucoup de travail avant d'arriver à un niveau suffisant de compréhension de
|
||
son fonctionnement.
|