[DRS] DRS pour Chroniques oubliées ? 598

Au cas où t'aurais pas compris justement BBE as dit que pour le moment ils n'avaient pas les ressources (temps, argent, expertise juridique) pour "juste" dire quoi mettre ou pas...inutile donc de rabâcher que c'est "facile" a faire et de mendier pour "rigoler"

Je vous ai mis le backup du site ici (lien qui ne va rester en ligne que 30J), au besoin : https://transfert.free.fr/QgiXXRM

Ce n'est pas une solution en soi, même si c'est partiellement navigable en local, c'est juste un backup / une archive pour que tout ne disparaisse pas soudainement.

A noter que ce n'est à priori ni plus, ni moins que ce que propose archive.org, accessible en ligne ici : https://web.archive.org/web/20230000000000*/https://www.co-drs.org/fr

(celà dit il y parfois des pages ratées / non sauvegardées par archive.org, surtout tout ce qui est fichiers additionnels, pages rarement accédées, etc.) (mais archive.org a l'intérêt de permettre de remonter dans le temps et de voir les évolutions, selon les prises de photo qu'archive.org aura prise).

Je viens d'aller voir les fichier .md de Nioux .. alors y a des bon éditeur de markdown (même online)

Mais le pére Nioux. il a une bonne ceinture noire de MarkDown.

https://github.com/Nioux/HD

Les fichiers sont en vrac telquel à mon gout (euh les chemins relatif en MD .. ca march Nioux ) ... mais vous pouvez voir que chaque fichier demande du travail.

A la différence d'un wordpress ou tu auras les éléments dans des articles que tu pourras que taggué et pourquoi pas reprendre dans des pages statique .. la les éléments sont dans des fichiers .md que tu peux modifier un par un ajuster et en fait si tu architecture bien, c'est une base locale .. qui pourront ensuite si tu le veux, aller nourir une base de données .. ect, ect .. l'important c'est de commencer modeste.

Par contre ça t'oblige a "comprendre" MarkDown .. mais aujourd'hui c'est un standard de présentation de texte qui évite la lourdeur d'écriture du HTML pur texte.

Il y a déjà eu il y a 7ans des consignes sur le contenu a mettre ou pas. Bbe a dis qu'il n'avait pas le temps d'étudier la nouvelle proposition de Nico il n'ont pas remis en cause le site tel qu'il est actuellement

Mais concernant mes message précédent je me suis clairement mal exprimé.
Jai écrit : refaire un site basique de type co-drs
En fait en disant co-drs je parlait pas du site en lui même mais de l'idée de base a savoir : "avoir un drs consultable sur le net de CO"
J'aurais du donc ecrire : refaire un site basique de drs avec aucune interaction, juste un site vitrine

Faut pas se fier à mon markdown "custom" : tous les tags "pseudo html comment" sont utilisés par une moulinette pour ajouter des meta données et des séparations de page pour mon app. J'ai utilisé des commentaires html bidouillés justement parce qu'ils sont ignorés par github. Et si je devais le refaire, je ferais différemment (fichiers séparés par page, et markdown + yaml sans doute)

Le markdown tout seul, c'est simple

https://docs.github.com/fr/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

Voumavécomplétemenperdus

C'était juste un début de discussion pour trouver une solution durable et résiliente pour un nouveau co-drs

Les repos comme github et gitlab offrent l'avantage de solutions gratuites pour les projets "libres", avec un historique, la possibilité de faire autant de branches qu'on veut, multi utilisateurs, etc...

Donc plus du tout de risque de fermeture à plus ou moins long terme.

Et le markdown est devenu une référence pour du texte enrichi, qui est justement supporté par ces deux repos, normalement pour la documentation des projets.

Une alternative gratuite et open-source aux solutions américaines : Codeberg est hébergée en Allemagne et est basé sur le logiciel Gitea.

• https://codeberg.org/
• https://european-alternatives.eu/product/codeberg

Vous êtes sur la bonne voie (quand il a été évoqué de reconstruire le site du DRS CO à partir de fichiers markdown), mais je pense qu'il faut aller un cran plus loin.

