SPIP203 et sauvegarde de la base

Général
1

Bonsoir

Depuis que je suis passé en spip2.0.3, j'ai un petit souci avec la base.

Quand je sauve ma base du site en ligne pour la restaurer sur le site local, les rubriques ne sont pas restaurées.
J'ai bien les articles, les mots-clés ... mais pas les rubriques !?

C'est la sauvegarde qui ne fonctionne pas car dans phpMyAdmin, la table spip_rubriques ne retourne aucun enregistrement.

Une idée d'où ça peut venir ?

2

Jean-Christophe Villeneuve wrote:

C'est la sauvegarde qui ne fonctionne pas car dans phpMyAdmin, la table spip_rubriques ne retourne aucun enregistrement.

Bonsoir,
Et dans le fichier xml produit par la sauvegarde SPIP, lorsque tu l'ouvres avec un éditeur de texte ? Les rubriques y sont ont pas ?
C'est à dire : le problème, est-il à la sauvegarde ou à la restauration ?

Paolo

3

Paolo a écrit :

Jean-Christophe Villeneuve wrote:

C'est la sauvegarde qui ne fonctionne pas car dans phpMyAdmin, la table spip_rubriques ne retourne aucun enregistrement.

Bonsoir,
Et dans le fichier xml produit par la sauvegarde SPIP, lorsque tu l'ouvres avec un éditeur de texte ? Les rubriques y sont ont pas ?
C'est à dire : le problème, est-il à la sauvegarde ou à la restauration ?

Paolo

Je viens de vérifier et tout y est, semble-t-il.
Donc un problème de restauration, en effet, contrairement à ce que je pensais.
La base compressée ne fait 290Ko et non compressée (même problème) fait 1.54 Mo.

4

Jean-Christophe Villeneuve wrote:

Donc un problème de restauration,

Et si tu fais tourner ceci dans la fenêtre SQL de la base destinataire :
  SHOW CREATE TABLE `spip_rubriques`

Reçois-tu la réponse :

CREATE TABLE `spip_rubriques` (
  `id_rubrique` bigint(21) NOT NULL auto_increment,
  `id_parent` bigint(21) NOT NULL default '0',
  `titre` text,
  `descriptif` text,
  `texte` longtext,
  `id_secteur` bigint(21) NOT NULL default '0',
  `maj` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  `export` varchar(10) default 'oui',
  `id_import` bigint(20) default '0',
  `statut` varchar(10) NOT NULL default '0',
  `date` datetime NOT NULL default '0000-00-00 00:00:00',
  `lang` varchar(10) NOT NULL default '',
  `langue_choisie` varchar(3) default 'non',
  `extra` longtext,
  `statut_tmp` varchar(10) NOT NULL default '0',
  `date_tmp` datetime NOT NULL default '0000-00-00 00:00:00',
  `agenda` tinyint(1) NOT NULL default '0',
  PRIMARY KEY (`id_rubrique`),
  KEY `lang` (`lang`),
  KEY `id_parent` (`id_parent`)
) ENGINE=MyISAM AUTO_INCREMENT=xxx DEFAULT CHARSET=utf8

ou autre chose ?

Paolo

5

Paolo a écrit :

Jean-Christophe Villeneuve wrote:

Donc un problème de restauration,

Et si tu fais tourner ceci dans la fenêtre SQL de la base destinataire :
SHOW CREATE TABLE spip_rubriques

Reçois-tu la réponse :

Presque mais non

CREATE TABLE spip_rubriques (
id_rubrique bigint(21) NOT NULL auto_increment,
id_parent bigint(21) NOT NULL default ‹ 0 ›,
titre text NOT NULL,
descriptif text NOT NULL,
texte longtext NOT NULL,
id_secteur bigint(21) NOT NULL default ‹ 0 ›,
maj timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
export varchar(10) default ‹ oui ›,
id_import bigint(20) default ‹ 0 ›,
statut varchar(10) NOT NULL default ‹ 0 ›,
date datetime NOT NULL default ‹ 0000-00-00 00:00:00 ›,
lang varchar(10) NOT NULL default ‹  ›,
langue_choisie varchar(3) default ‹ non ›,
extra longtext,
statut_tmp varchar(10) NOT NULL default ‹ 0 ›,
date_tmp datetime NOT NULL default ‹ 0000-00-00 00:00:00 ›,
agenda tinyint(1) NOT NULL default ‹ 0 ›,
PRIMARY KEY (id_rubrique),
KEY lang (lang),
KEY id_parent (id_parent)
) ENGINE=MyISAM AUTO_INCREMENT=xxx DEFAULT CHARSET=utf8

