Impossibilité de restaurer des versions précédentes

Support
#1

Nous venons de relever un souci sur un de nos wikis, la restauration ne fonctionne plus.
Lorsqu’on sélectionne une ancienne version et que l’on clique sur restaurer, la page semble s’actualiser pour au final ne rien restaurer et revenir sur la dernière version.
Nous n’avons pour le moment pas de piste sur la source du problème.

Le wiki : La cartographie des lieux de médiation numériques en AURA : Lieux de médiation numérique en région AURA
Il est en libre modification et c’est une duplication de l’original donc pas de soucis pour faire des tests dessus.

Est-ce que vous auriez des pistes pour le débogage ?

#2

Le wiki n’est pas si ouvert en tout cas la page en lien ne permet pas l’édition et donc pas possible de regarder l’historique des modifications…
Il ne serait pas en mode archive par hasard?

#3

Hello @mrflos :slight_smile:
en fait les pages ne sont pas ouvertes mais toutes les fiches bazar le sont (désolé pour l’incompréhension) Exemple au hasard La cartographie des lieux de médiation numériques en AURA : Maison du lien - Espace de Vie Sociale de Nantuaa ou tout autre lieu La cartographie des lieux de médiation numériques en AURA : Lieux de médiation numérique en région AURA
Et non malhreusement il est pas en hibernate.
NB : On a le même souci sur le site de prod La cartographie des lieux de médiation numériques en AURA : La Carto'HINAURA des lieux de médiation numérique en Auvergne Rhone Alpes :frowning: :frowning: :frowning:

#4

Je peux vous indiquer une piste, mais hélas pas bien plus que cela, car je n’arrive pas a reproduire le bug sur un yeswiki 4.4.1 comme celui de yeswiki.net ( a priori en 4.4.0 j’imagine que ca marche, mais au cas ou, passez en 4.4.1) .

Je remarque que le bouton « restaurer cette version » renvoie toujours sur une url avec un id= a zero : La cartographie des lieux de médiation numériques en AURA : Maison du lien - Espace de Vie Sociale de Nantua alors que l’id devrait etre le numéro de la version de page (un chiffre genre 134, 1653, ou autre, correspondant au champs id dans la table <prefixe>_pages dans votre bdd).

Je pense qu’il faudrait désactiver les modifications dans le dossier custom et enlever les extensions supplémentaires jusqu’a arriver dans un état qui permette de restaurer, et donc de trouver la modification coupable.

Autre piste : vérifier l’intégrité de votre base de données: la colonne id dans la table <prefixe>_pages a t’elle bien des chiffres variés ou que des 0 ?

#5

Finalement, le problème venait de notre côté.

Afin de corriger des erreurs, un export/import de la base a eu lieu et le paramètre auto-increment (cf ici) de la colonne id a sauté au passage… Autant pour nous !

#6

Du coup à penser à chaque fois qu’on fait des exports/imports de base (pour travailler dans notre cas sur MysQL plutôt que phpmyadmin) de remettre ce paramètre via une requête type
ALTER TABLE yeswiki_pages DROP column id;
ALTER TABLE yeswiki_pages ADD id INTEGER;
ALTER TABLE yeswiki_pages MODIFY id INTEGER NOT NULL AUTO_INCREMENT FIRST PRIMARY KEY;
Encore désolé pour le dérangement :frowning: