Mise à jour de maintenance et sécurité : sortie de SPIP 4.2.3, SPIP 4.1.10

Général
#21

Oui en théorie, mais voici quelques cas pratiques :

1./ Mon avant-dernier client est un établissement public dont le serveur tourne en php 7.3 et qui n’a pas prévu de passer en php 8 avant le rendu du site.

2./ Mon dernier projet est un Spip avec 69 plugins :

Voici une liste des plugins ne permettant pas de mise à jour

1./ En 4.1, ça va :

  • Il faudrait que je mette à jour liaison d’objet (indispensable pour ne pas avoir à refaire toute la Une du site) → c’est à ma portée
  • Rôle de document (indispensable pour ce site. dispo mais instable en 4.1). C’est du développement hors de porté pour moi avec plein de soucis remontés dans les tickets de dev du plugin. Les développeurs font ce qu’ils peuvent, mais j’imagine qu’il keur faudra du temps pour rendre stable le plugin.
  • Le partageur (pas indispensable mais pratique)

2./ En 4.2, ça se corse : classement du plugin le plus indispensable au moins indispensable :

  • Plein de plugin manquent à l’appel pour la partie E-commerce du site : API Prix, Commande, livraison et panier, Liste des pays, prix objet ( ces plugisn sont indispensables, il s’agit d’une maison d’édition avec vente en ligne). Je ne peux pas me contempler de petits tests une fois les plugins mis à jour.
  • Déclinaison prix (Indispensable car les ouvrages vendus ont commencés à être référencés avec une déclinaison numérique et papier avec ce plugin)
  • Rôle d’auteur (indispensable pour ce site qui distingue les auteurs d’ouvrages des coordinateurs, etc.)
  • Less Css (indispensable sinon je dois transformer toutes les feuilles de styles)
  • Mot de passe dès l’inscription (indispensable, ça constitue un élément important du tunnel de paiement )
  • Composition (indispensable), les squelettes s’appuient dessus
  • Crop image (qui avait déjà remplacé le massicot qui n’est pas dispo pour Spip 4 - presqu’indispensable car tellement pratique )
  • Rang et rang sur les auteurs (très utile)
  • Formulaire libre (pas indispensable, je peux le remplacer par un formulaire formidable)
  • Correction guillemet typo (pas indispensable)

Bref, ce site sera en retard d’une ou 2 version à sa sortie. Quand il a commencé à être développé et il n’y avait pas grand-chose de dispo en 4.1.

Pourquoi je rentre dans ces détails pratiques ?

Pas pour embêter mon monde ni pour mettre la pression aux développeurs de plugins, mais au contraire pour que l’on se pose la question de la dimension de Spip, de sa communauté et que l’on se demande si un calendrier de changement de sous-branche tous les 6 mois peut aller de pair avec la pérennité des projets.

1 « J'aime »
#22

@Yohooo effectivement, il manque « dans la mesure du possible » dans mon message :slight_smile:

Pour info, Compositions est compatible SPIP4.2 : #11 - Compatibilité 4.2 - compositions - SPIP on GIT

#23

Merci pour les retours pratiques @Yohooo

Pour les plugins pas encore marqués comme compatibles, ce qui peut aider c’est de les tester soi-même sur une installation locale ou un serveur de dev, et de signaler soit sur contrib soit via un ticket s’ils semblent toujours fonctionner correctement.

Ce week-end je devrais avoir le temps de jeter un coup d’oeil et proposer une montée de version pour une partie des plugins e-commerce : commandes / paniers / prix / livraison.

Pour rôles de documents on a pris du retard dans les résolution des bugs, mais on va s’y remettre urgemment.

#24

Bonjour,

Spip est un super outil et nous vous remercions pour tout le travail effectué :slight_smile:

Cependant, je rejoins Natacha et Yohooo dans leurs constats, étant également confrontée aux mêmes problèmes avec mes clients : version des hébergements, durée de développement, clients qui ne veulent pas évoluer malgré nos alertes…