et à la place de la dernière ligne :
) ENGINE=InnoDB DEFAULT CHARSET=utf8

C’est grave docteur ?

6

Jean-Christophe Villeneuve wrote:

`titre` text NOT NULL,
`descriptif` text NOT NULL,
`texte` longtext NOT NULL,

Ça, à mon avis, doit être le problème : cela veut dire que MySQL va réfuser à insérer toute rubrique qui manque un descriptif où un texte. Et probablement tu en as bcp. où un champs où l'autre ne contient aucune information.

Comment est-ce que la définition est arrivée à être ainsi ?

Pour la question de MyISAM / InnoDB, j'ignore si ceci est important ou non. Le deux choses sont-elles liées ? Je ne sais pas non plus.

Toutes tes tables sont-elles sous InnoDB ou seulement spip_rubriques ?

Paolo

7

Pour information, j’ai aussi des soucis de restauration de base sous spip2.0.3.
je pensais que le prob venait essentiellement du plugin champs extra2.
J’ai laissé un message sur:
http://www.spip-contrib.net/Champs-Extras-2#forum412887

Beru

Le 5 février 2009 21:50, Paolo <paolo2@taize.fr> a écrit :

Jean-Christophe Villeneuve wrote:

titre text NOT NULL,
descriptif text NOT NULL,
texte longtext NOT NULL,

Ça, à mon avis, doit être le problème : cela veut dire que MySQL va réfuser à insérer toute rubrique qui manque un descriptif où un texte. Et probablement tu en as bcp. où un champs où l’autre ne contient aucune information.

Comment est-ce que la définition est arrivée à être ainsi ?

Pour la question de MyISAM / InnoDB, j’ignore si ceci est important ou non. Le deux choses sont-elles liées ? Je ne sais pas non plus.

Toutes tes tables sont-elles sous InnoDB ou seulement spip_rubriques ?

Paolo

liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

irc://irc.freenode.net/spip ou http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip

8

Paolo a écrit :

Jean-Christophe Villeneuve wrote:

`titre` text NOT NULL,
`descriptif` text NOT NULL,
`texte` longtext NOT NULL,

Ça, à mon avis, doit être le problème : cela veut dire que MySQL va réfuser à insérer toute rubrique qui manque un descriptif où un texte. Et probablement tu en as bcp. où un champs où l'autre ne contient aucune information.

