cacatoès

CMS

Static Site Generator

Une liste triable : https://staticsitegenerators.net/

Packagés dans Debian

pelican, lektor, hugo, jekyll, chronicle, staticsite… (et d’autres)

Python

  • pelican
  • sigal : Un autre ssg Python pour les galeries
  • lektor : dispose d’un service en backend admin/écriture sur le port 5000
  • mkdocs : en Python, pour de la doc écrite en markdown, packagé dans Debian, un peu lourdingue sur les dépendances (libjs à gogo, quelques unes liées à sphinx).
  • rippledoc
  • Hyde : pas de commit depuis 2016
  • nikola : projet entretenu mais paquet Debian retiré et non maintenu
  • cactus : template django, sinon fourre-tout de technos 3rd party
  • staticsite (paquet debian) : par E. Zini, inspiré par Hugo

Bash

  • ssg : en bash avec lowdown
  • lgbt : similaire à ssg, par Thuban

… ou du templating direct, comme avec j2cli qui utilise jinja2, cookie ou le plus connu pandoc.

Haskell ou Perl

  • chronicle : en Perl, pour blogs. J’aime bien le résultat de celui de Petter Reinholdsten
  • hakyll (desc) : config a la xmonad, pandoc markdown+TeX

Rust

  • Cobalt : il s’épanche peu et fait croire qu’“il suffit de” (outil “cargo” de Rust)
  • Zola infos : ptet pas mal, trop de fonctions ?

Ruby

  • nanoc infos : semble corporate, pages peu descriptives du projet
  • jekyll infos : utilisé par github, markdown+liquid templates

Go

  • hugo infos : serveur en backend, markdown+front matter (meta), peu de dépendances !

Pandoc et dérivés

  • pdsite : sh+pandoc, dépot git non mis à jour depuis 2016.
  • https://stackoverflow.com/questions/15402512/whole-site-compilation-of-markdown-pandoc
  • rippledoc en python utilisant pandoc est assez simple. Pas propre car il met tout dans un même répertoire : sources markdown, fichiers html, et même le binaire qui sert à générer le bordel. Aussi il regénère TOUT le site à chaque modif pour générer les liens et menus, toléré pour utilisation individuelle mais à proscrire si utilisation collective. En plus, je n’ai pas vraiment besoin d’un menu persistant sur la gauche.
  • makebakery : avec make et pandoc, ptet pas mal.

CMS en PHP

  • Grav
  • Dokuwiki
  • Monstra
  • Pico CMS
  • Wordpress

Grav

  • Interface d’admin de base surchargée en complexité
  • Pas de gestion des utilisateurs de base, que donne l’interface admin avec des possibilités réduites ?
  • Semble être orienté geek, il faut passer des paramètres pour redimensionner une image.
  • Soucis inconnu lors de l’upload d’un avatar où l’upload d’image a fini par fonctionner miraculeusement au bout de plusieurs essais
  • l’outil en ligne de commande est plus compliqué à concilier si l’on alterne entre la gestion web (www-data) et la gestion par SSH (utilisateur courant)
  • la configuration nginx est fournie et n’est pas des plus rudimentaires

Dokuwiki

  • Création de nouvelles pages presque pas accompagnée (entrer l’ID dans l’URL)
  • Syntaxe spécifique à l’outil
  • Classement peu intuitif des ressources
    • Gestion des médias (images, videos) plutôt chiante, difficulté de synchroniser l’arborescence des pages et celle des médias
    • Le déplacement des pages nécessite un plugin

Monstra

  • Quelques soucis lors d’une tentative d’installation via https, le CSS ne charge pas, des bouts cherchent en http
  • Intégration de google-analytics dans le template fourni par défaut
  • Projet porté par une personne, bof confiance dans le suivi de sécurité etc.

Pico CMS

  • S’attend à ce que l’utilisateur créé les fichiers .md de lui-même (pas de gestion)
  • Fonctionne assez directement.

Wordpress

  • Nécessite une base de données, le contenu et la config ne sont pas en flatfile ce qui rend moins flexible les migrations.
  • Ne gère pas officiellement postgresql.
  • Dispose d’un paquet Debian qui dépend de MySQL/MariaDB (rend compliqué la séparation des services en cas de conteneurisation).

Conclusion

Wordpress apparaît comme l’outil le plus utilisable, mais sa dépendance à MySQL implique quelques désagréments.

Puisque aucun de ces outils PHP ne coche toutes les éxigences, il faudra peut-être se pencher sur des solutions plus complexes comme Django/Wagtail.

Idée principale : utiliser git pour le stockage des données

Il faut donc des CMS qui correspondent à ce modèle.

Cela va sans dire, on exclue les solutions dans le cloud non maitrisables (Github, Gitlab, Heroku), si elles sont libres il est toutefois possible qu’elles soient reprises par des structures amies (Gitlab FFDN…)

## Outils

RippleDoc

Se récupère ici : https://gitlab.com/uvtc/rippledoc

La version que j’utilise est patchée :

  • retrait du texte “Contents:” pour la table des matières.
  • retrait du footer
  • passage de lang=fr en paramètre à pandoc

Limitations de l’outil :

  • il regénère tout le site au moindre changement (édition de la toc, d’une faute de frappe…)
  • il faut gérer soi-même les liens internes et les corriger en cas de déplacement