Update Article “2023-02-28-staticcms-une-autre-approche-aux-cms”
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
parent
5bd266a5b2
commit
ddafe997f0
1 changed files with 25 additions and 8 deletions
|
|
@ -2,7 +2,7 @@
|
|||
layout: post
|
||||
title: StaticCMS, une autre approche aux CMS
|
||||
date: 2023-02-28T14:11:46.488+01:00
|
||||
status: draft
|
||||
status: published
|
||||
sitemap: true
|
||||
category: developpement
|
||||
description: Si Worpdress tient le haut du panier des CMS, il n'est pas dénué de
|
||||
|
|
@ -13,23 +13,40 @@ Deuxfleurs a fait le choix de stocker ses données via un système de son cru no
|
|||
|
||||
Alors si vous avez l'habitude de réaliser vos sites webs à la main, vous devriez être aux anges : en une commande, ou un glisser/déposer, votre site web est en ligne. Mais si vous êtes plutôt du genre à utiliser une interface, comme un système de gestion de contenu, alors tout devient plus compliqué…
|
||||
|
||||
À moins que… à moins qu'on puisse combiner “sites statiques” et “CMS”. Et heureusement pour nous, les sites statiques sont à la mode, donc pas mal de gens ont travaillé sur la question ces dernières années ! Quand on est cool, on appelle ça une [Jamstack](https://jamstack.org/). Ici rien à voir avec la confiture ou des concerts de musique, JAM veut dire Javascript, API et Markup, et c'est issu de réflexion par des développeurs web sur l'architecture idéale pour développer des sites webs. Nous, on va prendre juste les principes qui nous intéressent dedans.
|
||||
À moins que… à moins qu'on puisse combiner “sites statiques” et “CMS”. Et heureusement pour nous, les sites statiques sont à la mode, donc pas mal de gens ont travaillé sur la question ces dernières années ! Quand on est cool, on appelle ça une [Jamstack](https://jamstack.org/). Ici rien à voir avec la confiture ou des concerts de musique, JAM veut dire Javascript, API et Markup, et c'est issu de réflexion par des développeurs web sur l'architecture idéale pour développer des sites webs. Nous, on va prendre juste les principes qui nous intéressent dedans.
|
||||
|
||||
|
||||
Un premier principe, c'est un découplage entre le _front_, c'est à dire le site web que voient les internautes, et le _back_, c'est à dire l'interface qui permet de créer, modifier, ou supprimer du contenu. Un autre principe, c'est que le _front_ qui est présenté aux internautes doit être le plus _pré-calculé_ possible pour que ce soit le aussi rapide et économe que possible de charger une page web. À partir de ces deux principes, on a tout un ensemble de conséquences très désirables (bonnes performances, faibles coûts, sécurité, passage à l'échelle, mise en cache facilitée, etc.).
|
||||
|
||||
Maintenant qu'on a vu la théorie, passons à la pratique, et prenons ce (billet de) blog comme exemple ! Vous lisez ce billet depuis le _front_ qui est en réalité une série de fichiers HTML, CSS et Javascript. Ces fichiers sont stockés dans garage et ont été créés par un _générateur de site statique_, ici le vénérable [Jekyll](https://jekyllrb.com/), qui va transformer des fichiers [Markdown](https://fr.wikipedia.org/wiki/Markdown) en HTML. Bien sûr, Jekyll ne fonctionne pas tout seul, ni automatiquement, il faut le lancer à chaque modification. Pour automatiser ce lancement et l'envoi des fichiers, on va utiliser un _exécuteur de tâches_, ici [Drone](https://www.drone.io/). Maintenant, il faut bien stocker ces fichiers Markdown quelque part, pour ça on utilise Git, et plus particulièrement [Gitea](https://gitea.io). Enfin, parce qu'éditer ces fichiers Markdown à la main, et les envoyer dans Git, est une tâche fastidieuse, on a créer une interface _back_ qui permet de cacher toute cette complexité et proposer un environnement d'écriture.
|
||||
Maintenant qu'on a vu la théorie, passons à la pratique, et prenons ce (billet de) blog comme exemple ! Vous lisez ce billet depuis le _front_ qui est en réalité une série de fichiers HTML, CSS et Javascript. Ces fichiers sont stockés dans garage et ont été créés par un _générateur de site statique_, ici le vénérable [Jekyll](https://jekyllrb.com/), qui va transformer des fichiers [Markdown](https://fr.wikipedia.org/wiki/Markdown) en HTML. Bien sûr, Jekyll ne fonctionne pas tout seul, ni automatiquement, il faut le lancer à chaque modification. Pour automatiser ce lancement et l'envoi des fichiers, on va utiliser un _exécuteur de tâches_, ici [Drone](https://www.drone.io/). Maintenant, il faut bien stocker ces fichiers Markdown quelque part, pour ça on utilise Git, et plus particulièrement [Gitea](https://gitea.io). Enfin, parce qu'éditer ces fichiers Markdown à la main, et les envoyer dans Git, est une tâche fastidieuse, on a créer une interface _back_ qui permet de cacher toute cette complexité et proposer un environnement d'écriture.
|
||||
|
||||
Pour vous en convaincre, voici le tableau de bord :
|
||||
|
||||
|
||||
Et voici l'interface d'écriture pour un article :
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
À l'instant où je vais appuyer sur “Publier”, alors c'est tout le système qui va se mettre en branle automatiquement : mes modifications seront enregistrées (avec la gestion d'un historique pour pouvoir revenir en arrière), Drone va se lancer et construire les nouvelles pages de mon site web avec Jekyll, et ensuite les envoyer sur Garage.
|
||||
|
||||
Alors face à tout ces composants, on pourrait critiquer que ça ajoute une complexité importante, avec de nombreuses _pièces mobiles_ (_moving parts_ en anglais), c'est à dire des composants indépendants, qui ont leur propre cycle de vie, et qu'il faut pourtant garder _gluer_ entre eux.
|
||||
Alors face à tout ces composants, on pourrait critiquer que ça ajoute une complexité importante, avec de nombreuses _pièces mobiles_ (_moving parts_ en anglais), c'est à dire des composants indépendants, qu'il faut configurer pour faire fonctionner ensemble, et qui ensuite ont leur propre cycle de vie. Tout d'abord, ces composants ont des interfaces bien définies et relativement stables dans le temps, ensuite, ces configurations peuvent être automatisées et cachées. _In fine_, une plateforme bien intégrée peut très largement réduire la complexitée perçue, tout en laissant une flexibilité très importante pour quelqu'un qui aurait des besoins spécifiques.
|
||||
|
||||
Concrètement, aujourd'hui, vous pourriez vous demander quelles sont les étapes pour publier votre site statique avec un CMS sur Deuxfleurs ?
|
||||
|
||||
Tout d'abord, il faut préparer un dépôt git pour votre site web. Il vous faut commencer par choisir un générateur de site statique (Jekyll, Hugo, Zola, etc.). Souvent ces générateurs ont une commande pour initialiser le dépôt avec un squelette de fichiers (exemple : jekyll new mon-blog)
|
||||
|
||||
Ensuite, suivez [le guide de StaticCMS](https://www.staticcms.org/docs/add-to-your-site-cdn) pour intégrer le CMS à votre dépôt de site statique. Vous devriez avoir à la fin un dossier admin avec 3 fichiers : config.yml, index.html et static-cms-app.js (je vous conseille en effet de “vendorer” le fichier plutôt que d'utiliser un CDN). Notez que les informations de la section _backend_ sont spécifiques à Deuxfleurs et sont les suivantes :
|
||||
|
||||
```yml
|
||||
backend:
|
||||
name: gitea
|
||||
repo: <username>/<repo>
|
||||
base_url: https://teabag.deuxfleurs.fr
|
||||
api_root: https://git.deuxfleurs.fr/api/v1
|
||||
branch: main
|
||||
```
|
||||
|
||||
Vous devriez maintenant pouvoir valider vos modifications dans git, les pousser sur le dépôt, et lancer un serveur de développement local (exemple : `jekyll serve`). En accédant à [http://localhost:4000/admin/](http://localhost:4000/admin/) (pensez à adapter le port) vous devriez pouvoir accéder à votre interface CMS.
|
||||
|
||||
Une fois le CMS en place, vous pouvez configurer l'automatisation via Drone en ajoutant un fichier .drone.yml, puis en activant la CI sur votre dépôt, après avoir configuré les secrets pour publier sur Garage. Au final, vous pourrez ensuite travailler sur votre site web depuis l'URL complète de votre site, dans mon cas [https://quentin.dufour.io/admin/](https://quentin.dufour.io/admin/).
|
||||
|
||||
Bien entendu, nous pourrions imaginer une interface qui vous permettrait de choisir _un thème_ de site web, et qui vous créerait automatiquement le dépôt, avec les bons fichiers, et la configuration Drone qui va bien, de sorte qu'en moins de 5 minutes vous aillez un squelette en ligne sur lequel vous pouvez ajouter du contenu ! C'est pour une autre fois ça :-)
|
||||
|
|
|
|||
Loading…
Reference in a new issue