Bonjour chers développeurs Spip 
Veuillez simplifier le processus de mise à jour de Spip dans l’espace privé sans avoir besoin du fichier externe ‹ spip_loader › 
De nombreux utilisateurs ne peuvent pas comprendre les paramètres FTP et binaires, même eux sont confus lorsqu’ils sont invités à saisir l’URL /spip_loader.php
Il y a aussi des developpeuse SPIP.
Quant à la question de base : cela pose plein de problème sous jacent. Mais des gens y reflechissent.
1 « J'aime »
Bonjour Hacen,
Combien de logiciels web / CMS connais-tu qui ont la fonctionnalité que tu indiques ? de mise à jour avec un bouton dans le back-office ?
Et quelle version de SPIP utilises-tu actuellement ? En 4.3, si tu as le spip_loader.php sur ton site, un lien vers lui est indiqué dans le back-office déjà.
Au delà de ça, je t’invite à réfléchir à comment ça devrait fonctionner techniquement, et de combien de bouton « mettre à jour » il devrait y avoir : imagine ton site est en 4.2.15 : il pourrait te proposer : 4.2.16, 4.3.5, 4.4.0, 5.0.0 (lorsque ces versions seront sorties) ? Comment l’utilisatrice sait la version qui ne cassera rien sur son site ?
La personne qui a réussie à installer le site doit logiquement aussi avoir un minimum de compétences pour gérer les mises à jour dans la durée, du SPIP et de ses plugins utilisés.
Ce sujet est difficile, et déjà actuellement le spip-loader ne gère pas de nombreux points qui pourraient pourtant être pertinents :
- s’assurer que l’archive du SPIP récupérée est bien «signée» (ie: est bien celle attendue et n’a pas été modifiée par un tiers)
- s’assurer que l’intégralité des fichiers sont correctement copiés
- pouvoir rollback (revenir en arrière) si un problème à la migration survient…
Et tous ces points, depuis le «web» (ie: pas en ssh / CLI dans un terminal), ce n’est pas évident (timeout notamment…)
Bref: au vu de nos effectifs, le spip-loader c’est déjà très bien ! Mais si qqn·e veut prendre le temps de se pencher sur les questions que tu soulèves tout en maintenant un minimum de sécurité, iel sera certainement bienvenu·e.
4 « J'aime »
Un peu à propos, pour quelle raison déjà le spip_loader n’est il pas livré avec SPIP ?
1 « J'aime »
Dans le web, en général, il est normal de découpler l’outil qui fait les déploiements, de l’outil que tu déploies. Je ne sais pas si c’est une raison suffisante, mais ça peut en être une pour sûr.
1 « J'aime »
Bonjour @maieul c’est merveilleux que parmi l’équipe de développement de Spip, il y ait des reines, tout le respect et la gratitude
Salutations @marcimat Disons que WordPress a la fonctionnalité d’être mis à jour directement depuis le tableau de bord, veuillez prendre en considération que de nombreux « nouveaux » utilisateurs de Spip viennent de WP et de Drupal, nous voulons simplement leur permettre d’utiliser Spip et leur faciliter la maintenance via leur propre espace privé. Je peux vous dire que beaucoup d’utilisateurs que j’invite à utiliser Spip s’abstiennent à cause du processus de mise à jour qu’ils considèrent comme « fatigant ».
Moi je ne parle que des « nouveaux » utilisateurs de Spip que j’essaie toujours de les amener dans mon univers Spip bien-aimé, je suis un fier utilisateur de Spip depuis 2005 et c’est toujours mon seul choix qui ne peut pas être remplacé. Je suis juste venu ici pour suggérer quelque chose auquel je suis confronté quotidiennement en invitant de nouveaux utilisateurs.
Bonjour @JLuc c’est quelque chose de vraiment nécessaire, de distribuer le Spip Loader à l’intérieur de l’installation de Spip et d’avoir son lien à l’intérieur de l’espace privé, sans avoir besoin d’expliquer aux nouveaux utilisateurs le processus ordinaire qui peut en faire abandonner beaucoup.
1 « J'aime »
Parmi ceux que je connais bien, Prestashop et Dolibarr, de façon native.
Il me semble que c’est le cas de Nextcloud aussi dans les trucs très connus (et encore plus gros qu’un CMS).
Pas anecdotique quoi, WP, Nextcloud, Presta, les trois plus utilisés en libre chacun dans leur domaine (et du coup ça devient un peu la norme de ce que les gens attendent ensuite comme on le voit…). Je suppose qu’ils font ça de manière sécurisé. Mais ils ont tous des plus grosses équipes (et pas qu’un peu).
Dolibarr, je n’ai pas trouvé, mais Prestashop, il y a un module dédié How to use the Upgrade Assistant :: PrestaShop Developer Documentation et le code GitHub - PrestaShop/autoupgrade: Upgrade module for PrestaShop … mais bon, c’est du gros machin déjà. Y ptet plus de fichiers dans leur répertoire classes pour gérer cela que dans tout spip/ecrire !
Pour Nextcloud, ça semble cela GitHub - nextcloud/updater: 🔄 The updater app to keep your Nextcloud up-to-date et c’est plus léger déjà.
Ah mais oui, bien sûr Nextcloud 
J’en maintiens un gros en plus, et je fais les mises à jour par l’interface web et pas par occ, même pas peur.
Oui, pour Prestashop ça passe par un module (i.e. plugin) mais développé par Prestashop et livré en standard.
Pour Dolibarr c’est intégré à l’appli, on fait les mises à jour de façon séquentielle.
Si tu as un vieux Dolibarr, la procédure te fait passer par toutes les versions x au fur et à mesure : mise à jour du code (fichiers), de la bdd (structure), migrations (data), et retour au départ pour la version x+1, jusqu’à la version x.y.z courante.
Accessoirement, il y a un ticket en fait pour ça déjà (presque du moins)
A noter au passage que Prestashop comme Nextcloud commencent par faire un backup complet du site avant le lancer la mise à jour en elle même.
Et que la mise à jour n’est pas automatique, contrairement à WP, mais requiert une action spécifique dans le back office.
À vérifier mais de mémoire dans WP ya des mises à jour auto possible que pour les petites mises à jour. Et par contre si on change de grosse branche là faut bien une action volontaire aussi. Mais du coup si pas désactivé (car activé par défaut), tout ce qui est sécu ya même plus à y penser dans ce cas…
Et DotClear, qui a une toute petite équipe (une seule personne à ma connaissance).
Non, WP fait toutes les mises à jour (mineures et majeures) automatiquement.
Idem pour les plugins et les thèmes.
1 « J'aime »
Pour WP l’automatisme est paramétrable pour le core et pour les extensions. Pour le core on peut choisir de ne faire que les mineures ou les mineures et majeures. En général je désactive la mise à jour auto des majeures du core.
Pour Nextcloud c’est depuis le back-office sur action volontaire sauf pour les instances avec bcp d’utilisateurs (>20) ou il est conseillé d’utiliser la ligne de commande occ (mais à priori sur de grosses instances quelqu’un s’en occupe).
Pour Prestashop depuis le back-office sur action volontaire, c’est un module one-click upgrade qui effectivement sauvegarde au préalable. Modules par action volontaire.
Pour Joomla par le back-office, par action volontaire pour le core et les modules.
Dans la demande initiale je n’ai pas l’impression que la demande soit un automatisme, j’ai l’impression qu’il souhaiterait simplement que spip_loader soit livré avec spip et avec un bouton pour faire la mise à jour, genre bouton accessible seulement aux webmestres (comme des actions de maintenance).
La difficulté semble être le fait de devoir utiliser le FTP pour installer ce fichier, avec potentiellement l’impression (que j’ai eu longtemps) qu’on avait intérêt à supprimer le fichier. Ça me semble hyper simple (ça semble toujours simple vu de l’extérieur) comme je trouvais simple ma suggestion d’inclure un lien vers spip_loader dans le mail de notification, cette demande a été rejetée suite à des suggestions complémentaires (faire d’abord un lien vers la maj des plugins) qui compliquait tellement la chose que la demande simple du début a été abandonnée.
1 « J'aime »
@marcimat La raison « il est normal de découpler » est l’expression d’une autorité, mais ce n’est pas une explication.
Ceci dit, installer spip_loader n’est pas baucoup plus difficile que d’installer spip initialement. C’est tout de même plus difficile car il faut passer le transfert en mode binaire, ce qui est d’une technicité plus élevée pour un⋅e néophyte.
Mais surtout, j’imagine, le problème se pose pour celleux qui reçoivent un spip clé en main installé par genre un⋅e pro ou par une connaissance qui s’y connaît, et qui doivent par la suite faire les mises à jour … alors que spip_loader n’a pas été installé / ou qu’on ne leur pas donné les autorisations / ou expliqué. C’est à de telles situations que tu es confronté @Hacen ? Car je vois pas bien sinon.
Une solution faisable à l’échelle de la communauté de Spip serait de mettre en place un système de mise à jour automatique de l’écran de sécurité.
Explication : Il y a de grandes chances que cette demande fasse suite à la vague d’attaques de sites Spip qui se sont déroulé depuis l’été 2024. Or la plupart des utilisateurs ne cherchent pas obtenir les dernières petites évolutions innovantes disponibles désormais chaque mois, mais juste à garder un environnement sécurisé.
Ne pourrait-on pas inétgrer à Spip un job qui s’assure à échéance fixe (paramétrable) que la version de l’écran de sécurité dispo sur le site soit bien la dernière ?