Le rythme de changement de version est actuellement un peu trop rapide pour que nos clients suivent.

#25

Là, c’est moi qui craque…

Vu que ça parle indirectement de pognon, parlons pognon.

Le « rythme de changement de version » , comme tous les aspects liés à la mise à disposition du logiciel, appartient à une communauté de personnes physiques organisées sans rapport financier entre elles. Ce ne sont pas vos clients, ou vos difficultés à contractualiser avec eux, qui peuvent décider du présent et du futur du logiciel. C’est la meilleure garantie d’en faire un bien commun, accessible aux gens qui vous payent et aux gens qui ne payent pas pour l’utiliser. Vous ne payez pas pour l’utiliser… Cela reste notre objectif : produire, maintenir, faire évoluer un bien commun.

Il n’y a pas d’opposition à ce que des membres de cette communauté ait une activité rémunérée autour de SPIP. Mais cette logique financière leur est propre, leur appartient et n’a pas à influer sur le bien commun.

Cet argument, « ça va trop vite », est donc irrecevable parce qu’il est associé à « pour mes clients ».

Mon argument à moi est « ça ne va pas assez vite ». Ce bien commun vieillit parce qu’il ne s’adapte pas assez vite aux technologies sur lesquelles il s’appuie historiquement et sur celles qui ont émergé depuis sa création.

Vous faites des sites de e-commerce avec SPIP ? Cool. Y a du fric qui transite dans des requêtes HTTP. Vos clients se font un peu (ou beaucoup) de moulah avec le produit du bien commun. Un bisou, un merci, un café ?

Y a aussi des gens qui vont tenter de le voler ce pognon. Y a intérêt à ce que toute la pile matérielle et logicielle soit protégée: le système, les langages (PHP, JS) et SPIP…

Bref, je reste calme (et donc je m’arrête là) parce que j’aime les gens qui utilisent SPIP :kiss:

5 « J'aime »
#26

Hello !

Ce n’est certainement pas une réponse générique qui fonctionnera pour tout le monde, mais je vais rapidement vous expliquer comment on s’en sort de notre côté :

1/ On demande à nos clients de prendre une TMA de 2-4h par an spécifiquement pour le suivi et l’application des « petites » mises à jour SPIP Là dessus je fais passer les mises à jour de l’écran de sécu, et les màj x.x.X, parfois les x.X quand c’est pas trop compliqué (c’est le cas pour la migration 4.1 → 4.2 qui se passe plutôt bien de mon côté). Le client sait qu’il a un budget à consacrer chaque année à ça (en plus de l’hébergement), de notre côté on a pas à demander quoi que ce soit avant de faire une mise à jour.

2/ Limiter l’usage des plugins. Pour moi SPIP est une excellente (je pèse mes mots) solution de gestion de site « classique » : y’a quasiment tout ce qu’il faut dans un SPIP vanilla. Les choses se compliquent quand on a besoin d’autres objets éditoriaux, quand on gère d’autres flux d’informations/données, quand y’a du paiement… On construit donc nos sites pour séparer au maximum les choses : SPIP gère le site front, le reste c’est des développements spécifiques ou d’autres outils (les boutiques c’est un excellent exemple). Parfois il y’a des données qui remontent du développement spécifique vers le SPIP, qu’on peut exploiter assez facilement avec les boucles DATA. Résultat : on a entre 4 et 6 plugins par site, maximum (dont 3 sont des plugins maisons). On a donc peu de dépendance et moins de soucis sur les mises à jour.

3/ Il faut industrialiser les mises à jour. J’ai passé un peu de temps pour me construire mes propres outils pour déployer facilement et rapidement les écrans de sécurité et les mises à jour SPIP. Ca prend un peu de temps mais on en gagne sur le long terme. (je crois que SPIP-Cli - SPIP-Contrib fais cela également).

4/ Ajouter des sur-couches des sécurité. Ca ne remplacera jamais une mise à jour de SPIP, mais ça permet de dormir plus tranquillement. On a des firewalls, nG firewall (8G Firewall (Beta) | Perishable Press), des accès filtrés à /ecrire/ par IP, des outils de surveille sur les machines, d’autres externalisés, des backups, de la redondance… Ca ne s’est évidement pas fait en un jour, mais on est un peu plus sereins.

