Bonjour Nal,
Je t'écris pour te présenter un plugin que j'ai eu à écrire pour le CMS Grav: il s'agit d'une tribune semblable à celle de linuxfr.
Conforme au standard coutumier des tribunes de la moulosphère, il est utilisable via la plupart des coincoins, tel que l'excellent QuteQoin:
J'espère que grav-plugin-tribune alias gpt prendra sa place parmi les bouchots facile à installer à côté d'un site comme l'était le plugin pour Drupal.
# Grav c'est cool
Posté par cmal (site web personnel) . Évalué à  3.
Grav est super intéressant, à mi-chemin entre les générateurs de site statique et les CMS à la Wordpress ! En gros, toutes les données exploitées par Grav sont stockées dans le dossier même de l'installation (
flat-file database) ce qui permet une sauvegarde ultra simple avec rsync & cie.Après, chaque étape finie de construction du site est judicieusement mise en cache pour permettre un chargement ultra-rapide des pages et des fonctionnalités… tout en gardant le côté dynamique de PHP qui permet de mettre en place des systèmes d'authentification/autorisation ou… ou autre chose j'imagine mais perso j'ai rien trouvé d'autre d'utile à faire avec un CMS lol
Écrire un thème pour Grav, c'est juste merveilleux avec le moteur de templating Twig. Et du coup pour les personnes qui ont l'habitude de trucs vraiment mal foutus (genre Wordpress/Drupal) c'est rafraîchissant d'utiliser une technologie qui a appris des erreurs du passé.
Perso, mon expérience a été de passer de Wordpress à Grav, puis à des générateurs de site statique, car je me suis rendu compte qu'un générateur me permettait de faire tout ce que je faisais déjà avec un CMS complet, mais avec moins de risques de sécurité (pas besoin de stresser pour les mises à jour) et moins d'impact écologique (générer tes pages une fois c'est plus écolo que les générer à chaque requête ou de faire tourner une surcouche PHP avec un cache APCU).
Bref, si tu veux absolument utiliser un CMS en PHP, essaye Grav. Y'a des chances que tu kiffes graves x). DĂ©so c'Ă©tait un peu hors sujet mais j'essayais de donner un peu de contexte au journal :D
[^] # Re: Grav c'est cool
Posté par devnewton 🍺 (site web personnel) . Évalué à  3. Dernière modification le 17 septembre 2018 à 13:59.
Tu as taisté ce plugin pour faire de grav un générateur statique https://github.com/BarryMode/grav-plugin-blackhole ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Grav c'est cool
Posté par cmal (site web personnel) . Évalué à  2.
Nope, ça existait pas encore à l'époque où j'utilisais Grav :D
De fait, j'ai adopté des solutions plus minimales et plus adaptées à mon usage, d'abord avec hugo, et maintenant avec gutenberg (qui ne va pas tarder à être renommé zola).
De fait ce qu'il manque dans certaines situations (pour faire administrer le bousin au quotidien par des personnes sans formation spécifique) c'est un CMS par-dessus avec une gestion des autorisations. NetlifyCMS remplit pas mal cet usage, mais faire tourner une webapp avec un backend NodeJS pour ça c'est overkill. De plus, git est chelou pour ce genre d'usage puisqu'il n'a pas de gestion des permissions et permet à n'importe quel personne qui peut écrire dans le dépôt de réécrire l'histoire. En bref ce genre de stack c'est du bidouillage. On a beaucoup de marge pour améliorer le status quo ! :)
Sinon, pour des personnes (qui peuvent partager des identifiants) qui ont un minimum l'habitude des outils numériques (études/secrétariat/communication), gérer le site depuis l'interface web de Gitlab/Gitea passe très bien. Créer un dossier pour l'article, uploader les photos dedans, mettre un
index.mdet c'est parti que le script d'intégration continue s'occupe du reste ![^] # Re: Grav c'est cool
Posté par Graveen . Évalué à  2.
Tu peux préciser ce qu'est un generateur de site statique ?
Je reviens un peu au web en ce moment. J'hésite entre partir sur du Wordpress (mais ca me semble lourd… trés lourd… trop lourd !) ou un truc plus sympa comme Grav.
Merci de ton feedback :)
[^] # Re: Grav c'est cool
Posté par Alcyone . Évalué à  4. Dernière modification le 18 septembre 2018 à 13:53.
On oppose souvent Static Site Generator (SSG) et Flat-File CMS bien que l'on mélange souvent les deux.
Pour le coup, si un générateur de site statique voit sa logique complètement désolidarisé du serveur qui hébergera le site, ce n'est pas le cas du Flat-File CMS qui embarque la génération et l'administration, le point commun (qui est aussi le point de confusion) entre les deux étant l'absence de base de données.
Que choisir ? Ma foi j'en sais rien du tout :')
J'ai touché un minipeu Grav en Flat-File CMS et Hugo en SSG, ma foi c'est plutôt sympa. J'ai entendu pas mal de bien de Pelican sur lequel je zieute pour la prise en charge du reStructuredText et de AsciiDoc mais j'ai pas encore touché.
P.S. : on en trouve aussi ici
Alcyone
[^] # Re: Grav c'est cool
Posté par cmal (site web personnel) . Évalué à  2.
Comme le dit Alcyone, le générateur de site statique ne s'occupe pas de la gestion du contenu. Pas d'interface d'édition embarquée, pas de gestion des utilisateurices et des permissions, etc… Ce sont des outils à destination des personnes qui ont des besoins éditoriaux minimaux (identification par git + publication de fichiers sans ACL et sans modération) ou qui ont les moyens de développer/adapter une infrastructure en amont pour gérer ces questions.
En gros, le générateur de site statique, quand tu lances la construction du site, te produit un dossier de pages HTML que tu peux héberger n'importe où… y compris sur d'autres réseaux que HTTP, par exemple IPFS. Ce sont des outils vraiment stylés qui remplissent une fonction importante dans la diffusion de l'information : mettre en forme le contenu (et rien de plus).
Du coup c'est Ă toi de voir dans quelle direction tu veux te lancer. Mes conseils perso selon la direction que tu veux prendre:
- instance ActivityPub : Plume est un moteur de blog fédéré assez stylé et en développement actif
- CMS complet : Grav est (ou du moins était) délicieux à utiliser au quotidien et les devs étaient dispo et sympa. Mais faut kiffer le côté interface d'administration full-JS qu'il faut une bête de guerre pour faire tourner dans ton navigateur lol
- Générateur de site statique : Gutenberg est à mon sens le meilleur compromis. Léger et rapide, intègre un compilateur Sass vers CSS. Le système de thèmes est pas du tout utile en l'état (mais y'a pas forcément besoin). Pas d'internationalisation pour le moment (ça arrive), et encore plein de bugs et de trucs à polir mais le système de templating est prévisible et agréable, et plutôt aidant dans ses messages d'erreurs je trouve. Le code de Gutenberg est par ailleurs juste très lisible même s'il reste très perfectible.
hugo est plus rapide et a beaucoup plus (trop!) de fonctionnalités, mais son moteur de templating est une catastrophe intergalactique. Faut se préparer à passer des heures et des heures à débugger tes templates avec des messages pas du tout informatifs et un système d'héritage de contexte complètement retourné du cerveau… et pas de vrai système de macros ! Après si tu as besoin d'internationalisation (i18n) et de plusieurs types de contenus à gérer (content kinds / custom output formats), hugo reste un outil extraordinaire pour parvenir à tes fins !
[^] # Re: Grav c'est cool
Posté par devnewton 🍺 (site web personnel) . Évalué à  2.
J'utilise Hexo pour mon blog qui marche bien, mais je trouve qu'il manque un un CMS qui ferait Ă la fois du statique et dynamique:
On pourrait ainsi héberger à part les trois parties.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Grav c'est cool
Posté par cmal (site web personnel) . É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)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.