On pourrait ainsi héberger à part les trois parties.
Je vais partir de ce principe dans ma réponse :)
une interface d'administration en ligne comme grav/wordpress/drupal
Il y a deux approches à cette problématique :
- CMS pour site statique : un système qui s'interface avec tous les générateurs de site statique (génère des fichiers markdown avec frontmatter au choix en YAML/TOML/JSON) comme NetlifyCMS
- CMS agnostique, ou headless CMS : le système offre généralement une API pull (typiquement en JSON) avec webhooks sur certains événements (en gros un ping vers une page web quand ton continue change) ; j'imagine qu'il existe de tels CMS en pubsub mais ce n'est pas le cas de Directus avec lequel j'avais expérimenté parce que la doc est très fournie
un gros bouton "Publier" qui génère les fichiers statiques.
Ça ton CMS doit s'en occuper pour toi. Il doit savoir si un article est un brouillon ou prêt pour publication, et être capable de déclencher la compilation du site quand c'est nécessaire grâce à un webhook ou une autre forme de notification.
une partie publique dynamique optionnelle pour gérer les tribunes/commentaires/formulaires/...
Pour gérer les formulaires, il y a pas mal de solutions qui répondent à des besoins différents en terme de fonctionnalités :
- certains t'envoient les soumissions par mail comme Formspree ou Maily Form (idéal pour un formulaire de contact)
- d'autres utilisent directement l'API de Github (malheureusement!), comme staticman qui est à ma connaissance l'outil autohébergé le plus utilisé pour traiter les commentaires sur les sites statiques
- d'autres encore stockent d'elles-mêmes les données et t'exposent une API (typiquement JSON) pour accéder au contenu.
Pour s'attarder sur cette dernière approche (qui est très Keep It Simple Stupid), certaines personnes consomment alors directement le contenu côté client. Si c'est souhaitable pour du contenu évoluant rapidement (une tribune/discussion en temps-réel), c'est un gâchis de ressources (réseau et puissance de calcul) innommable que de faire ça pour les commentaires... en plus de casser la fonctionnalité pour les personnes qui n'utilisent pas Javascript dans leur navigateur. Cette approche complètement débile de l'industrie du web a son petit nom marketing : la JAMStack.
En revanche, consommée côté serveur, une API bien foutue qui stocke les données associées à ton site n'est pas du tout déconnante. Alors si tu veux à la compilation de tes templates récupérer l'ensemble tes commentaires sur une API JSON, c'est pas très scalable/écolo non plus. Par contre, si avant compilation du site tu récupères seulement les derniers éléments (depuis la dernière compilation du site) et que tu stockes ça directement dans le contenu (ou les data) de ton site statique sous une forme consommable localement par tes templates, là ça commence à avoir du sens ! D'autant plus si tu te débrouilles pour que l'apparition d'un nouvel élément déclenche automatiquement la compilation du site.
Cette dernière approche, je la trouve particulièrement intéressante pour gérer les intéractions Indieweb entre nos sites. Ça peut se construire avec webmention.io (hébergeur de webmention) grâce aux notifications IRC/Jabber intégrées, ou alors directement avec une solution maison autohébergée sur ton stack (les webmention c'est vraiment pas compliqué à implémenter).
Ainsi, tu peux afficher tes commentaires/intéractions sur ton site statique, y compris quand il est partagé sur d'autres réseaux que HTTP ! Typiquement, quand tu le partages sur une clé USB, ou sur IPFS, ou Freenet, etc...
Déso c'était un peu long mais condenser plusieurs années de réflexion/expérimentation en un paragraphe c'est pas mon fort x)
[^] # Re: Grav c'est cool
Posté par cmal . En réponse au journal Une tribune pour le CMS grav. Évalué à 3.
Je vais partir de ce principe dans ma réponse :)
Il y a deux approches à cette problématique :
- CMS pour site statique : un système qui s'interface avec tous les générateurs de site statique (génère des fichiers markdown avec frontmatter au choix en YAML/TOML/JSON) comme NetlifyCMS
- CMS agnostique, ou headless CMS : le système offre généralement une API pull (typiquement en JSON) avec webhooks sur certains événements (en gros un ping vers une page web quand ton continue change) ; j'imagine qu'il existe de tels CMS en pubsub mais ce n'est pas le cas de Directus avec lequel j'avais expérimenté parce que la doc est très fournie
Ça ton CMS doit s'en occuper pour toi. Il doit savoir si un article est un brouillon ou prêt pour publication, et être capable de déclencher la compilation du site quand c'est nécessaire grâce à un webhook ou une autre forme de notification.
Pour gérer les formulaires, il y a pas mal de solutions qui répondent à des besoins différents en terme de fonctionnalités :
- certains t'envoient les soumissions par mail comme Formspree ou Maily Form (idéal pour un formulaire de contact)
- d'autres utilisent directement l'API de Github (malheureusement!), comme staticman qui est à ma connaissance l'outil autohébergé le plus utilisé pour traiter les commentaires sur les sites statiques
- d'autres encore stockent d'elles-mêmes les données et t'exposent une API (typiquement JSON) pour accéder au contenu.
Pour s'attarder sur cette dernière approche (qui est très Keep It Simple Stupid), certaines personnes consomment alors directement le contenu côté client. Si c'est souhaitable pour du contenu évoluant rapidement (une tribune/discussion en temps-réel), c'est un gâchis de ressources (réseau et puissance de calcul) innommable que de faire ça pour les commentaires... en plus de casser la fonctionnalité pour les personnes qui n'utilisent pas Javascript dans leur navigateur. Cette approche complètement débile de l'industrie du web a son petit nom marketing : la JAMStack.
En revanche, consommée côté serveur, une API bien foutue qui stocke les données associées à ton site n'est pas du tout déconnante. Alors si tu veux à la compilation de tes templates récupérer l'ensemble tes commentaires sur une API JSON, c'est pas très scalable/écolo non plus. Par contre, si avant compilation du site tu récupères seulement les derniers éléments (depuis la dernière compilation du site) et que tu stockes ça directement dans le contenu (ou les data) de ton site statique sous une forme consommable localement par tes templates, là ça commence à avoir du sens ! D'autant plus si tu te débrouilles pour que l'apparition d'un nouvel élément déclenche automatiquement la compilation du site.
Cette dernière approche, je la trouve particulièrement intéressante pour gérer les intéractions Indieweb entre nos sites. Ça peut se construire avec webmention.io (hébergeur de webmention) grâce aux notifications IRC/Jabber intégrées, ou alors directement avec une solution maison autohébergée sur ton stack (les webmention c'est vraiment pas compliqué à implémenter).
Ainsi, tu peux afficher tes commentaires/intéractions sur ton site statique, y compris quand il est partagé sur d'autres réseaux que HTTP ! Typiquement, quand tu le partages sur une clé USB, ou sur IPFS, ou Freenet, etc...
Déso c'était un peu long mais condenser plusieurs années de réflexion/expérimentation en un paragraphe c'est pas mon fort x)