On s’adapte, et on a fait des choix.
Et merci la communauté pour cet excellent outil !

2 « J'aime »
#27

Est-ce que tu as conscience que cette version de PHP n’est plus maintenue (par PHP) depuis plus d’un an ?
https://www.php.net/supported-versions.php

Certes… mais la communauté maintient plutôt le plugin scssphp… Less c’est déjà d’une autre époque. Possiblement il fonctionne avec SPIP 4.2, mais la compatibilité avec PHP 8.2 n’est peut être pas là.

#28

Est-ce que tu utilises pour ça un outil existant connu ? Tel que Deployer ou Capistrano ? Si c’est le cas ça peut être sympa un petit tuto quelque part ?

#29

Du tout, c’est des script bash qui lancent des rsync. C’est assez spécifiques à nos besoins et y’a pas de grande intelligence. SPIP-Cli est infiniment plus complet.

#30

C’est quelque chose auquel je suis sensible, car c’est parfois plus facile de construire soi-même un plugin (quand la prise en main d’un plugin est insuffisamment documentée) et de le maintenir (quand les mainteneurs ont d’autres choses à faire). Ça peut interpeler et faire réfléchir… mais je n’ai aucune idée de ce sur quoi ça peut déboucher.

#31

Non, surtout pas, c’est pas le but. Et je remercie la communauté Spip pour son boulot, sa bienveillance et même son altruisme. L’aspect politique de Spip me motive grandement à continuer à l’utiliser.

Tu as raison de parler modèle économique et je n’aime pas utiliser le mot « client » pour parler à une communauté bénévole. Mais comme je donnais des cas pratico-pratiques, le but n’est pas de me cacher. Et il est vrai que je me rémunère pour ce travail.

Par contre, Site E-commerce ne veut pas forcément dire plein de fric. Les structures auprès desquelles j’interviens sont soit des assos, soit des syndicats, soit des groupes politiques, soit des artistes. Le E-commerce, c’est pas forcément World Compagny. Il est utilisé pour payer des adhésions d’assos, pour payer des abonnements à des canards en ligne qui balbutient, pour vendre des ouvrages de bouquineries en ligne. Certains de mes interlocuteurs ne peuvent payer. Je fais en sorte dans mes offres commerciales que les gros participent plus que les petits.

J’ajoute que je sensibilise ces structures au fait d’investir dans la maintenance. Mais on sait tous que de nombreuses structures ont des fins de mois difficiles.

Hé bien nos 2 arguments se juxtaposent. On n’est pas obligé d’être en contradiction. On a juste des besoins différents. La question est juste : comment on fait pour répondre aux 2 ?

Pourrait-on imaginer, à partir de la version 4.0, une maintenance un peu plus longue uniquement axée « correction de failles de sécurité » ? (je ne sais pas si l’écran de sécurité suffit en lui-même à faire cela).

Merci aux autres pour vos réponses :

  • Oui, Marcimat, j’ens suis conscient pour php, mais c’est pas moi qui décide. Il s’agit d’une asso hébergée sur le serveur d’une institution nationale. Le passage en Scss est dans mes prochains chantiers.
  • Merci Mathieu_L pour tes conseils
#32

merci @Mathieu_L de ton retour, c’est toujours interressant de savoir comment les autres fonctionnent.

De mon côté :

Maintenance / Sécurité

3 possibilités (de la plus chère à la moins chère) :

  • je gère la maintenance (mise à jour SPIP + plugins) et on provisionne un nombre d’heures annuelles pour l’accompagnement et les petites modifs
  • j’installe le site chez un hébergeur douillet pour SPIP pour que la sécu soit assurée (et on se connait plus)
  • je montre comment faire les mises à jour de façon autonome en précisant bien que dans 90% des cas, ça ne sera pas fait et que, si ça casse, il faudra payer qq1 pour réparer (et on se connait plus)

