pubnum: document my difficulties with hugo dates

* NEW Adds new kinds for two categories (pubnum, traces).
* NEW Adds a blog post to document my difficulties with the way hugo
process dates.
* NEW Update the layout templates.

Co-Authored-by: Igor Milhit <igor@milhit.ch>

archetypes/pubnum.md

@@ -0,0 +1,9 @@
+---
+title: "{{ replace .Name "-" " " }}"
+date: {{ .Date }}
+draft: true
+categories: ["publication numérique"]
+tags: [""]
+slug: {{ .Name }}
+---
+

archetypes/traces.md

@@ -0,0 +1,9 @@
+---
+title: "{{ replace .Name "-" " " }}"
+date: {{ .Date }}
+draft: true
+categories: ["traces"]
+tags: [""]
+slug: {{ .Name }}
+---
+

content/blog/les-dates-avec-hugo.md

@@ -0,0 +1,96 @@
+---
+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&#x202F;: {{ .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&#x202F;: {{ dateFormat "2006-01-02" (default .Date (.PublishDate)) }}</li>
+{{ if isset .Params "lastmod" }}
+  <li>Dernière mise à jour&#x202F;: {{ .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.

themes/portfoliGor

@@ -1 +1 @@
-Subproject commit 02d6d2f08623ed894085ee4f0594c383fba9c167
+Subproject commit 55dadc702cbe691c63ad12f48d03a489cd862169