Sacré programme… Félicitations à toi de t’y coller.
J’ai juste 2 questions par rapport à l’avenir : est-ce qu’il sera facile de maintenir ce site à jour (sans devoir passer par les étapes de validation trop lourdes qui font qu’il y a encore des MR vieilles de plus d’un an sur le site actuel) et est-ce qu’il sera facile pour quelqu’un d’autre de reprendre/maintenir tout le travail que tu vas faire ?
C’est l’objectif, oui.
Quelques indications pour donner confiance dans le fait que ce sera le cas :
Je souhaite justement éviter une n-ième situation où nous serions incapables de gérer les contributions sur un site web qui est au cœur de notre identité en ligne (ma contribution sur le site multilingue n’avait pas pu être acceptée à l’époque).
De plus, je souhaite me servir du site duniter comme support pour vulgariser la RFC en vue d’une ré-écriture et pour faciliter des projets tels que celui-ci.
Les amis, il y a du nouveau. J’ai écrit un script de migration de Pelican vers Zola (https://git.42l.fr/HugoTrentesaux/pelican_to_zola) qui gère pas mal de choses.
Le résultat est que j’ai pu conserver les pages et articles Markdown de l’ancien site à quelques fonctionnalités manquantes près :
Vous pouvez consulter :
pour vous faire une idée.
Même si ça a l’air bien avancé, ne vous fiez pas aux illusions, il me reste encore beaucoup de travail pour que le site soit réellement exploitable (et surtout documenté). Le script devrait permettre de gérer facilement les changements qui seront faits entre temps sur les articles, je suis basé sur le commit d12f64f2a50cefc1b722f7b3460e14f6e6bdfb3b pour info.
Il y a quelque temps je me disais qu’il faudrait que je me documente sur Pelican, dans le but de participé à la maintenance des sites web.
Aujourd’hui je vois qu’il faudrait plutôt que j’étudie Zola.
Je n’arrive pas à suivre, j’ai plusieurs train de retard.
Ou peut-on trouver des explication sur Zola? Parce mes recherche me renvoie vers un écrivain 
Merci!
Je vois que c’est encore en anglais! Je crois que je vais laisser faire les pros…
@Maaltir comme promis, je vais écrire (en français) une documentation spéciale pour contribuer sur le futur site web de Duniter. Je veux bien t’accompagner dans ton apprentissage, j’ai déjà écrit un « quickstart » pour Zola en anglais et en français (
). Si tu as des questions, tu peux également les poser sur le forum de Zola. L’auteur de ce logiciel est français (de Nice), donc pas de problème pour parler français.
Ok je vais regarder çà!
Mais je vois bien que j’ai beaucoup de wagon à rattraper… Gros boulot pour moi.
Si tu veux qu’on se fasse une petite séance de formation en partage d’écran, c’est possible quand tu veux 
mais si tu veux juste contribuer au site et pas forcément apprendre Zola, il vaut mieux attendre que je documente l’ensemble.
Super initiative la refonte du site !
Curieux que zola utilise +++ pour frontmatter au lieu de --- comme la plupart des SSGs markdown…
Dommage de ne pas utiliser un moteur de site statique en javascript. Je ne comprend pas l’intérêt vu que les navigateurs sont en js. C’est quand même top de pouvoir intégrer des composants js dans du markdown et du markdown dans du js !
Sinon, il serait peut-être aussi pas mal de sortir les fichiers .md du contenu du site ?
Au lieu d’avoir le contenu dans le dépôt du générateur de site ici : https://git.duniter.org/websites/website_fr/-/tree/master/content
Ce serait mieux d’avoir un dépôt dédié au contenu, et un autre dédié à la génération du site. C’est SoC (Separation of Concern). D’un côté le text du site : la data, et de l’autre le générateur : le code. Ce sera mieux pour les contributeurs non techos, et pour les devs afin de générer le site avec différents moteurs de SSG (ça évolue vite tout ça…).
Ce sera aussi plus simple pour plugger wiki.js si il y a besoin. J’ai testé wiki.js seulement, jamais utilisé en prod. Je ne me sens pas d’installer ça de suite, et c’est peut-être un peu prématuré ?
Par contre, je peux installer un nuxtjs avec PWA (mobile et offline) et nuxt content en 2-2 
Je me dis que ce serait même génial pour merger le contenu du site en markdown avec un moteur de recherche de liens comme veut le faire infojune.fr
Avec nuxt content, tu lui donnes un json avec des liens structurés par exemple, et il fournit une API. Pratique pour faire un moteur de recherche ou des listes…
Merci
La plupart des navigateurs peuvent interpréter du javascript, mais :
Comme tu vois, aucune réponse n’est un argument marteau, mais c’est une somme qui me fait préférer d’éviter ça.
C’est “mieux” théoriquement d’un point de vue bonnes pratiques, mais en vrai, c’est sacrément chiant. Tout simplement parce que le contenu et sa mise en forme sont assez intriqués, on a souvent besoin de changer les deux en même temps, et ça fait deux fois plus de commits à faire, trois si on compte le thème. C’est pourquoi après beaucoup d’expérience dans ce domaine, je préfère de loin avoir le thème, le contenu, et la config du site au même endroit.
Non, au contraire, ça le perd encore plus.
C’est faux aussi. Même si le contenu est écrit en markdown dans tous les cas, la façon de l’organiser, les métadonnées, la manière de lier les fichier statiques, les shortcodes spécifiques au SSG rendent la migration fastidieuse. Ce n’est pas pour rien que je travaille sur un script de migration, si c’était aussi simple que de drag and drop d’un dossier à l’autre, tu te doutes bien que je ne m’embêterais pas à écrire un script pour ça.
Ça reste à prouver. Fais les deux et reviens me voir après.
Ça dépend. Si on le pense comme un projet indépendant, ça peut arriver n’importe quand. Si on veut l’intégrer au site, il vaut mieux attendre un peu, oui.
Oui, comme toujours on peut faire un tas de choses, ce qu’il faut, c’est savoir pourquoi telle chose est pertinente ou non et si on aura les ressources humaines pour le maintenir à long terme. Oui, il y a plein d’outils pour faire des tas de trucs et ils sont tous mieux conçus et plus astucieux les uns que les autres, mais non, on n’a pas envie de diversifier excessivement parce qu’après c’est ingérable. Donc avant de proposer le prochain trucjs à la mode qui s’installe en un clin d’œil, essaye de répondre aux questions suivantes :
Je veux bien faire un rappel sur les points qui ont guidé mon choix de techno :
Après ce très long message, j’aimerais ne plus avoir à parler de choix technologique sur ce sujet. Je préfère me concentrer sur la refonte du site (qui a avancé, je vais écrire un prochain message).
Bonjour les amis, voici le temps du deuxième update. J’ai quelques questions à vous poser :
Par rapport aux tables des matières, j’en ai inséré une systématiquement dans chaque page et ai laissé les balises [TOC]. C’est donc normal si elles se baladent dans la nature. J’attends de voir si j’ai suffisamment bien effectué la migration pour pouvoir me détacher du contenu original et retravailler le contenu du site lui même sans avoir à régler des conflits de migration.
Prochaine étape :
Étape d’après :
Étapes ultérieures à la mise en service (nouvelles fonctionnalités) :
J’en ai fait très peu moi-même, donc ça ne me dérange pas de les refaire avec un outil externe, par contre je ne pense pas que @cgeek aura le temps de refaire tous ses schémas, et je ne me sens pas de le faire a sa place, donc on va perdre des schémas, a voir quels sont les plus importants à garder, et lesquels on peut se permettre de perdre.
Perso je la trouve pertinente sur le fonds, après sur la forme ça m’est égal, donc ok pour une version sans mise en page 
Je ne suis pas sûr d’avoir compris ce que l’on doit vérifier, quand je http://duniter.trentesaux.fr/ la plupart des liens pointent sur la page courante avec un # en plus donc ils sont presque tous cassés ou juste pas migrés ? Quand a la mauvaise mise en page je suis nul pour repérer ce genre de truc 
Je trouve que c’est un plus qui aide beaucoup a la navigation. C’est une fonctionnalité que j’apprécie beaucoup lorsque je navigue sur un nouveau site. Ce n’est bien entendu pas indispensable, mais je trouverai dommage de perdre ça.
Avec le validateur, on voit quelques problèmes pouvant causer des bugs de mise en page pour certains navigateurs (surtout des attributs width avec unités, qui devraient être remplacés par du CSS, mais bizarrement Firefox supporte ça).
Edit: quelques problèmes d’accessibilité et référencement aussi
Oulà, je disais juste ça à titre de conseil…
Loin de moi vouloir troller, mais la somme est nulle, pas un de tes arguments n’est juste :
Va sur la doc de silkaj réalisé avec vuepress, désactive le javascript : le site est le même !
Juste la navigation n’utilise pas l’api html5 pour le routage, mais ça recharge la page au lieu de naviguer directe ; régression transparente.
62.8 KB de js, ça va ton vieux téléphone et firefox peuvent tenir le coup… (ce forum utilise 4.2MB de js).
Toutes les balises meta et le sitemap sont construit au compile time, c’est SEO friendly. C’est pas le client qui travaille, c’est ton ordi lors de la compilation. Tous les calculs sont justement fait en amont, même pas de serveur, c’est quand même mieux en conso énergétique. Mais bon, zola fait ça aussi. Je pense qu’il y a une incompréhension sur ce que fait réellement le javascript… un SSG javascript peux comprendre le javascript dans un fichier markdown au compile time, charger les composants dont à besoin la page et les intégrer directement pour le runtime. Zola, Hugo, Pelican, Jekyll… et autres SSG non js ne peuvent pas faire ça.
Avec nuxt, tu peux commencer le site en statique, puis passer en PWA ou en SSR en changeant juste un paramètre. C’est fait pour évoluer en fonction des besoins et la taille du site…
Benchmark :
http://duniter.trentesaux.fr ← 18 requests, 7 fichiers css, 1.2MB
https://mystifying-nobel-66ae54.netlify.app/fr/ ← 17 requests, 1 fichier css, 588 KB
Et encore, les perfs sont plombées par la taille des images… Bon ok, ce site fait en 2020 à du javascript, ça craint. Par contre tu l’installes sur ton smartphone comme une appli web, et tu navigues hors ligne… Perso je préfère plutôt désactiver le wifi que javascript, mais là tu peux même faire les 2
Côté allergique à js, tu fais yarn dev au lieu de zola build dans ton bash et tu créés le site en live sans recharger le site, il te suffit juste d’oublier que c’est du js en fait…
Côté séparation contenu, c’est justement pour éviter ce genre de problème. Chacun pourra compiler le site avec le moteur SSG de son choix…
Si le contenu est couplé avec la mise en forme, c’est qu’il y a un problème SoC (Separation of Concern) avec ton SSG. Pour les nons techos, c’est quand même plus clair de ne pas avoir d’autres fichiers que les fichiers du contenu en .md. En terme de gestion du site, ils n’ont pas à ce soucier d’avoir des commits et issues sur le code au milieu d’issues et commits sur le contenu… c’est pas pour rien que tous les gros outils open source font comme ça pour leurs docs ! Il n’y a qu’à parcourir github…
Enfin, tu peux avoir un fichier markdown que n’importe quel rédacteur à l’aise en markdown peut comprendre :
<breadcrumb />
<toc />
# Bienvenue !
La **june** compte actuellement **<g1-members-count /> membres**.
Le dividende est de <g1-dividend />.
Les composants mettent à jour automatiquement listes et compteurs. Pas une ligne de js. Et tu peux compiler ça pour du vuejs, react, svelte… peu importe ! Pas besoin de scripts de migration et autres shortcodes… c’est juste du html + md. Pas besoin de templates et autres {% extends %} séparant le contenu de la vue…
Pour les devs se sera aussi plus simple.
Tout ça n’est pas que le dernier trucjs à la mode. Tu as déjà utilisé gatsby, vuepress ou du headless cms comme strapi ? Moi oui et depuis longtemps, et je comprend tout l’écosystème que c’est mis en place autour des SSG, headless ou JAMstack…
Les points qui guident mes conseils sont aussi une grande expérience, des outils low tech et rapide (vitejs avec vue3, c’est de l’import de module en natif. Ça peut pas être plus rapide, c’est natif !). De la compilation sass, less, postcss… depuis le composant direct (encore SoC), avec assurément plus de fonctionnalités (RSS, breadcrumb et import uml et surtout du PWA !) et utilise un language à la base fait pour le web et pas pour les serveurs.
En terme de maintenance pour les 3 prochaines années, ce sera sûrement plus simple à gérer et évolutif qu’un outil qui ne respecte pas les standards front matter, fait pas d’i18n et n’utilise pas les dernières avancées du web (build modulaire js et css, HMR, PWA, import js natif…).
Maintenant, je dis tout ça juste à titre de conseil justement pour expliquer pourquoi telle chose est pertinente ou non… Mais j’ai l’impression de rentrer dans une gueguerre de specs techniques que je ne pensais pas générer avec mon précédent post…
Bref, j’émettais seulement des idées et proposais d’installer tout ça avec nuxt. Vu la réaction, je sais plus… Je le ferais plutôt plus pour monnaie-libre, et assurer la construction et maintenance du générateur, pas forcément du contenu.
Pour la mise en place j’ai pas la main, @moul doit faire une CI avec gitlab pour la doc Silkaj pour que ce soit sur “nos” serveurs. En attendant, l’hébergement gratos installé en 5 min sur netlify marche toujours très bien depuis des mois…
Tout ça à définitivement à voir avec le 1er post de ce topic : boucles de rétroaction trop longues, processus conflictogène… Chacun fait à sa sauce sans concertation et avec ses convictions… et c’est toujours aussi difficile de savoir qu’est-ce qu’il y a à faire et qui fait quoi dans le process de cette ML…
Pour pouvoir fonctionner en réseau, il faut de la transparence.
Bref, j’adhère à 100% aux remarques de @anon88550267 !
Oups, je me suis mal exprimé. Les schémas actuels sont conservés en tant qu’images, et le code est là aussi. C’est juste que si on veut les modifier, il faudra les recompiler avec un outil externe car Zola ne gère pas la compilation des uml. Donc aucune perte de schéma, mais modification de ces schémas moins immédiate qu’avant.
Zut, je me suis encore mal exprimé. Quand je parlais de migration, il s’agissait de tous les articles et de toutes les pages du wiki (actualités/wiki). Les pages “custom” (accueil/logiciels/g1/monnaie-libre) sont encore brutes et seront retravaillées au moment du polissage.
D’accord, c’est donc parti pour ajouter un breadcrumb au thème.
Merci pour le signalement. Pour l’instant on est sur du brut, j’utiliserai le validateur au moment du polissage pour régler ces erreurs. Pareil pour l’accessibilité, encore que je n’ai aucune compétence là dedans.
Bah c’est justement ça que j’ai mal pris je n’aime pas tellement qu’on me conseille un outil en disant :
alors que mon choix est mûrement réfléchi. Ça ne m’aide pas, c’est juste gênant, et ça me freine dans le travail que je suis en train de faire.
En effet, je me suis emporté, je n’ai pas compris comment fonctionnait cet outil.
C’est ça que je n’avais pas compris. Je pensais que le markdown était rendu chez le client via du js dans son navigateur. Je crois que c’est ta remarque :
qui m’a induit en erreur.
oui, ça me gène beaucoup
Bah si, il faut bien un serveur pour servir des fichiers statiques !
Merci pour les Benchmarks, est-ce que tu pourras m’aider à optimiser le site en temps voulu ? Pour l’instant l’objectif est juste de migrer le contenu du site depuis Pelican.
Je suis aussi allergique à yarn 
je sais que c’est pas très rationnel, mais je suis un peu js-phobe
J’ai envie de te dire “fais le”. Si c’est si facile avec tes outils, fais-le avec tes outils, mais ne viens pas me faire chier pour me demander de faire autrement que la manière dont je suis en train de faire. Au cas où tu n’as pas compris, cette discussion m’énerve.
Tant mieux pour toi, je fais avec mes outils, je le fais et je suis content. Je sais comme c’est tentant de partager des outils dont on est fan, mais ici n’est vraiment pas l’endroit pour ça. Ici est un sujet sur le forum duniter pour refondre le site duniter, pas une plateforme de promotion pour des outils, js ou pas. Si tu veux m’aider, aide moi, si tu veux faire la course, fais le travail dans ton coin et ponds une version du site avec tes outils, et propose-la (si ça se trouve, ce sera mieux et ça m’évitera de passer des heures sur ce site).
Le problème de la maintenance n’est pas tellement un problème d’outil, c’est un problème humain. Il faut un bonhomme qui soit là pendant les trois prochaines années pour maintenir le site, c’est tout. Si tu veux être ce bonhomme, annonce-le, mais si non, alors laisse moi utiliser les outils que je veux, sachant que, je le répète :
Bah voilà, même si tu as raison sur les specs, j’ai perçu tes conseils comme une leçon de morale, et ça m’a énervé.
Excellente idée ! On n’a qu’à dire que je travaille sur le site duniter, tu travailles sur le site monnaie libre, et comme ça on peut s’aider mutuellement sans se gêner. Est-ce que tu peux ouvrir un autre post pour en parler ? Là j’aimerais surtout parler du site de duniter.
Et moul semble un peu débordé parce que depuis qu’on s’est vu au ground control et que tu avais entrepris de faire ce site, il n’est pas encore passé en prod.
En effet, c’est tout à fait dans le sujet. Mais là, voilà comment j’ai vu les choses :
Tu peux comprendre qu’avec cette vision je sois un peu énervé.
J’imagine que ta vision est la suivante :
Donc je comprends aussi ton doute :
Mais je pense que ce serait dommage que nos volontés se neutralisent, la meilleure option me semble être celle que tu proposes :
Si on fait comme ça, non seulement ça me décharge de la responsabilité du site monnaie libre qui me faisait un peu peur (je préfère me concentrer sur le site duniter) mais en plus, on a officiellement une personne pour maintenir ce site dont pour l’instant personne ne s’occupe.
Je ne sais pas à quelles remarques tu fais référence, mais j’espère que ma réaction ne va pas te faire “ragequit” comme lui. Si tu veux bien, on fait la paix et on travaille chacun sur notre site
fini la
et c’est parti pour
!
@HugoTrentesaux s’occupe du site duniter pour les trois prochaines années
@ManUtopiK s’occupe du site monnaie libre prochainement
On peut donc estimer ce sujet clos (la guerre est finie, nous sommes en paix). La discussion se poursuivra sur les sujets :
https://forum.duniter.org/t/site-web-de-duniter/
https://forum.duniter.org/t/site-web-monnaie-libre/
Vous avez le droit de réagir avec l’émoji 
à ce message, cela fera office de traité de paix !
Oui, pardon, je n’étais pas venu sur le forum depuis un moment et j’ai débarqué avec mes gros sabots Dans le contexte, je comprend tout à fait ton agacement. Toutes mes excuses ! Je me suis un peu emballé aussi… C’est vrai que le site de duniter n’est peut-être pas amené à avoir de gros besoins techs, contrairement au site de monnaie libre je pense…
OK. Je pourrais même faire le js et essayer de rendre le site compatible PWA. Évite le choc anaphylactique si tu as du javascript à faire, n’hésite pas à demander, moi je kiffe
Avec quoi est-ce que tu fais ces benchmarks ? Est-ce qu’il y a plus de détails ?
Oui, il y a carrément beaucoup plus de détail.
C’est lighthouse. Avec google chrome, dans le devtools tu as l’onglet « audit » ou « lighthouse » depuis la dernière version.
Sinon tu peux l’installer en local : npm install -g lighthouse. Désolé, c’est du js