forked from quentin/quentin.dufour.io
Update Article “2023-02-28-staticcms-une-autre-approche-aux-cms”
This commit is contained in:
parent
906b0374f1
commit
cc3d12fc89
1 changed files with 13 additions and 8 deletions
|
@ -13,18 +13,23 @@ 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. Ce concept est issu de réflexions par des développeurs web sur l'architecture idéale pour développer des sites webs. Nous, on va se contenter de garder les principes qui nous intéresse là dedans.
|
||||
|
||||
![](/assets/screenshot-2023-02-28-at-14-47-22-for-fast-and-secure-sites-jamstack.png)
|
||||
|
||||
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.).
|
||||
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 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, nous y voilà, je parle bien de [StaticCMS](https://www.staticcms.org/).
|
||||
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, nous y voilà, je parle bien de [StaticCMS](https://www.staticcms.org/). Lors de votre travail de publication, vous n'aurez pas besoin de vous soucier de tout ces composants. Comme avec Wordpress, vous allez simplement intéragir avec une interface web de gestion de contenu.
|
||||
|
||||
Pour vous en convaincre, voici le tableau de bord :
|
||||
Pour vous en convaincre, voici le tableau de bord de notre CMS :
|
||||
|
||||
![](/assets/20230228_15h03m03s_grim.png)
|
||||
Et voici l'interface d'écriture pour un article :
|
||||
|
||||
Et voici son interface d'écriture :
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
![](/assets/20230228_15h02m40s_grim.png)
|
||||
À 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.
|
||||
|
@ -33,9 +38,9 @@ Alors face à tout ces composants, on pourrait critiquer que ça ajoute une comp
|
|||
|
||||
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)
|
||||
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 :
|
||||
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 à votre hébergeur, pour Deuxfleurs voici les paramètres à configurer :
|
||||
|
||||
```yml
|
||||
backend:
|
||||
|
@ -48,6 +53,6 @@ backend:
|
|||
|
||||
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/).
|
||||
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