Plugins

Je limite au maximum les développements persos et utilise généralement autours de 30 plugins par site (sauf cas particulier, je préfère les plugins révisés par la communauté aux développements persos pour plus de sécu). Je me limite au strict nécessaire (notion subjective) et n’installe pas (plus) de plugin « juste histoire de » (principe KISS). Je choisis les plugins qui sont les mieux maintenus (à force, on les repère et on peut poser des questions ici si on a nouveau besoin).

Hébergement

Mes client·es n’ont pas de gros besoins de ressources, donc c’est systématiquement du mutualisé pour ne pas avoir à gérer de hardware (admin sys, c’est pas mon métier)

Mises à jour

Spip_loader est ton ami : à chaque mise à jour, un clic sur un lien pour lancer la mise à jour. Quand le mise à jour est faite, j’envoie un mail (via Newsletter/Mailshot/Mailsubscribers) pour prévenir les utilisateur·rices.
Sur ces points, j’ai encore du chemin à faire pour me faciliter la tâche mais c’est déjà plus fluide que fût un temps.

Communauté

J’essaie de participer autant que possible, selon mes dispo/capacités (par ex, tester les plugins sur mes nouveaux sites en dev et signaler les problèmes ou mettre jour les bornes quand ça roule, répondre aux questions sur ici…) et je remercie les devs lors des mises à jour et l’ensemble de la communauté pour ces échanges nourrissants !
SPIP :heart:

1 « J'aime »
#33

On tâtonne, mais c’est bien ce qu’on essaye de faire depuis 4/5 ans.

Je ne rentre pas dans les détails. Si un jour j’ai le temps, je raconterai tout ça, mais je ne suis pas certains que ce soit si intéressant que ça…

Concrètement, la page des versions maintenues, que j’ai déjà signalée dans ce fil, donne de la visibilité sur ce qui a été, est ou sera. Cliquez, n’ayez pas peur.

Le cycle de vie n’est pas encore parfait, d’où la sensation de « trop vite » sans doute. Je pense qu’on pourra apporter des clarifications durant l’été ou à l’automne.

Et désolé pour la blague malheureuse sur le craquage. C’était juste une tentative pour dire qu’on est toutes et tous, un peu, dans la même situation, qu’on le voit, qu’on le sait, mais que voilà quoi… (je m’embrouille)

#34

Et quels sont les soucis rencontrés avec Less en SPIP 4.2 et PHP 8.2 ?

#35

Pour ces deux la :

  • formulaire libre j’imagine c’est « formulaire de contact avancé » → on ne maintiendra plus, car on a deja pas mal de boulot aveec formidable et co
  • Correction guillement → ne sera sans doute plus maintenu, remplacé par orthotypo, qui a été corrigé pour le bug qu’il y a vait en 4.2
#36

Bonjour
je reviens sur cette remarque
oui il vaut mieux Mais … il y a encore quelques mois en arrière très peu de plugin étaient disponibles
donc je partait (à tort peut être) sur la version de Spip correspondant au plus haut niveau possible c’est pourquoi il y a encore 2 ans la version 3.2 était la plus aboutie car tous les plugins étaient ok
ces 6 derniers mois ça c’est accélérè et de plus en plus sont passables en 4.2

Pour citer un exemple pour passer un site en 4.2 je me bat depuis hier sur un petit plugin très pratique : ORR organisation de réservations de ressources, le seul qui fait ça à ma connaissance : code obsolète, javascript de 2013 et popup qui passe en lity et inclus le fichier en iframe :frowning:
faut il que je continue de débogger ou passer à autre chose ? telle est la question
ce n’est qu’un exemple pour pas mal de sites j’ai des plugins fait avec La Fabrique (merci pour la mise à niveau en 4.2 !! ) , des sliders plein écran jquery , etc…
bref tout cela prend un temps fou de tout tester en local et de reproduire en prod

