Présentation usage de SPIP à Alphamosa

Dev
#14

Aucune idée, mais je vais essayer d’aller assez vite pour pas monopoliser votre temps. Au pifomètre je dirai au moins 45min hors questions/échanges.

1 « J'aime »
#15

Je bloque donc la date du mardi 4 avril à 10h.
@marcimat @rastapopoulos @JLuc @tcharlss @Jack31 @George sauf erreur de ma part il me manque votre email (par MP) (désolé pour le ping). Si d’autres personnes veulent y participer n’hésitez pas à m’envoyer un message d’ici mardi prochain.

1 « J'aime »
#16

Toutes les personnes concernées ont du recevoir un mail avec le lien de la visio (sauf @rastapopoulos :). Faites moi signe par DM si ce n’est pas arrivé dans votre boite mail.

1 « J'aime »
#17

Quid / relayer l’invitation sur la liste des utilisateurs ?

#18

Si vous pensez que ça peu intéresser d’autres personnes n’hésitez pas. Mais faut bien faire comprendre que ce n’est pas une visio de présentation de SPIP a des non initiés :slight_smile: (Ca je pense que je le ferai dans qq mois, ça pourrait être intéressant).

#19

Merci @Mathieu_L pour ta présentation. C’était intéressant et instructif.

TL;DR : il y avait surtout de la matière pour les « fronteux ». L’aspect ergonomique/facilité d’usage de ce qui a été présenté mériterait qu’on s’y intéresse pour la sortie de SPIP5.0.

Le compte-rendu qui suit doit être pris comme celui de quelqu’un d’un peu atypique : Je suis plutôt « backeux », je m’intéresse essentiellement aux aspects plus « invisibles » de SPIP : PHP, releases, git, transformation de la base de code, … et je le fais sur mon temps libre. Une partie de mon temps libre, en fait. Par chance, j’étais en vacances ce matin, mais je n’avais qu’une heure à consacrer à cette présentation, j’ai du quitter le live à 11h et ce n’était pas tout à fait fini. Du coup, la suite sera partielle et sans doute partiale :wink:

Mutualisation ? Pas mutualisation ?

A prioiri, la tendance chez Alphamosa est plutôt 1 SPIP pour 1 site. Pas de plugin mutu, pas de mutualisation.

c’est très « backend » comme sujet. On en parle assez peu ces dernières années. Mais c’est un sujet que je trouve intéressant. J’espère qu’un jour on remettra ça sur la table.

Plugins communautaires

Mathieu a démontré qu’on peut avoir une certaine autonomie avec SPIP seul (ou presque) pour déployer et maintenir une 50aine de sites. Cela aurait été intéressant de discuter du pourquoi et du comment. Est-ce que les plugins « contrib » manquent de publicité, de visibilité ? Sont-ils peu ou mal adapté ? Est-ce le temps qui manque pour parfaire sa connaissance de leurs fonctionalités ? Selon moi, ça mérite un thread à part entière :slight_smile:

Techno du futur

:slight_smile:

Pas de troll, mais cette phrase m’a marqué: « On n’utilise pas de techno du futur chez Alphamosa. » Ça aussi, ça mérite un thread. Ce que j’ai compris, c’est que l’essentiel du travail d’intégration se fait avec du HTML, du CSS et du Javascript Vanilla, très peu de PHP… Je trouve ça très positif. Mais pendant toute l’heure de la présentation, je me suis demandé "De quoi parle-t-il quand il dit techno du futur ? :slight_smile:

Security by lack of popularity

Malgré l’actualité récente, SPIP est « peu attaqué ». Sans doute parce que c’est une solution moins populaire que d’autre. Et l’arsenal de sécurité mis à disposition semble suffisant. La @spip-team-me est réactive et c’est cool.

Hélas, je trouve qu’il y a trop peu de gens qui se préoccupent de cet aspect, moi le premier. Malgré tout, le job est fait.

Conclusion

À refaire de temps à autres. Peu importe qui présente et ce qui est présenté. C’est très sympa d’avoir ce genre de retour d’expérience.
Et qui sait, peut-être qu’un jour, on parlera de « backend » et de « techno du futur » ? :smiley:

5 « J'aime »
#20

J’ai fait ce petit CR aussi que Mathieu (Alphamosa) me propose de poster ici