Et j'y peux quoi ?
ce qui est bizarre (je n'y connais rien en MySQL) c'est que
SHOW CREATE TABLE `spip_articles`
me donne
CREATE TABLE `spip_articles` (
`id_article` bigint(21) NOT NULL auto_increment,
`surtitre` text NOT NULL,
`titre` text NOT NULL,
`soustitre` text NOT NULL,
`id_rubrique` bigint(21) NOT NULL default '0',
`descriptif` text NOT NULL,
`chapo` mediumtext NOT NULL,
`texte` longtext NOT NULL,
`ps` mediumtext NOT NULL,
`date` datetime NOT NULL default '0000-00-00 00:00:00',
`statut` varchar(10) NOT NULL default '0',
`id_secteur` bigint(21) NOT NULL default '0',
`maj` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`export` varchar(10) default 'oui',
`date_redac` datetime NOT NULL default '0000-00-00 00:00:00',
`visites` int(11) NOT NULL default '0',
`referers` int(11) NOT NULL default '0',
`popularite` double NOT NULL default '0',
`accepter_forum` char(3) NOT NULL default '',
`date_modif` datetime NOT NULL default '0000-00-00 00:00:00',
`lang` varchar(10) NOT NULL default '',
`langue_choisie` varchar(3) default 'non',
`id_trad` bigint(21) NOT NULL default '0',
`extra` longtext,
`id_version` int(10) unsigned NOT NULL default '0',
`nom_site` tinytext NOT NULL,
`url_site` varchar(255) NOT NULL default '',
PRIMARY KEY (`id_article`),
KEY `id_rubrique` (`id_rubrique`),
KEY `id_secteur` (`id_secteur`),
KEY `id_trad` (`id_trad`),
KEY `lang` (`lang`),
KEY `statut` (`statut`,`date`)
) ENGINE=InnoDB AUTO_INCREMENT=494 DEFAULT CHARSET=utf8

avec des NOT NULL partout et pourtant les articles sont bien restaurés avec id_secteur rempli dans la base.
Et tout n'est pas rebseigné, loin de là (pas de surtitre, de soustitre, de chapeau, ...)

Comment est-ce que la définition est arrivée à être ainsi ?

Pour la question de MyISAM / InnoDB, j'ignore si ceci est important ou non. Le deux choses sont-elles liées ? Je ne sais pas non plus.

Toutes tes tables sont-elles sous InnoDB ou seulement spip_rubriques ?

Paolo

les 2-3 que j'ai vérifié oui

9

Jean-Christophe Villeneuve wrote:

SHOW CREATE TABLE `spip_articles`
me donne

> ...

avec des NOT NULL partout et pourtant les articles sont bien restaurés

Eh bien. Alors je ne sais pas.

Suggestion : faire un dump phpMyAdmin de la base, et la faire restaurer dans une nouvelle base de données (également par phpMyAdmin). Voir si cela te donne une base MyISAM.

Ensuite faire des changements dans la base d'origine et reessayer le transfert avec la sauvegarde de SPIP.

Mais je suis autant dans l'obscurité que toi.

Paolo

10

Paolo a écrit :

Suggestion : faire un dump phpMyAdmin de la base, et la faire restaurer dans une nouvelle base de données (également par phpMyAdmin). Voir si cela te donne une base MyISAM.

on peut aussi lancer
  ALTER TABLE ma_table ENGINE=MYISAM;
pour chaque table spip_
mais je doute que le problème soit lié au type de moteur...

sinon, en 2.0.3, on peut ne sauvegarder que la table spip_rubriques
et, à tant faire, en format non compressé.
le tenter pour voir si le dump est correct en l'éditant.
il y a peut-être (mais pourquoi donc) un tag mal fermé (< sans >)

ou encore n'exporter que cette table là en passant par phpmyadmin et la restaurer en local toujours par phpmyadmin...

11

denisb a écrit :

Paolo a écrit :

Suggestion : faire un dump phpMyAdmin de la base, et la faire restaurer dans une nouvelle base de données (également par phpMyAdmin). Voir si cela te donne une base MyISAM.

on peut aussi lancer
ALTER TABLE ma_table ENGINE=MYISAM;
pour chaque table spip_
mais je doute que le problème soit lié au type de moteur…

sinon, en 2.0.3, on peut ne sauvegarder que la table spip_rubriques
et, à tant faire, en format non compressé.
le tenter pour voir si le dump est correct en l’éditant.
il y a peut-être (mais pourquoi donc) un tag mal fermé (< sans >)

ou encore n’exporter que cette table là en passant par phpmyadmin et la restaurer en local toujours par phpmyadmin…

Bien je mène l’enquête …
C’est visiblement le plugin Agenda2 qui pose problème.
Dès que celui-ci est désactivé en local, tout rentre dans l’ordre.

J’ai donc essayé de le supprimer puis de le réinstaller.
Tiens j’ai besoin de spip-bonux 1.3 minimum et je n’ai que la 1.2
Ok je supprime aussi et je réinstalle
Aie, problème si je sélectionne spip-bonux dans la liste auto
Fatal error: Call to undefined function filtre_implode() in C:\wamp\www\Jules203\ecrire\public\composer.php(51) : eval()'d code on line 35

Je poursuis l’enquête …

12

Jean-Christophe Villeneuve a écrit :

denisb a écrit :

Paolo a écrit :

Suggestion : faire un dump phpMyAdmin de la base, et la faire restaurer dans une nouvelle base de données (également par phpMyAdmin). Voir si cela te donne une base MyISAM.

on peut aussi lancer
ALTER TABLE ma_table ENGINE=MYISAM;
pour chaque table spip_
mais je doute que le problème soit lié au type de moteur…

sinon, en 2.0.3, on peut ne sauvegarder que la table spip_rubriques
et, à tant faire, en format non compressé.
le tenter pour voir si le dump est correct en l’éditant.
il y a peut-être (mais pourquoi donc) un tag mal fermé (< sans >)

ou encore n’exporter que cette table là en passant par phpmyadmin et la restaurer en local toujours par phpmyadmin…

Bien je mène l’enquête …
C’est visiblement le plugin Agenda2 qui pose problème.
Dès que celui-ci est désactivé en local, tout rentre dans l’ordre.

J’ai donc essayé de le supprimer puis de le réinstaller.
Tiens j’ai besoin de spip-bonux 1.3 minimum et je n’ai que la 1.2
Ok je supprime aussi et je réinstalle
Aie, problème si je sélectionne spip-bonux dans la liste auto
Fatal error: Call to undefined function filtre_implode() in C:\wamp\www\Jules203\ecrire\public\composer.php(51) : eval()'d code on line 35

Je poursuis l’enquête …


---

J’ai bien essayé de mettre les mêmes versions de tous les plugins en local et en ligne.
Et c’est toujours le même problème.
Bon au moins je sais comment biaiser mais ce n’est pas complètement satisfaisant.
Merci de l’aide apportée.