donc j’y travaille mais je compte 1 an au moins pour passer ma quarantaine de sites de 3.2 à 4.2
la conclusion : je vais obliger les nouveaux clients à prendre un contrat de maintenance et les anciens à faire de même au fur et à mesure

bon wd à tous
Natacha

#37

Peut être enfonçai-je une porte ouverte, mais il est assez important, dans ce cas, que tu-et-chacun⋅e commite ensuite le résultat de ton-son adaptation via une ou plusieurs PR.
C’est seulement par ces contributions partagées que les mises à jours peuvent se faire plus facilement et plus rapidement ensuite, y compris pour toi-moi-tous.

#38

Je ne les connais pas, mais je vois qu’il y a aussi les plugins suivant, tous SPIP 4 ou 4.1 :

En fait c’est tellement l’abondance qu’un petit guide transversal serait bienvenu pour aider à s’y retrouver…

#39
  • ORR - Plugins SPIP nous dit qu’il est déprécié et, apparemment, utilisé 4 fois sur des sites publics. Il n’est pas compatible avec SPIP3.2 ou plus…

Perso, je re-partirai d’une feuille blanche. Mais faut voir avec les auteurs (ORR v2 - SPIP-Contrib) : ils ont peut-être des alternatives ?

#40

Bonjour chers amis,
Vous dire d’abord que je ne suis qu’un petit amateur auto-didacte qui a développé avec l’aide d’un copain du libre un site www.amis-robespierre.org . C’était en 2015 et j’ai galéré un peu au début pour comprendre la philosophie du logiciel et en découvrir la puissance éditrice et d’une certaine manière sa facilité d’utilisation.
Dans mon entourage d’autres ont préféré wordpress , tant mieux pour eux mais je préfère de loin spip même si je ne suis rien à côté des compétences techniques que la plupart d’entre vous avez. Quand je trouve un « petit truc » j’essaie de le faire partager mais de ce côté là c’est pour moi très limité.
Bien sûr, après avoir lu la doc, il me semble avoir compris l’importance qu’il y a pour moi de mettre à jour ma version 3.2.19 et passer à 4.1 puis 4.2 etc. Bon . Je suis passé de 3.2.16 à 3.2.19 avec spiploader (génial!) à la sortie, le pluging « imprimer » 3.1.56 qui permettait à mes internautes d’imprimer nos articles ne fonctionnait plus pas plus que la visibilité des couleurs dans la bande de traitement texte du privé. Par ailleurs, en local, en utilisant une méthode manuelle assez longue (raptriment du site et de la base (galère sur macintosh) j’ai réussi à mettre à jour en 4.1. Mais là ô surprise mes images retaillées en 3.2.19 par le plugin massicot ne l’étaient plus. Pour le reste ça avait l"air d’aller même le squelette de Giraud qui n’est plus mis à jour avait l’air de tenir (du moins les CSS) et mon sommaire.
Après, je me suis demandé si j’aurais le même résultat en tentant un spiploader sur le site public (chez OVH version php 7.4). Alors j’hésite à pousser plus loin. J’ai vérifié plusieurs fois si je n’avais pas été « attaqué » et je n’ai rien trouvé. J’utilise des plugins de sécurité FB anti spam et nospam .

Alors c’est un site associatif, on court après les sous (seules les cotisations de nos adhérents) et par les temps qui courent c’est dur. Alors je me débrouille avec les moyens du bord. Nos internautes apprécient. La plupart sont heureux d’y trouver des ressources fiables mais vous devinez que nous ne manquons pas d’adversaires sur la toile vu son contenu. Je cherche à en améliorer son accès et sa lisibilité au fur et à mesure. Mais je crains fort être un peu perdu dans la mise à jour des plugins.
Alors, je suis heureux de lire que 3.2.19 bien que non maintenu soit à jour s’agissant de la sécurité – du moins pour un temps !
Pour faire un essai de mise à jour sur le site public dois-je faire une copie de l’existant sur le site et pourrais-je y revenir si je me plante?
Merci de m’avoir lu .
Et félicitations à tous pour votre engagement votre travail coopératif et votre disponibilité et vive spip