Des points pour SPIP

  • accessible aux utilisateurs novices
  • gestion d’une arborescence (rubriques), ce qui devient rare dans les CMS
  • interface ultra claire de SPIP 4 (rien à redire)
  • CMS clair et fluide d’usage d’un point de vue utilisateur
  • Réactivité du core (notamment sur la sécurité)
  • Peu utilisé, et donc peut être moins de pression sur les devs de SPIP (c’est positif)
  • Bonne tenue à la charge (avec stack simple : apache + php, même sans reverse proxy)
  • Migrations de versions agréables (comparées à d’autres CMS)
  • «Pâte à modeler» pour le front (accessible et efficace)

Usage

  • 200 Spip créés
  • 50 Spip maintenus
  • 1 SPIP / site (1 cas de multidomaine)

Présentation (Plugin Boîte à outils Alphamosa)

  • Recherche en haut de la page d’accueil (sous le bandeau)
  • Rubriques remontées en haut de la page d’accueil
  • Statistiques Matomo sur l’accueil
  • Remplace le title des liens SPIP ([truc|title->art12]) par une sélection de classe CSS ([truc|classe_css->art12])
  • Modales (boutons Porte Plume) pour faciliter l’insertion de liens, de documents (ça ressemble fortement à Insérer Modèles)
  • Modèles pour carousel et lignes d’images
  • Syntaxe pour faire des colonnes de texte ((( ... col 1 ... )))((( ... col 2 ... )))((( ... col 3 ... )))
  • Syntaxe pour des accordéons <accordeon>{{{titre}}} ... {{{titre}}} ... </accordeon>
  • Modale pour l’insertion (transformation en syntaxe SPIP) de tableaux à partir d’un copier / coller d’Excel / Calc

Autre config

  • Configuration d’un textarea pour ajouter des CSP (Content Security Policy)
  • Configuration d’un truc de JSON-LD (mais pas suivi, j’ai eu un coup de téléphpone)
  • Configuration de champs adresse, tél, identifications dans l’identité du site (un peu comme le plugin Identité Extra ou Réseaux Sociaux)
  • Log des connexions au BO de SPIP (besoin CNIL)
  • Note: il manque des infos pour la CNIL : loger qui fait quoi dans le BO (kent1 avait commencé journal mais pas utilisé je crois)
  • Logs de journal() en _LOG_INFO_IMPORTANTE

Remarques

  • Suit le plugin Prism (coloration de l’édition)
  • La fenêtre duale code à gauche, visu à droite n’est jamais utilisée par les rédacteur·es, entre autre car c’est pas les styles qui seront visibles dans le public
  • Préfère utiliser le moins de plugins possibles

Outils

Remarques SPIP

  • Gestion des logos compliquée
  • Syntaxe SPIP pas habituelle
  • Prévisu pas pratique (car pas représentative du site public)
  • Besoin d’insertion d’image de styles particuliers
  • Statuts d’objets trop complexes
  • Pouvoir remplacer l’identification SPIP par un service externe
  • Génération des images parfois lent
4 « J'aime »
#21

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.

#22

Un peu : Liens Visio SPIP :slight_smile:

#23

Amha tous les messages après celui-ci Prochaine version de SPIP : 5.0 et PHP 8.1 ? - numéro 18 devraient être déplacés dans un fil dédié.

#24

totalement d’accord…
…mais je ne vois pas comment on peut « découper » un thread dans Discourse :frowning:

#25

Moi je vois ^^ Par contre, il me faudrait un nom pour le nouveau thread avant de lancer ça.

#26

Done.

#27

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).

#28

« Déposséder contrib de son rôle documentatoire pour l’attribuer à discuter.spip »

Je ne comprends pas de quoi tu parles, tu peux préciser ?

#29

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é.

#30

Quelques réponses en vrac.

  • 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).

#31

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.

Cf Reporting API Reference: API Reference - Matomo Analytics (formerly Piwik Analytics) - Developer Docs - v5
L’API matomo permet de récupérer plein de stats assez facilement : tout ce qu’on voit sur les différents tableaux de bords matomo. Par exemple, récupérer le nombre de vues d’une page… Dans la présentation de @Mathieu_L, le graph des stats était bien attrayant aussi.

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.

#32

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.

#33

OK ça marche avec la doc Embed a Matomo report (or dashboard) in a HTML page FAQ - Analytics Platform - Matomo pour les données,
et Metadata: API Reference - Matomo Analytics (formerly Piwik Analytics) - Developer Docs - v5 pour les graphes tout prêts.

1 « J'aime »