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.
|