En créant ce site, il a fallu que je me décide pour un CMS. Après une phase de recherches, je me suis décidé à utiliser Grav. Entre le choix initial, l'installation et la pratique à l'usage, je décris ici mes impressions sur cet outil peu connu qui change du traditionnel Wordpress.
L'origine de ma demande
L'origine c'est la création de ce site bien sûr. Mais avec quoi ?
Je voulais changer de Wordpress et, à l'occasion d'une visite à Paris web, j'ai assisté à une présentation qui parlait de générateur de sites statiques. J'étais attiré par tous ces nouveaux CMS headless et voulait aller vers plus de simplicité dans la gestion d'un site. J'ai donc mis ça de côté en me promettant d'y revenir un jour et la création de ce site fût une bonne occasion de m'y mettre.
J'étais aussi curieux de voir ce que pouvait apporter un site statique à l'usage.
La phase de recherche
Je suis rapidement tombé sur ces trois sites qui recensent et expliquent bien l'état de l'art sur les GSS :
Cela m'a permis de comprendre un peu mieux de quoi l'on parlait. Donc en gros, on génère à l'avance des pages HTML via un générateur de page basé sur une interface (ou pas) et des templates. On n'a pas besoin de base de données et l'on peut mettre ça assez facilement sur un serveur web et un CDN.
L'idée est de se concentrer uniquement sur le contenu et de laisser l'hébergement, le rendu et le design à d'autres (ou pas). Le couple Jekkyl / Netlify est la solution la plus aboutie en la matière me semble-t-il, mais on est sur du git là.
J'ai bien aimé cette vidéo (en anglais) de 2019 issue des JamStack conf qui résume bien l'idée de JamStack par l'entreprise Netlify.
L'heure du choix
J'avais quelques contraintes / prérequis / indices qui m'ont aidés à filtrer un peu les offres :
- Je voulais un outil open source
- En auto-hébergement
- Connaissant HTML, Markdown et git, je préférais m'orienter vers ce genre de langage / technologie
- Framasite utilisait Grav pour ses pages de blog
- Je connaissait des personnes satisfaites qui utilisaient Ghost, Pelican ou Cockpit
- Je n'avais pas besoin de base de données, ne souhaitant pas gérer les intéractions avec d'autres personnes sur la modification du site (via les commentaires ou un panier par exemple). Le contenu n'est donc pas "dynamique", 2.0, toussa toussa. Ca tombe bien , c'est l'idée du site statique.
- Je sais utiliser la ligne de commande mais s'il peut y avoir une petite interface d'administration sympa à ce CMS, c'est pas plus mal.
Bref, je me suis décidé pour Grav qui a l'avantage de n'être pas trop dépendant d'un langage exotique, qui est reconnu, avec une communauté vivace, beaucoup de thèmes différents et entretenus, une interface d'administration graphique simple. Un bon compromis dans la galaxie des CMS statiques.
Pour être complet, j'ai bien aimé Hugo aussi, que j'utilise par ailleurs. Mais là on parle d'une interface graphique en moins et donc plus de ligne de commande. Cela m'a semblé plus fastidieux avec une courbe d'apprentissage plus longue. Je me trompais.
En pratique, ça donne quoi ?
L'installation
J'ai un peu galéré car il a fallu créer un utilisateur dédié sur le serveur que j'utilise et que celui-ci ait les bons droits d'utilisation des sockets php (là je suis perdu). La configuration du serveur Nginx n'était pas évidente du tout.
Les thèmes
Bon là c'est normal mais on passe toujours beaucoup (trop) de temps à trouver les thèmes qui nous conviennent, c'est comme avec Wordpress. Et, comme avec Wordpress, il n'est pas évident de trouver un thème qui ne fasse pas tout mais seulement bien ce qu'il doit faire.
La configuration
L'avantage de Grav est qu'il existe un plugin qui gère graphiquement l'administration du site, ainsi que sa gestion du contenu.
Mais en fait, il a quand même fallu que je comprenne ce que je paramétrais en épluchant la documentation de grav. La première découverte fût le frontmatter c'est-à-dire les configurations en langage YAML des fichiers en Markdown. Pas dur mais de la documentation à ingurgiter.
La personalisation du thème
C'est là que c'est devenu chaud et que j'ai découvert le langage de templating Twig !
J'explique : le contenu est sous forme de fichiers Markdown, un langage très proche du texte normal, donc ça va. Mais pour transformer ce fichier en HTML il faut passer par des modèles , des "templates", qui sont écrits en un mélange de HTML et de Twig.
A partir du moment où l'on souhaite personaliser le thème, on est obligé d'aller vers plus de compréhension du CMS.
Le templating
Pour faire simple, et connaissant le fonctionnement de Wordpress, il s'agit de remplacer php par un autre langage, un peu plus simple peut-être mais avec les mêmes difficiles notions d'algorithmie. De la même manière, la hiérarchie des modèles de Wordpress est remplacée par un ordonnancement des fichiers et dossiers dans la structure des fichiers.
Donc, alors que je m'attendais à un truc plus simple pour ce type de CMS, je me retrouve avec les mêmes questions et des réponses différentes. En y réfléchissant, c'est normal qu'elles se posent si je veux personnaliser le thème.
L'internationalisation
Je me suis lancé dans la localisation de mon thème : les messages du type "previous post" devaient être traduits par "article précédent" etc..
De même, les dates anglaises et françaises ne sont pas affichées pareil. Il a fallu que j'aille dans le code des templates car il m'a semblé que le plugin d'admin ne répondait pas à ce besoin.
En plus, il existait de vrais bugs dans les templates, que je n'ai pu corriger qu'en allant sur les dépots Github des développeurs du thème. (Merci aux développeurs extérieurs pour les pull request).
Conclusion
Après cette petite grande phase de configuration / personnalisation, j'apprécie pouvoir me ballader facilement dans l'interface graphique pour éditer du contenu, mais cela n'a pas été facile d'arriver jusque là. Comme toujours, cela m'a permis d'apprendre des choses et de pouvoir le rendre aux autres (clients, futurs employeurs, communauté).
Et je vais pouvoir profiter des avantages des sites statiques :
- plus de rapidité dans le rendu des pages
- plus de sécurité dans le code
- une logique assez similaire d'un site statique à l'autre