J'ai déjà expliqué çà sur le topic CASUSNO qui traite de ce même sujet (fermeture du DRS CO), quand je pensais (totalement à tort !) vu les premiers échanges que le coeur du problème était le coup d'hébergement (alors que pas du tout = ce n'est pas pour çà que le site va fermer).

Mais comme il semble y avoir des bonnes volontées motivées ici pour refaire quelque chose ailleurs, çà vaut peut-être le coup que je (re)détaille un peu. J'ai essayé de ne pas être trop technique, pour ceux étrangers au sujet.

La solution idéale pour ce genre de cas (vu la nature du site, le fait que plusieurs personnes puissent participer, qu'il faille quand même tant qu'à faire avoir les coûts d'hébergement et de maintenance les plus faibles possibles, etc.) est sans doute quelque chose de ressemblant à çà.

Etape 1 - Recréer le contenu du site en MARKDOWN.

Le MARKDOWN, pour ceux qui ne connaissent pas, c'est une manière d'écrire facilement et de manière ouverte un contenu quelconque, en se focalisant sur le texte pur et en ajoutant un minimum de "balisage" pour indiquer comment certaines parties du texte doivent être présentées (un titre, une partie en gras, etc.). En pratique c'est simplement du texte pur (éditable avec n'importe quel logiciel, notepad.exe, Word, VSCode, une plateforme en ligne, ...), éditable de manière "brute" (en écrivant le balisage à la main - dès lors qu'on le connaît un peu, çà vient très facilement) ou visuelle (comme dans Word).

Il y a tout un tas d'avantages :

• çà permet de séparer autant que faire se peut le texte lui même de la manière dont il sera affiché au final
• c'est éditable de n'importe où / n'importe comment
• c'est "ouvert", en ce sens que ce sera toujours éditable dans le futur (il ne pourra pas y avoir un "lock-in" lié à un logiciel propriétaire)
• c'est de nos jours très largement répandu, d'ailleurs de nombreux forums ou sites communautaires (reddit, ...) ont leur zone d'édition en markdown maintenant

C'est tout à fait adapté à un site contenant surtout du texte au final, comme CO DRS.

Par contre il n'est pas possible de faire facilement des choses "complexes" (ex. : une fiche de personnage éditable ne sera pas faisable en markdown, il faudra faire du HTML/JS, par ex.)

Etape 2 - Créer l'ensemble du site via un générateur de sites statiques comme HUGO, y compris les parties "bases de données"

Cette étape consiste à "habiller" le texte construit à l'étape précédente pour avoir un rendu aussi sympa que celui de CO DRS à l'heure actuelle, et de gérer les aspects "bases de données" (mais sans avoir besoin d'installer / configurer / définir un logiciel de base de données !).

Pour le rendu, il suffira de créer un "template" (en s'inspirant d'un template existant en ligne, ou en partant de zéro : c'est juste du HTML/CSS/JavaScript (au besoin)). Ce template sera appliqué sur chaque page de texte écrite en markdown.

C'est ce que font les logiciels appelés "générateur de sites statiques". HUGO est le plus connu / a probablement la plus grosse communauté.

Pour l'aspect "base de données", il y a dans HUGO un mécanisme pour les données - l'exemple du tutorial est du type "un site listant un ensemble de films avec toutes les infos navigables sur films, acteurs, réalisateurs, etc. (qui a joué dans quel film, ...)

Merci pour ces infos super intéressantes.

Tu décris 5e DRS, c'est bien .

En quelques mots : on définit les données dans un fichier texte (YAML typiquement, ou éventuellement autre chose (JSON, ...)) - le YAML, c'est juste du texte avec des listes à tiret et des noms d'attributs.
Ensuite HUGO prend les entrées de ces fichiers textes, itère sur les entrées, et les injecte dans le site selon ce qui est définit dans le template : on pourra vouloir une table classique (façon EXCEL) dans certains cas, ou alors, bien sûr, des "cartes" (une carte par entrée d'un bestiaire).

Pour les templates, il y en a de nombreux disponibles un peu partout sur le web (en guise d'exemple, ou de point de départ).

Etape 3 - Publier le site en ligne

En sortie de l'étape 2 (la génération du site) on a donc un ensemble de fichiers web classiques totalement statiques (HTML, JS, CSS, images, ...).

Il est dès lors possible de les héberger absolument n'importe où (et c'est ce qu'il y a de plus simple à héberger) :

• Sur une offre web d'entrée de gamme de n'importe quel hébergeur (OVH, INFOMANIAK, ...)
• Sur "GITHUB pages" (= uniquement la partie "hébergement de pages statiques" de github sera nécessaire, pour faire office de publication, et rien d'autre))
• Dans un VPS d'entrée de gamme (machine virtuelle dans le cloud) avec un container docker faisant tourner HTTPD ou CADDY (çà devient un peu plus technique, mais c'est juste pour illustrer)
• etc.

C'est pour çà que la question "GITHUB" ou "GITEA" ou "GITLAB" ou je ne sais quoi n'a pas de sens - avec ce genre de workflows :

• Les sources du site sont sauvegardées quelque part, et ce n'est pas très important / structurant (NEXTCLOUD ou GIT, etc.)
• Les pages générées sont poussées n'importe où, en hébergement classique, et ce n'est pas très important / structurant non plus (il est facile de changer pour un hébergement moins cher, etc.)

Avantages

• Le coût d'hébergement est vraiment minimal (pas de licences wordpress, coûts d'hébergements réduits car il n'y a aucune dépendance et aucun besoin de "puissance" / pas de besoin de langages dynamiques, etc.)
• Le coût de maintenance est vraiment réduit (pas de montées de version Wordpress à faire, pas de montées de versions de la base de données, ...)
• Il n'y a aucune faille de sécurité possible (pas de hack possible, ...) (vu que tout est statique)
• Le site publié a la disponibilité la plus élevée possible (= celle de l'hébergeur), il ne peut quasi pas "planter" à l'usage
• Tout est automatisable facilement pour publier d'un click
• Il n'y a pas besoin de backups des fichiers publiés (au pire, il suffit de les repousser en ligne en sortie de l'étape 2), pas de backup de configuration ou de bases de données, etc.
• Comme dit précédemment, tout ou partie est facilement migrable ailleurs extrêment facilement et sans devoir tout reconstruire / exporter

Inconvénients

• Le ticket d'entrée peut sembler élevé pour un non-technicien, mais très honnêtement, c'est même plus simple que d'installer Wordpress / une base de données
• Ce n'est pas adapté aux bases de données très complexes
• La partie "moteur de recherche" nécessite un peu d'attention (pour avoir une recherche dans le site lui même, il faudra activer un mécanisme d'indexation à la génération du site (étape 2) couplé à un moteur de recherche javascript intégré dans le template)
• La partie "commentaires" doit se faire autrement : il y a des scripts communautaires (à intégrer dans le template), ou sinon utiliser une plateforme tierce comme Disqus (ensuite tout çà s'intégrera très bien dans chaque page où on veut des commentaires)

HUGO : https://gohugo.io/

Exemple de site généré avec HUGO (il y en a beaucoup d'autres) : https://www.nginx.com/
Vous pouvez voir que c'est très propre, avec différents types de rendus / layouts / navigations, etc. Evidemment c'est un site "technique", donc très sobre niveau mise en page, il faut l'imaginer habillé façon CO-DRS (mais c'est donc tout àf ait possible).

(désolé pour le post en deux messages, je n'avais pas vu que le forum m'avait tronqué la moitié)

Espèce de vil DevOps ! 🤣🤣🤣

Il faut comprendre que pour qui n'est ni dev ni devOps, ce schéma de pensé est fort peu convivial et le ticket d'entrée dont tu parle n'est pas technique mais bien conceptuel.

A moins d'être "de la partie", quelqu'un qui qui veut faire un DRS sera pour moi bien plus à l'aise avec un Wiki ou du HTML simple et assisté type WIX qu'à héberger, je te rejoins là dessus, un site sur GIT (Je te laisse leur expliquer le init, clone, fetch, pull et push, et avec un peu de chance rebase et ça part en live ... lol)

Je trouve génial le fait de passer les feuilles web pur lire tout de même les données. Mais, si tu dois arrêter, peux-tu aussi donner les bases de données ?

Merci pour ton travail, même si je n'utilise pas tout !

Il y a méprise sur la personne. SRG408 n'est pas celui qui tient le site CO DRS. Il a seulement fait un backup de ce à quoi il a accès, à savoir la même chose que tout le monde. Pour cela il a automatisé l'enregistrement de toutes les pages html et des ressources associées. C'est donc une copie incomplète, parce qu'à part Nico de CO DRS, personne n'a accès aux fichiers dynamiques du site, ni aux bases de données.

Il y a aussi asciidoc qui est plus puissant en termes de possibilité de mise en forme (notamment les tables) et reste aussi simple à apréhender que markdown. Le problème avec markdown, c'est qu'il en existe plusieurs variantes qui cherchent justement à compenser les lacunes du markdown de base.

Dans notre boîte, nous avons migré nos manuels pour les utilisateur depuis Word vers de la génération à partir de fichiers asciidoc grâce à ce genre d'approche. Et bien markdown était vraiment trop limité pour obtenir un résultat proche de Word (et quand je dis limité c'était vraiment très limité). Markdown c'est bien pour des choses très simples comme les readme et certaines instructions sur Github (désolé pour ce charabia technique pour les non connaisseurs).

Bonjour tout le monde,

Je ne sais pas si ça servivera, mais j'ai fais un exel qui récapitule des classes et des races avec leurs voies pour que mes joueurs les retrouvent facilement. Avec la fermeture prochaine de CO DRS je partage le lien cela peut dépanner :

Récap des classes et des Voies COF

sympa mais c'est en mode lecture seule , pas de possibilité de télécharger...

Bonjour à tous,

Voici ma réponse suite aux échanges avec BBE concernant la fermeture de CO DRS et mes réflexions sur les perspectives à venir. Merci encore une fois pour votre soutien !

Réponse à BBE - Quel avenir pour CO DRS ?