Passage en statique

geek & hype

Il y a deux ans je testais Koken pour construire idolum. Le point fort de Koken était la connection depuis Lightroom, un service de publication. Et puis je suis passé de Mac à Linux, en abandonnant Lightroom, donc cette facilité a disparu. L’avantage qu’il restait à Koken était la mise en page facile d’articles et de galeries - mais ça, d’autre logiciels le font aussi.

Une autre question en suspens c’est la présence d’une database: pour un site comme idolum avec peu de mouvements, peu de data, et surtout peu d’interactions puisque les commentaires n’existent plus, quel est l’intérêt d’une database qui peut facilement se faire hacker ? Alors l’idée d’un site statique (juste une collection de pages HTML) a fait son chemin. J’ai fait une test rapide avec Nikola parce que c’est du Python et qu’en ce moment j’apprends le Python. Mais non, je n’ai pas réussi à faire ce que je voulais. J’ai testé avec Hugo, et après quelques tâtonnements, ça marche !

Hugo

Hugo est fait en go, mais franchement, ce n’est pas très important: si on ne hacke pas le moteur, on reste sur les templates des thèmes. Le langage du contenu (les posts) est du Markdown, qui permet une syntaxe relativement légère et claire.

Les templates sont codés en assemblant des morceaux de fonctionnalités. Exemple avec la homepage d’idolum:

{{ partial "header" . }}
    {{ $.Scratch.Set "shareNav" true }}
    {{ partial "navbar" . }}
    <!-- Main -->
    <div id="main">
      {{ $paginator := .Paginate (where .Site.Pages "Type" "post") }}
      {{ range .Paginator.Pages }}
          {{ .Render "content-list" }}
      {{ end }}
      {{ partial "pagination" . }}
    </div>
    {{ partial "sidebar" . }}
{{ partial "footer" . }}

Les briques de base ici sont header, navbar, content-list, pagination, sidebar et footer. Chacun de ces blocs correspond à un morceau de code mixant du HTML et du template.

Ajustements du thème

Le thème de départ de la mise en page courante est Hugo Future Imperfect, lui même un portage de HTML5 UP’s Future Imperfect.

Liste de mes modifications:

  1. l’ensemble des posts sur la homepage, à l’exception des albums
  2. deux sections d’albums, landscape/ et series/. Ces sections sont des listes, chaque élément de la liste n’affiche que l’image featured.
  3. un shortcode qui me permet d’instancier une figure pour une photo, donc d’attacher une légende

Reste à faire:

  1. reprendre un peu le CSS, beaucoup d’espace est perdu. Un peu de couleurs aussi peut-être ?
  2. de la correction orthographique en français dans mon éditeur :)

Workflow: travailler avec git

Tant qu’à faire un workflow, pourquoi ne pas se mettre à git ?

Voilà l’idée:

  • éditer du contenu localement (article, album photo)
  • le tester localement (avec hugo server)
  • construire un build de test (c’est à dire l’ensemble des pages HTML et les quelques fichiers autour), le pousser avec git sur une URL de test (privée)
  • une fois que c’est bon, construire le build final, et le pousser avec git sur idolum.info
  • au passage, se familiariser avec git, une ligne de plus sur mon CV !

Mon hébergeur fournit git comme service de déploiement. Il y a même une page d’explications. Donc voilà ce que je fait:

  • édition d’un article
+++
title = "Passage en statique"
date = 2018-03-25T14:19:21+02:00
draft = true
withsummary = "remove me for no summary"
description = "geek & hype"
type = "post"
tags =["geek", "web"]
+++

Il y a deux ans je [testais](/blog/une-nouvelle-ergonomie/) [Koken](http://koken.me/) pour construire *idolum*. ...
  • build pour l’URL de test:
hugo -b http://mon-url-de-test/ --cleanDestinationDir --destination ./test_htdocs/
  • push sur l’url de test

    # ajout, commit des changements
    git add <le fichier a ajouter>
    git commit -m "avec un message de log"
    # push sur la base git distante (remote)
    git push alias_test master
    # déploiement
    ssh <user>@<git.service> deploy <url-de-test.git> master
    

Si tout va bien, il n’y a plus qu’à réitérer sur l’URL de production.

hugo -b http://idolum.info/ --cleanDestinationDir --destination ./public/

Puis pousser dans le git remote associé à l’URL de production.

Et voilà.