C’était sympa ; et entre 2 party IRL ça mériterait d’être reproduit.
Les CR de @JamesRezo et @marcimat étant en fin d’un thread dont le sujet n’a qu’un lointain rapport avec la présentation, ne faudrait il pas les reporter sur le wiki de contrib ?
À part ça,
la question de la distribution des développements maison de @Mathieu_L , ou de certains, a t elle été abordée à la fin ?
comme suggère @JamesRezo , un autre thread « tout dev soi-même vs utiliser les plugins existant ? » me parle, car sans être aussi extrémiste que @Mathieu_L, il y a pas mal de devs que je fais moi-même et qui doublonnent plus ou moins des trucs de la zone.
Remarque : Seuls les superadmins de discuter.spip peuvent ainsi diviser un thread en 2 parties, alors que tout le monde peut participer pour créer ou éditer un article sur contrib et/ou sur le wiki de contrib.
Déposséder contrib de son rôle documentatoire pour l’attribuer à discuter.spip… ne va pas alléger la tâche des admins de discuter… (mais bon, c’est plus fun que de modérer les spams).
Mettre des notes de compte rendu en vrac à la suite du fil de discussion qui proposait une rencontre en visio, bah c’est juste logique en fait. Rien à voir avec un article vraiment rédigé.
Dans ma tête les technos du futur c’est toutes ces magnifiques technos qui s’empilent les unes sur les autres pour monter des châteaux de cartes, ou des technos que je considère trop compliquées pour le besoin de nous autres mortels. C’est très personnel, pas grand monde ne sera d’accord avec moi, j’assume. Ca englobe plein de technos qui pourrait vous faire hurler (React, Sass, TypeScript, Node, …).
Pourquoi j’utilise peu de plugins communautaires : il y’a bien longtemps (SPIP 1.7/1.9/2) je me suis retrouvé à gérer des sites SPIP que je n’avais pas construit. Lesquels étaient montés avec de nombreux plugins. J’avais régulièrement des problèmes (petit bug dans un plugin, demande d’un utilisateur qui concerne un plugin et donc sur lequel je n’avais pas « vraiment » la main, montées en version impossible car plugin non maintenu…), de fil en aiguille j’ai pris pour habitude d’y aller solo sur les installations de plugins, jusqu’à tenter de faire le maximum sans. Ca ne m’empêche pas de reconnaître la force de la communauté à ce sujet et le travail qui a été abattu pour nous fournir tous ces plugins ! Mais dans mon cas, très précis où je gère pas mal de sites, c’était nettement plus sage d’en limiter l’usage.
Distribution des développements maison : oui j’ai abordé le sujet (je savais bien que j’allais me faire aligner là dessus :p). J’ai plusieurs blocages à ce niveau mais qui sauterons peut être dans les mois à venir (j’ai notamment besoin d’une vraie formation Git, sur lequel je suis niveau zéro).
A propos de matomo, il se trouve que justement la semaine dernière, j’ai voulu accéder dans un squelette SPIP aux nombres de clics sur des liens sortants. J’aurais pu le faire avec un compteur de clic local (cf Résultats de la recherche - SPIP-Contrib ) mais puisque matomo est actif sur ce site, autant lui demander, et j’ai fait un petit filtre qui récupère cette valeur via l’API matomo. La valeur est alors utilisée dans les pages d’admin (un espace à accès restreint, pas /ecrire), et pourrait l’être, à l’avenir, sur la page publique où figure le lien lorsque c’est son auteur qui la regarde, ou dans certains mails semi-automatiques aux auteurs, etc.
Yaurait donc matière à un plugin qui encapsule tout ça et facilite l’usage « in situ » des stats matomo @Mathieu_L, voudrais tu initier cela puisque tu as pris de l’avance ?
Sinon je peux créer un plugin pour partager ce que j’ai fait. Pour l’instant il n’y a qu’un filtre accédant au nombre de clics sur un lien externe :-), mais ça ferait une base pour d’éventuels développements communautaires ultérieurs.
Alors pour le coup j’ai justement pas fait grand chose : l’intégration que vous avez vu dans la page d’accueil de BO SPIP de Matomo c’est un simple widget Matomo intégré via l’API Matomo classique (c’est une iframe, ça tape sur l’URL du serveur Matomo avec une clé d’authentification). Y’a zéro code de mon côté si ce n’est de stocker ces deux informations qq part dans la base de données de SPIP pour pouvoir afficher le widget en question.
