URL: https://linuxfr.org/news/simpleweb-le-plus-petit-gestionnaire-de-contenu-cms-du-monde Title: simpleWeb, le plus petit gestionnaire de contenu (CMS) du monde Authors: echarp Benoît Sibaud et Davy Defaud Date: 2020-04-19T17:11:09+02:00 License: CC by-sa Tags: web, générateur et cms Score: 5 … dans sa catégorie ! :) En fait, un assemblage de quelques scripts shell et Web (un script Web c’est du JavaScript, non ?), qui permet de gérer des sites Web statiques. Un nain posé sur les épaules de géants : Apache httpd, hugo (mais cela serait modifiable), cron et incron, git, tinymce et ace. Une plate‐forme pour générer des sites et un éditeur Web minimaliste pour les modifier, afin de permettre à des non‑techniciens d’interagir avec des outils qui leur sont généralement inaccessibles. ---- [Code source](https://framagit.org/simpleweb) [Bac à sable](http://sandbox.acoeuro.com) [StaticGen](http://staticgen.com) [Thèmes](https://themes.gohugo.io) [À Livr’Ouvert (exemple 1)](https://www.alivrouvert.fr) [Fils du Net (exemple 2)](https://filsdu.net) [Finverbus (exemple 3)](http://www.finverbus.com) ---- # Au commencement Il y avait du HTML, du CSS et du JavaScript, un assemblage de trois langages disparates, mais qui permettent : * performance ; * sécurité ; * facilité de maintenance. # Génération statique Leur mise en place peut cependant se révéler compliquée, surtout parce que les pages d’un site Web comportent souvent des éléments communs ou répétitifs. Un en‑tête, un menu ou pied de page, par exemple. Il peut aussi y avoir des problématiques de traduction, si une même page existe en plusieurs langues. Dans ce contexte, un générateur de site Web statique devient presque indispensable. Avec lui, on automatise les tâches qui permettent la mise en place du fond, de la forme et des comportements, ces fameux HTML, CSS et JavaScript. Cela fonctionne assez bien pour les techniciens, ceux qui vont directement éditer leur site Web avec `vim` ou `emacs`, par exemple, puis lancent manuellement la génération et le déploiement. Le générateur statique peut tourner en fond, en attendant un changement quelconque dans un des fichiers source. Et avec `livereload` le navigateur va même tout de suite afficher les changements ! # Étapes 1. éditer 2. générer 3. sauvegarder sous Git Dans simpleWeb l’édition se fait avec l’éditeur [[WYSIWYG]] nommé `tinymce`, et aussi avec `ace` qui, lui, est plus orienté code. Le choix se fait en fonction du type de fichier édité. `incron` détecte cette édition et lance le générateur statique en tâche de fond pendant trente minutes. Cela permet une génération presque instantanée tout en conservant la mémoire système en évitant qu’un générateur soit continuellement en fonctionnement pour chaque site Web. La sauvegarde `git` se déclenche après chaque édition. # Minimaliste $ cloc --exclude-dir=test,build /var/simpleWeb/bin /var/simpleWeb/conf /var/simpleWeb/apps/editor 34 text files. 34 unique files. 12 files ignored. github.com/AlDanial/cloc v 1.82 T=0.02 s (1497.8 files/s, 101611.8 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Sass 4 93 2 476 CoffeeScript 7 63 40 388 Bourne Shell 7 90 32 275 Haml 2 6 5 85 HTML 2 6 0 51 Ruby 1 4 6 11 YAML 1 0 0 3 JavaScript 1 1 59 0 ------------------------------------------------------------------------------- SUM: 25 263 144 1289 ------------------------------------------------------------------------------- # Magique Il y a plusieurs « **tours** » (au sens étapes ou pas). En effet, comment modifier un site statique _à l’aide_ d’un éditeur Web statique. Sans base de données, ni serveur applicatif ?! Avec le module `webdav` d’Apache httpd ! C’est une extension du HTTP, qui permet d’interagir avec les fichiers d’un serveur (lire, créer, modifier, supprimer…). Le client peut être n’importe quel navigateur Web qui sait utiliser les verbes HTTP appropriés, à l’aide de JQuery (cela pourrait fonctionner avec d’autres bibliothèques JavaScript, bien sûr). Un deuxième _**tour**_ repose sur `incron`, qui surveille les fichiers journaux du serveur Web Apache. Ces journaux sont rattachés à chaque site Web, et sont configurés afin que les verbes HTTP de consultation et les verbes de modification aboutissent à des fichiers séparés. `incron` peut ensuite surveiller ces fichiers et lancer le générateur statique et la synchronisation Git. `cron` va ensuite arrêter le générateur au bout d’un certain temps d’inactivité (à l’aide d’un fichier contenant l’identifiant du processus correspondant). Un troisième _**tour**_ dépend d’Apache, qui permet facilement de modifier la page listant un répertoire. C’est ainsi que l’on peut y injecter un script qui organise la page et permet l’édition. # Utilisations C’est un petit projet, mais il est utilisé sur des sites comportant des milliers de pages. Dans ce contexte, le lancement du générateur `hugo` (il a été choisi car c’est actuellement le plus rapide) prend une minute. Une fois lancé, il reflète une modification presque instantanément. Les utilisateurs n’ont accès qu’au contenu « pur », c’est‐à‐dire l’un des sous‐répertoires nommé `content`, et pas les squelettes de pages ou la mise en forme. # Évolutions L’édition des méta‐données disponibles en Markdown, sous la forme de clés‐valeurs dans un en‑tête [[YAML]] ou [[TOML]], reste spartiate, et sera probablement améliorée dans le futur. Une remontée des erreurs possibles du générateur est aussi en place dans l’éditeur, mais reste cryptique, car ces erreurs sont souvent plutôt techniques et cryptiques. :) Il y a du travail à faire de ce côté‑là ! Cet éditeur statique est en fait généré avec un autre outil : `middleman`, qui n’est plus guère maintenu mais permet facilement d’écrire en utilisant les syntaxes alternatives : [[Haml]], [Sass](https://fr.wikipedia.org/wiki/Sass_(langage)) et [[CoffeeScript]]. Il faudra sûrement revoir cela à un moment donné. Peut‑être tester un générateur statique fait en Rust (donc plus rapide ?), ou assembler un générateur en utilisant `incron` et d’autres outils système. En théorie, on peut éditer l’éditeur avec l’éditeur, si si !!! Le générateur `hugo` est vraiment très bien, et il a été utilisé comme base pour les scripts existants. Il faudrait faire un gros travail pour le rendre interchangeable aisément, surtout parce que les arborescences de fichiers ne sont pas les mêmes d’un générateur à un autre… # Intégration et sécurité Eh oui, un éditeur de site Web se doit de limiter les accès à seulement ceux qui y sont autorisés. Pour cela, inutile de réinventer la roue, Apache httpd sait très bien gérer ce genre de choses, par exemple avec : * un fichier d’identifiants et mots de passe ; * les droits d’un projet Redmine ; * une authentification GitLab. Autant de mécanismes déjà mis en place pour certains sites. Le code source d’un projet GitLab peut déclencher une synchronisation Git et une régénération du site à chaque _push_. Là encore, avec les journaux d’Apache et `incron`, en surveillant une adresse HTTP prédéfinie, que l’on configure dans GitLab. Cela offre un grand confort au technicien qui veut éditer et tester un site sur son propre ordinateur, avant de le pousser sur un autre environnement. En théorie, il serait ainsi possible de multiplier à l’infini les environnements d’édition : développement, recette, préproduction, production, etc., tout en gardant un historique plutôt fin (mais l’historique ne reflète pas les auteurs, c’est une limite technique qui cherche encore sa solution). Bref, c’est un assemblage que l’on pourrait qualifier de bricolage système, mais basé sur des concepts et des outils tellement simples et efficaces, que je voulais vous en parler ! :)