Dernières news de SPIP - juin 2023

[paidge]

Bon bah merci chatGPT Pour les captures, au besoin, y’a ce qu’il faut dans le dépôt du plugin

=== DEBUT #graphql

GraphQL est un langage de requêtes et un modèle de données développé par Facebook en 2012 et rendu OpenSource en 2015 pour optimiser les performances des applications mobiles et des sites web développés en JAMstack. Il permet aux clients de spécifier précisément les données dont ils ont besoin, évitant ainsi les multiples appels aux API. GraphQL offre une flexibilité remarquable en permettant aux clients de récupérer plusieurs ressources dans un seul appel et de définir la structure de réponse souhaitée. Cette approche granulaire réduit la bande passante et accélère le développement des applications.

Avec le nouveau plugin graphQL pour SPIP, il est désormais possible de tirer parti des avantages de GraphQL en transformant SPIP en un endpoint GraphQL. Ce plugin permet aux développeurs et aux développeuses d’exposer les données de SPIP sous la forme d’un serveur GraphQL, offrant ainsi une alternative puissante et flexible aux méthodes de récupération de données traditionnelles. Grâce à cette intégration, les utilisateurs et les utilisatrices de SPIP peuvent bénéficier de la simplicité et de la performance de GraphQL tout en tirant parti des fonctionnalités et du contenu riches de leur CMS favori.

Le plugin est encore en phase de développement (RoadMap en cours d’élaboration) mais est fonctionnel, grâce à la bibliothèque graphql-php. Il propose au webmestre (qu’il soit homme ou femme ou même non-genré) d’exposer les collections et les champs de son choix, avec ou sans jeton API pour privatiser l’accès aux données. Il permet au développeur ou à la développeuse de créer facilement ses propres requêtes et ses propres types de données. Enfin, il propose un client graphQL intégré (graphiql) pour tester vos requêtes graphQL directement dans le back-office de SPIP. Le plugin et le code sont extrêmement commentés pour faciliter l’appropriation de cet outil par la communauté.

=== FIN

[touti]

Bonjour
sans parler du contenu, un des trucs de l’IA si iel n’est pas guidé est de reprendre la façon dont la majorité des textes est écrite, avec ses travers.
Pour s’adresser à une communauté ouverte (qui a très peu de participantes comme beaucoup de projets libres) SPIP essaye d’éviter les terminaisons masculines. Ce que ne fait pas Chattruc.
Ainsi, on préfèrera écrire « les personnes qui font du développement » ou « les personnes qui utilisent » plutot que développeurs ou utilisateurs. Quand on ne peut pas écrire de façon épicène, on met alors un point médian.
Petit rappel qui fait que du bien :*

[paidge]

Je conçois. Je ne suis pas sensible à cette thématique et cela ne me dérange pas que le texte soit modifié dans ce sens avec des termes neutres comme « personnes ». Perso, je n’aime pas trop les iel, iul & Co. Et les points médians - même s’il existe 1 ou 2 projets OpenSource avec lesquels ça fonctionne - sont souvent mal interprétés par les lecteurs d’écrans ce qui ne favorise pas l’accessibilité (a11y). Sans parler des dyslexiques. J’ai modifié le texte pour qu’il soit plus inclusif

[marcimat (Matthieu Marcillaud)]

Un petit mot sur le PDF / epub pour les rédactrices & rédacteurs rédigé et actualisé par @Ysabeau pour SPIP 4 SPIP 4 : vu du côté de la rédaction - Modèles et guides qui très propre ?

[Un guide pour] des personnes qui sont amenées à rédiger ou administrer un site tournant avec ce logiciel de gestion de contenu mais n’ayant pas à intervenir sur l’aspect technique. À récupérer en version PDF ou EPUB.

Note

• Les images sont un peu trop compressées dans le PDF je trouve, mais bon ;
• les captures montrent certains plugins activés en plus, sur la barre typo notamment

[jeanmarie]

Salut @paidge,

Merci pour ta contribution

@paidge

Je ne suis pas sensible à cette thématique

Ce n’est pas une thématique mais un sujet de fond qui a longuement été débattu ici (ce commentaire n’a pas pour but de relancer le débat) et qui est inscrit dans la charte de la communauté SPIP : « respect de l’identité de chaque personne »

C’est donc une demande de la communauté dans son ensemble que les textes soient le plus inclusifs possible, donc soyons tous et toutes vigilant·es lors de la rédaction (et je m’inclue dedans ).

[touti]

Je t’ai demandé de modifier ton texte pour qu’il soit inclusif, je ne m’attendais pas à ce que cela te serve à étaler ton point de vue masculiniste. C’est dommage et pour toi qui étale ta suffisance sans vergogne et pour moi qui prend encore et toujours sur moi de rappeler que l’écriture chez SPIP est inclusive.
Décrotter vous le cerveau les mecs là, à part jeanmarie personne ne dit rien comme d’hab ??

[JLuc]

Alors quoi de nouveau dans la galaxie SPIP ?
Il s’est passé des trucs à relayer la semaine dernière ?

[maieul (Maïeul Rouquette)]

le travail de james sur la décomposition du code de spip en petit morceaux modulaire ?

[maieul (Maïeul Rouquette)]

Squelette Koinós - SPIP-Contrib

(Mais je pense que globalement on pourrait relayer toutes les publications récentes de contrib, voir même imaginer un modèle pour les récuperer automatiquement…)

[JamesRezo]

Il y a à ce jour 314 plugins compatibles SPIP4.2. Il y en avait un peu moins de 250 début mai. Dans la plupart des cas, c’était « juste » un problème de borne supérieure de compatibilité…

