Création d'INFOJUNE

Salut tout le monde. Je suis en train de refaire le design de infojune.fr et je vais en profiter pour ajouter la version espagnole. Quelqu’un pourrait-il me traduire un fichier de langue ?

2 Likes

C’est pas plus sur le forum ML que tu as le plus de chances de trouver un traducteur ?

J’ai mis aussi ce message sur l’autre forum :wink:

La nouvelle version est en ligne. N’hésitez pas si vous avez des remarques/suggestions.

4 Likes

Super ! J’adore le design ! Bravo :+1:

1 Like

Très bien !
Cependant, je note qu’il nécessite JavaScript pour que le clique sur un de ces boutons redirige vers une autre page.

1 Like

Oui. C’est un comportement qui est amené à changer. J’ai déjà commencé le travail (et c’est en production) pour les liens. Il n’y a plus de fenêtre modale affichée en AJAX. Ce qui évite un clic avant d’aller visiter un lien et ne nécessite donc plus javascript. Le même travail est en cours pour les rubriques. Stay tuned ^^

2 Likes

Est-ce que le code source du site sera publié sur le GitLab Duniter ?

2 Likes

C’est fait avec le CMS SPIP qui est open source (PHP/MySQL). Avec qqes plugins et la création de squelettes HTML, j’obtiens ce résultat. Tu souhaites que j’y dépose tout le projet ? Je n’y vois pas de problèmes. Mais faut y adjoindre la BDD sinon ça n’a pas de sens. Je ferai un dossier SQL avec la BDD dans le dépôt avec une explication dans le README.

2 Likes

Est-ce que tu as utilisé un thème spip existant ou créé un ? Je suis d’accord qu’il faudrait aussi publier un backup de la bdd, ne serait-ce que pour éviter de tout perdre. Mais effectivement, je ne connais pas de mécanisme de synchronisation de SQL permettant d’avoir plusieurs instances infojune communiquant.

Il existe la notion de thème dans SPIP mais je n’ai jamais utilisé. Je fais les sites" from scratch" en surchargeant le dossier ./squelettes. J’ai utilisé un plugin de gestion de noisettes HTML pour faciliter la tâche.

C’est effectivement une technologie centralisée (de type wordpress). Néanmoins il est possible de faire de la syndication de sites nativement dans le CMS. Je n’ai jamais poussé son utilisation, y’a peut-être qqe chose à exploiter de ce côté-là. Le seul intérêt que je verrai d’avoir plusieurs instances communicantes, serait que chacun alimente sa BDD et les autres instances pourraient agréger ce nouveau contenu. Sinon, j’ai donné les droits d’admin à @Attilax (qui héberge le site chez lui) et @Maaltir . Si d’autres veulent pouvoir créer/modifier du contenu, je peux leur créer un compte :wink:

1 Like

lol j’ai paumé mon mdp.

Pour publier et sauvegarder automatiquement la bdd, plutôt que git il y a tout simplement la solution du cron qui met un dump SQL dans un dossier servi par le serveur web.

Et pour la sauvegarde, un autre cron sur un autre serveur qui télécharge ce dump de temps en temps.

Mais bien vérifier si la bdd contient des mots de passe, clés privées ou tokens avant de la publier.

1 Like

J’ai créé un dépôt sur le Gitlab mais il semblerait qu’il faille créer une branche par défaut et je ne trouve pas comment faire (pas sûr d’avoir les droits) :
image

Je t’ai passé de développeur à mainteneur sur le groupe websites. Est-ce que ça passe à présent ?

1 Like

Pour rebondir sur ce sujet, il y a les CMS Headless (cet exemple utilisant NodeJS est intéressant) qui peuvent offrir une API centralisée afin d’avoir plusieurs instances avec des rendus différents. L’autre avantage c’est qu’on peut changer facilement de technologie front en fonction des évolutions du marché. Cela pourrait être l’occasion de tester des frameworks comme VueJS ou ReactJS.

1 Like

Oui, c’est une bonne idée ça, qui va dans le sens du concept de Jamstack et de site statique (si je comprends bien).

Pour moi, il ne devrait pas y avoir de développeur web pour un site (si c’est pas un troll ça :wink: !). Je pars du principe que tous les langages de programmation peuvent générer un site, et le concept de Jamstack me paraît le plus pertinent pour rester dans son langage impératif ou fonctionnel préféré et ne pas avoir à coder du bas niveau déclaratif (HTML/XML ou CSS).

Les langages descriptifs (ou déclaratifs) comme le HTML/XML ou CSS ne devrait jamais être codés par ceux qui veulent faire un site, mais par ceux qui font des composants web, des templates, destinés à être générés par du code impératif (ou fonctionnel).

@ManUtopiK ne me contredira pas je pense puisqu’il a choisi ce concept de Jamstack pour le site web de Duniter avec Nuxt.js.

2 Likes

Donc un développeur web aujourd’hui ne devrait plus gagner sa vie en vendant des sites mais en vendant des templates ? (hors-sujet mais ça m’intéresse)

@Paidge Oui, Directus est vraiment bien, je l’utilise pour des clients. Mais il faut un node.js sur un serveur, et une bdd, et… gérer tout ça…
Je pense que du headless basé sur du git, c’est encore mieux. Que des fichiers, c’est plus portable…

@vit Jamstack c’est fun ! Même si ça simplifie les choses pour les devs et les rédacteurs d’un site, ça nécessite toujours un peu de dev, au moins pour la mise en place… C’est le site de monnaie-libre.fr qui est sous nuxt, pas Duniter.

Chacun fait ce qu’il peut pour gagner sa vie, ce n’est pas vraiment le sujet. Je parle en terme d’efficacité, et de temps. De trouver la technologie la mieux adaptée au problème à résoudre.

La tendance que je vois se dessiner c’est de coder juste ce qui est nécessaire et d’utiliser des composants ou des framework pour le reste. Mais aussi de générer du code déclaratif en restant dans du code impératif (ou fonctionnel) ou avec de la configuration et des templates. C’est ce qu’on fait ici avec Spip, Nuxt.js, etc.

Qui programme en PDF ? :wink: (don’t feed the troll).

Oops. My bad. Le site de Duniter est fait avec Zola si je ne me trompe pas. Un générateur de site statique, dans la philosophie Jamstack…