Bonjour,
Le problème semble hélas toujours présent sur SPIP 3.0.14 qui est pourtant la dernière version.
Il m’a été remonté par une utilisatrice qui testait la future version du kit labos du CNRS ; celle-ci a voulu restaurer une sauvegarde réalisée sur un site SPIP 3/SQLite (elle est partie d’une base vierge sur un SPIP 3.0.11), et s’est retrouvée avec un site vide, dans lequel ses rubriques, ses articles, etc. avaient disparu, cela sans aucune possibilité de revenir en arrière, car nous avons réalisé après coup que toutes ses sauvegardes étaient en fait vides.
Je constate par ailleurs qu’aucun message d’erreur explicite n’est affiché dans ce cas. On a pourtant la coche verte et un message indiquant que la sauvegarde a bien été réalisée ; en fait, il faut vraiment faire très attention à la liste des tables située dessous, et au nombre indiqué d’enregistrements copiés, sur le nombre présents en base. Par ailleurs les logs indiquent de nombreuses erreurs, et cela même sur des sites dont la sauvegarde fonctionne correctement. Il y a apparemment des lacunes dans la détection et la gestion des erreurs, en particulier dans ecrire/req/sqlite_generique.php ligne 933 dans function spip_sqlite_insertq_multi() où il n’y a aucune gestion d’erreur sur
if ($requeter)
$retour = spip_sqlite::executer_requete($query,$serveur);
et c’est pourtant sur cette ligne que l’erreur d’insertion a lieu, c’est pourquoi les erreurs passent inaperçues.
Je ne peux aujourd’hui expliquer pourquoi, mais cette utilisatrice a une structure de données qui ne correspond pas à la structure de base "dump" de destination, d’où les erreurs sur insertion à cause de champs en trop, comme indiqué en #25 :
– extra (longtext) présent dans spip_articles, _breves, _mots, _rubriques et _syndic ;
– id_version (unsigned) présent dans spip_articles.
Par ailleurs les "CREATE TABLE" que j’ai pu afficher avec un client SQLite présentent d’autres différences plus subtiles entre une installation normale et celle qui bugue :
– certains champs ne sont pas dans le même ordre,
– dans certaines tables, certains types (timestamp, varchar) sont en minuscule dans la version buguée alors qu’ils sont en majuscule dans la normale,
– l’ordre NOT NULL DEFAULT ’’ / DEFAULT ’’ NOT NULL varie,
– certains types diffèrent, par ex : int(11) au lieu de integer
– certains types sont plus précis, par ex : maj timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP à la place de maj TIMESTAMP
– etc.
Je n’explique pas qu’il y ait de telles différences de structure.
J’ai refait une install d’un SPIP plus ancien (3.0.11), sur laquelle cette utilisatrice était partie ; j’ai même volontairement désactivé l’extension PHP sqlite3 dont la présence n’était apparemment pas testée avant la 3.0.13, et fait une install basée juste sur la librairie sqlite (pas 3). Puis j’ai réactivé SQLite3, mais même dans ce cas j’ai une structure de données tout à fait normale. J’ai bien sûr également remis tous les plugins qui étaient sur son site.
Si je ne comprends pas pourquoi on peut se retrouver avec une structure de données avec de telles différences, le fait est que le cas peut se présenter, et que le système de backup est bugué, indiquant des erreurs apparemment où il ne devrait pas y en avoir (il suffit de regarder dans spip.log tous les "no such table", même avec une sauvegarde qui se déroule bien), et ne détectant pas des erreurs graves qui peuvent conduire, pour ceux qui n’y font pas attention, à la purge de tout ce qui a été saisi sur le site en faisant une simple restauration d’un mauvais backup...
Je pense que ce fil ne devrait pas être marqué comme résolu, la manipulation consistant à supprimer à la main des champs en base de données me semble plutôt de la bidouille qu’une vraie solution, non ?