[JLuc]

@JamesRezo Je pourrais recopier ton texte sur la décomposition du code de spip en petit morceaux modulaire, mais je n’en connais pas les tenant et les aboutissants alors pourrait on plutôt le décrire de manière simple ?
Pourrais tu indiquer, par exemple en 1 phrase pour chaque point :

• dans quel projet à long terme cela s’inscrit il ?
• qu’as tu fait (grosso modo) ?
• en quoi ce travail sert il ce projet, à court ou moyen terme ?
• quel est le principal résultat intéressant ?
• quelles sont les (ré)orientations induites et les suites à court terme ?

[RealET]

Une news plus côté développements : phpstan, phpcbf, rektor et autres outils de qualité de code, en 2 parties :

1. objectifs : en parler d’un point de vue conséquence pour la communauté et l’avenir de SPIP : une montée en qualité et sécurité
2. méthodes et outils : une description de chaque outil et comment les utiliser

[JamesRezo]

Bah tu ne m’épargnes pas ! 1 phrase par réponse, rha la la, on va me reprocher d’être lapidaire (ou hermétique) ^^

Nan, chouette exercice. J’essaie.

Le projet à long terme est de sortir SPIP de son isolement technologique vis-à-vis de l’écosystème PHP.

Ce qui est fait à ce jour, c’est l’assemblage de la distribution classique de SPIP avec composer pour SPIP5.0, qui devrait sortir en début d’année prochaine. La suite, pour les 6 mois (le court terme) qui nous restent jusque là, c’est de tenter de remplacer la plus grosse part possible du PHP historique du dossier ecrire/ par des composants (pas des plugins) techniques spécialisés, basés eux-même, dans la mesure du possible, sur des lib externes plus sûres, maintenues par d’autres pour allégeer notre propre charge mentale. En ce moment, j’analyse le code existant et je classe les fonctions, les fichiers, les globales, les constantes. On aura peut-être besoin d’étaler ça sur un peu plus temps plus long. On verra …

À moyen terme, (disons pour les 3 années suivantes ? pour les SPIP 5.x grosso modo ?) ça nous permettra, d’assurer plus facilement la compatibilité des plugins communautaires, et donc les diverses montées de version, mais ausi, je l’espère de ne plus avoir besoin d’un dossier physique ecrire/, de faire des distributions « moins classiques » plus facilement, de proposer d’autres manières de sécuriser des applications SPIP sur le web, de ne plus copier/coller du code de lib externes dans des plugins, voire des dossiers vendor/ entier …

Le résulat principal intéressant, pour le moment, bah ça dépend de ce à quoi on s’intéresse, forcément… mais je pense que l’assemblage de spip avec composer, ça nous facilite pas mal la production des zip de spip et donc des releases mais aussi pour les devs en local (mais c’est plus aux autres de le dire…). Si on tient nos objectifs, ça devrait aussi être plus facile de maintenir des plugins…

Les orientations induites, sans être 100% sûr de répondre à ta question, c’est qu’on bénéficie des standards d’autoloading partagés avec l’écosystème PHP: on peut donc faire du code objet, ce qui nous facilite notament la production de tests unitaires automatisables (parce que c’est plus facile de tester des classes que des fonctions mélangées à des globales, par exemple)

[JLuc]

Merci James. Il y a plus d’une phrase par point, alors ça reste pas évident à comprendre… mais ça ira bien pour les spipeurs concernés.

À part ça, suite à suggestion de @b_b, je préparerai un bestof des trucs les plus inintéressants de Truc super pas intéressant

Et je relève aussi l’échange à propos de la personnalisation des notifications de formidable :

==== DÉBUT
Q: Je voudrais insérer des liens actifs dans le courriel envoyé par Formidable, via un champ pré-rempli au chargement.

A: Il faut créer ton propre squelette notifications/formulaire_XX_email.html pour le formulaire XX en question (XX étant l’identifiant, pas le numéro). Et là tu peux récupérer ton champ caché dans #ENV{valeurs/tonchamp} et construire le squelette du mail avec.

=== FIN

[maieul (Maïeul Rouquette)]

je ne suis pas sur que cela vaille la peine d’en faire une news.

[JLuc]

En effet je savais pas mais c’est dans la doc de Formidable.
Alors ça pourrait (quand même) aller dans la super rubrique des « Trucs pas intéressants »

Idem et pour la même raison cf paquet.xml -> <procure> ?
==== DEBUT
Question : Dans quel cas faut il déclarer une balise <procure> dans le fichier paquet.xml ?
Réponse :

• Ça peut servir quand un plugin fournit une librairie dans le dossier « lib »
• Ça peut aussi servir à un plugin d’indiquer qui supplante un autre (car il a intégré ses fonctionnalités), exemple avec SPIP qui indique qu’il procure les fonctionnalités de l’ancien plugin itérateurs spip/paquet.xml at master - spip - SPIP on GIT

==== FIN

[JLuc]

==== DEBUT #SPIP5
Depuis le commit 7e0ef909, les CSS de la dist utilisent des variables CSS. Elles sont séparées en 2 :

• Des variables « publiques » qui pourront être communiquées, elles permettent de modifier simplement les principaux éléments qui régissent l’apparence du thème : couleur d’accent, etc.
• Des variables « privées » à usage interne, qu’il n’est pas recommandé de surcharger dans ses styles persos.

Exemple :

.success    { 
    background: var(--dist-color-success-bg); 
    color: var(--dist-color-success-text); 
    border-color: var(--dist-color-success-border); 
}

==== FIN