Mises à jour non effectuées / dépannage

Dev
#1

Soit un plugin qui est en version stable pour SPIP 3.2, mais en version test pour SPIP 4

Du coup pour l’instant SVP ne propose pas la mise à jour en SPIP 4 (bug corrigé en SPIP 4.2 / 01b39e7d6b si j’ai bien suivi).

Pour forcer la mise à jour, un utilisateur me rapporte avoir désactivé la vieille version puis activé la nouvelle. Le problème c’est que de cette façon, la mise à jour ne s’est pas effectuée correctement, il manque des nouveaux champs dans la table du plugin.

Comment on dépanne les gens dans ces cas là ?
Il y a une façon « accessible » de relancer la mise à jour ?

#2

C’est pas ce qui se fait de plus accessible, mais quand j’ai rencontré ce genre de cas j’allais remplacer dans la table spip_meta la valeur de prefixeplugin__base_version par une version plus basse que celle indiquée. Puis, un passage par la page d’admin des plugins permet alors de relancer la mise à jour de celui-ci (sinon tu peux la forcer en désactivant/réactivant celui-ci).

#3

Le 13/12/2022 à 11:12, b_b via Discuter de SPIP a écrit :

C’est pas ce qui se fait de plus accessible, mais quand j’ai rencontré ce genre de cas j’allais remplacer dans la table |spip_meta| la valeur de |prefixeplugin__base_version| par une version plus basse que celle indiquée. Puis, un passage par la page d’admin des plugins permet alors de relancer la mise à jour de celui-ci (sinon tu peux la forcer en désactivant/réactivant celui-ci).

C’est ce que je fais aussi toujours depuis des années quand ça c’est mal passé et que ça plante durant des màj. C’est la seule manière que j’ai trouvé, le seul moyen pour que SPIP rejoue des blocs de màj précis. Mais donc faut savoir changer des champs dans la base.

–
RastaPopoulos

#4

Du coup pour des utilisateurs lambdas c’est quand même pas génial.

Le cas ne doit pas être si rare car tant que SPIP 4.2 n’est pas releasé avec le fix qui va avec, SVP ne propose pas des mises à jour légitimes et donc les gens n’ont pas d’autre choix que de désactiver / réactiver des plugins pour disposer de la nouvelle version. Mais sans la mise à jour qui va avec…

Ça pose aussi question pour SVP : est-ce qu’il est pas censé garder en base le n° de schéma de la version désactivée afin de pouvoir lancer la maj quand une nouvelle version sera activée ?

#5

Le 13/12/2022 à 11:37, tcharlss via Discuter de SPIP a écrit :

Mais sans la mise à jour qui va avec…

Je ne comprends pas ce point dont tu parles. N’importe quel plugin activé, ça fait les màj suivant le version_base du plugin en question qui est toujours dans meta, peu importe que c’était déjà activé ou pas avant.

–
RastaPopoulos

#6

Bah non, pas pour la personne qui a rapporté l’erreur.

#7

Le 13/12/2022 à 11:58, tcharlss via Discuter de SPIP a écrit :

Bah non, pas pour la personne qui a rapporté l’erreur.

Oui mais est-ce qu’il y a une preuve que c’est à cause de ça ? Ça peut être n’importe quel autre problème un truc planté dans une des fonctions de màj, le truc qui est pété en plein milieu (mais qui a quand même mis le version_base à jour à la fin).

Le fait qu’elle doive le rejouer c’est une chose, ça ok. Mais la source du problème n’est à priori pas que SVP ne propose pas les màj en test etc, le fait de désactiver puis réactiver un plugin, ça lance bien les màj. D’ailleurs des fois on renomme tout plugins/ et ça désactive de fait tous les plugins d’un coup, et quand on remet le dossier, avec parfois pas les mêmes versions, du moment que version_base est différent du XML ça lance forcément les blocs de màj.

–
RastaPopoulos