Bonjour
Quand je lance spip_loader et que je valide la mise à jour, tout se passe comme d’habitude :
J’ai les messages Téléchargement de l’archive, installation, nettoyage, c’est fini et aucune erreur n’est signalée. Un dossier de fichiers obsolètes est créé.
Le seul souci est que le site reste en 4.4.16
J’ai pu mettre spip_loader à jour en 7.0.0, mais le problème est le même avant ou après.
Que faire ?
Salut, as-tu tenté un var_mode=recalcul dans l’espace privé ? (c’est peut-être un problème d’opcache un peu agressif)
Je viens d’essayer de lancer ecrire/?var_mode=recalcul` puis spip_loader.php, sans changement.
J’ai aussi vidé le cache depuis la configuration, sans effet.
Hello,
Cela m’est occasionnellement arrivé mais en relançant la maj, ça passe 
À noter qu’il y a maintenant une 4.4.19 
J’ai relancé une dizaine de fois et ça ne « passe » pas mieux.
C’est effectivement la 4.4.19 qui est maintenant proposée, mais sans plus de succès.
Comment puis-je voir si la mise à jour est effectuée ?
Tu peux consulter le fichier CHANGELOG.MD à la racine du site pour voir s’il mentionne bien la 4.4.19.
Sinon, peut-être que ton problème vient des permissions sur les fichiers du site et que l’utilisateur « web » n’a pas les droits pour les modifier.
Oui, c’est ça et après changement des droits ça marche bien.
Est-ce que cela ne devrait pas donner lieu à un message d’erreur. Si on ne vérifie pas la version, rien n’indique qu’elle a été mise à jour.
Voilà…
Quand la mise à jour est effectuée le numéro de version de SPIP dans le pied de page change. S’il ne change pas, en principe un simple recalcul le met à jour
Bonjour,
Serait‑ce une bonne idée de notifier l’utilisateur que la mise à jour n’a pas fonctionné ?
Soit en suivant quels fichiers n’ont pas été mis à jour ?
Ou, peut‑être plus simple, en redirigeant vers /ecrire mais avec ?spip_loader_version_expected=4.4.19
Et ensuite nous pourrions afficher une noisette : « Il semble que vous vouliez mettre à jour vers 4.4.19, mais la version actuellement installée est 4.4.18. Cela signifie que la mise à jour n’a pas fonctionné. Dans la plupart des cas, cela est dû à un problème de permissions sur votre serveur. » Quelque chose comme ça.
Ou juste « Mise à jour échouée ».
Oui, ce serait utile de notifier un échec de mise à jour.
Elle est tellement simple et fiable, par rapport à beaucoup d’autres CMS, qu’on ne pense pas toujours à vérifier !
A mon avis il faut juste mettre un message « Mise à jour échouée » et un lien vers une page spécifique de l’aide, qui listera les causes possibles et les solutions, et pourra être modifiée si besoin.
OK, cela m’intéresserait de contribuer à ce sujet.
Je pense le mieux serait une modification de spip_loader pour vérifier, à la fin du processus, s’il reste des fichiers qui n’ont pas pu être mis à jour.
À défaut, un contrôle du numéro de version serait déjà utile, mais je pense qu’il serait préférable de savoir si chaque fichier a bien été modifié. En effet, selon les permissions, certains fichiers peuvent être mis à jour et d’autres non, et ce serait dommage d’avoir une mise à jour partielle sans le savoir…
Comparer les md5file entre l’archive et le site pourrait être une solution, mais risque aussi d’être très coûteux en performance
Hello @marcimat, oui je pense que le mieux est simplement d’intercepter toutes les valeurs de retour des opérations de renommage / d’écriture / de déplacement. C’est quasiment gratuit en termes de performance.
Il semble que dans SPIP‑loader on faudrait intercepter les erreurs dans la fonction Filesystem::move_all et les faire remonter, ou les enregistrer pour les afficher plus tard sur une page d’erreur (affichée uniquement en cas de problème). Et le meme dans la fonction Cleaner (fichiers_obsoletes_...date).
Je peux faire une proposition.
J’ai ouvert un ticket si tu veux poursuivre là-bas
OK great, I will work on a commit.
J’ai envoyé une proposition