cacatoès

CMS

Static Site Generator

  • pelican
  • Hyde : pas de commit depuis 3 ans
  • sigal : Un autre ssg Python pour les galeries
  • chronicle : en Perl, pour blogs. J’aime bien le résultat de celui de Petter Reinholdsten
  • lektor : en Python, celui-ci, je l’avais oublié !
  • 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).
  • 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. … et une floppée d’outils qui requièrent des environnements moins répandus (Ruby, Haskell…).

Pandoc et dérivés

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