mise a jour de la base

webmaster web-artstyle

Mai 2012

la mise a jour ne se fait pas pourquoi et commenfaire merci d’avance

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Quelles versions de SPIP ? Comment est-ce que vous faites votre mise à jour ?
Indiquez l’intérêt que vous portez à cette réponse

0

Mai 2012

la version de SPIP 3.0
Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Comment faites-vous la mise à jour ? Qu’est-ce que vous voulez dire par "ne marche pas" ?

Il y a des articles sur la mise à jour :
http://seonul.blogspot.fr/2012/04/mettre-jour-spip-2-vers-spip-3.html
par exemple
Indiquez l’intérêt que vous portez à cette réponse

0

dreline

Mai 2012

Bonjour,

Ce n’est pas moi qui ai posté les premiers messages, mais j’ai un problème de mises à jour qui me paraît similaire.

J’ai fait une copie du site d’origine sur laquelle je travaille, c’est en spip 2.1.14.

Je copie spip 3.0.1 dessus et je lance la procédure de MaJ de la BdB. Mais il bloque sur la MaJ. J’ai laissé tourner le script pendant 4h, il arrive rapidement à la MaJ 18597 mais bloque dessus.

J’ai essayé ensuite (en repartant de mes sauvegardes) de passer par spip 3.0.0, et la j’ai un message d’erreur de timeout lorsque j’accède à l’interface privée pour lancer la MaJ

"Fatal error : Maximum execution time of 30 seconds exceeded in /home/sdendev/www/dev/ecrire/public/debusquer.php on line 194 "

le numéro de ligne varie, j’ai essayé d’augmenter la valeur de timeout dans la config de mon serveur, c’est pareil.

J’ai eu le problème sur deux sites, l’un d’entre eux ayant quelques dizaines d’articles, l’autre étant beaucoup plus conséquent avec des millier d’articles et des centaines d’auteurs.
Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Ce que j’imagine, c’est qu’un des appels Ajax a bloqué au bout de 30s, donc aucun message d’erreur ne s’est affiché mais la mise à jour avait planté (donc attendre 4h n’a servi à rien). Eventuellement pour ne pas passer par Ajax, une solution est de désactiver le Javascript dans son navigateur avant d’aller à cette étape.

Inutile de passer par SPIP 3.0.0 car il y a un bug sur cette version qui affecte certaines configurations.

Est-ce que vous avez essayé le plugin migration ? Il marche assez bien pour passer d’une version 2.1 à une version 3.0

L’idée est de migrer votre site vers un autre installé dans un sous-répertoire (ou un autre domaine), puis de déplacer les fichiers et changer le nom du site dans le backoffice.

http://www.nursit.com/Le-plugin-migration-pour-SPIP

Sinon, est-ce que votre serveur est bien sous PHP > 5.1 ?
Avec safe_mode et register_globals désactivés ?

.Gilles
Indiquez l’intérêt que vous portez à cette réponse

0

dreline

Mai 2012

Merci de votre réponse.

J’ai essayé de désactiver javascript, au moins j’ai un message d’erreur :
MAJ 18597 . . Fatal error : Maximum execution time of 30 seconds exceeded in /home/sdendev/www/dev/ecrire/req/mysql.php on line 0

Je vais essayer le plugin, je vous tiens au courant.

Sinon, est-ce que votre serveur est bien sous PHP > 5.1 ?
Avec safe_mode et register_globals désactivés ?

Oui, je viens de vérifier
Indiquez l’intérêt que vous portez à cette réponse

0

dreline

Mai 2012

J’ai essayé le plugin : j’ai créé un site spip 3.0.1 dans lequel j’ai installé et lancé le plugin
J’ai installé et lancé la migration. Côté spip 2.1.14 il m’annonce des échecs sur quelques tables :

Migration des tables en cours (52)

1. spip_articles[Echec] .
18. spip_breves[Echec] .
34. spip_ortho_cache[Echec] .
36. spip_petitions[Echec] .
39. spip_rubriques[Echec] .
41. spip_syndic[Echec] .
42. spip_syndic_articles[Echec] .

les tables principales ne sont pas migrées. Les autres sont bien. Pour les documents, ça a l’air de bien se passer, mais il y en a 10000 à migrer.

J’ai quand même 5300 articles et 1200 brèves à migrer ensuite. Pourquoi ces tables ne sont-elles pas migrées ? Est-il possible qu’un plugin ayant modifié les tables puisse créer ce blocage ?
Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Le nombre d’articles ne me semble pas énorme, je ne vois pas pourquoi ça pourrait expliquer un plantage.

Peux-tu envoyer un message sur la liste de diffusion de spip-zone@rezo.net en indiquant tes erreurs (et un lien vers ce sujet) ? Les auteurs du plugin te répondront et corrigeront l’erreur du plugin si c’est lié à lui (ou l’adapteront par exemple en migrant les articles par paquets de 1000).

Effectivement, indique bien quels autres plugins tu as installés (même si en théorie le plugin Migration sait très bien gérer cela)
Le lien pour gérer ses abonnement sur spip-zone@rezo.net est http://listes.rezo.net/mailman/listinfo/spip-zone
Indiquez l’intérêt que vous portez à cette réponse

0
dreline

Mai 2012
En utilisant le plugin + copiant les bases dans phpmyadmin avec ces commandes :
create table spip_syndic_articles as select * from sden_spipDB.spip_syndic_articles; create table spip_syndic as select * from sden_spipDB.spip_syndic; create table spip_articles as select * from sden_spipDB.spip_articles; create table spip_breves as select * from sden_spipDB.spip_breves; create table spip_rubriques as select * from sden_spipDB.spip_rubriques
Je me rends compte de deux problèmes :
– si je ne mets pas la table rubriques, la MaJ de la base ne bloque pas, si je la mets la MaJ bloque.
– j’ai peut-être un problème d’encodage car la table rubrique est en latin1_swedish_ci

De plus la MaJ de la BDD n’a pas mis à jour correctement les articles et j’ai des erreurs de squelette.
Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Ca me semble un peu hasardeux de copier les bases - je ne sais pas exactement comment elles ont changé entre la version 2.1 et la version 3.0

Quand aux erreurs du squelette, il y a des choses à changer en passant entre ces deux versions majeures : http://www.spip-contrib.net/Migration-d-un-squelette-de-SPIP2-vers-SPIP-3-0
Indiquez l’intérêt que vous portez à cette réponse

0

dreline

Mai 2012

Quand je parle d’erreur de squelette, c’est dans la partie privée : des erreurs de champs de bases de données.

Quant à la copie des bases, je la fait avant la mise à jour. C’est pareil que de faire la mise à jour sur la base de départ, il me semble.

Je fais encore quelques test, mais je sens que je vais finir par faire ma propre procédure de mise à jour. J’ai l’impression qu’il y a une boucle infini quelque part. Je vais pas tarder à aller à la recherche des infos pour développeurs.

Je crois avoir trouvé mon bug à l’instant. En regardant dans la base pendant la mise à jour, je constate que certaines rubriques ont une profondeur de 639 .... 680 maintenant. J’ai trouvé ma boucle infini, je vais pouvoir corriger directement dans la base initiale et vérifier.
Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Super, tiens-nous au courant, ça peut intéresser du monde !!
Indiquez l’intérêt que vous portez à cette réponse

0

dreline

Mai 2012

Je ne sais pas comment ça c’est fait, mais trois rubriques avaient id_rubrique=id_parent, j’ai corrigé en mettant id_parent=id_secteur et la mise à jour passe.

Par contre le plugin continue à échouer lors de la copie des 7 tables et la procédure de mise à jour se termine par un "Ce site n’est pas encore configuré. Revenez plus tard..." mais c’est un autre problème.

Et aussi : le site public s’affiche a peu près correctement, mais j’ai manifestement un problème d’encodage :-)

Je vais repartir de zéro et ajouter la commande sql "update spip_rubriques set id_parent=id_secteur where id_rubrique=id_parent" en début de ma procédure de migration.
Indiquez l’intérêt que vous portez à cette réponse

0

Gilles

Mai 2012

Attention, id_secteur est le numéro des rubriques qui sont à la racine. Met plutôt id_parent=0.
Puis tu les déplaceras dans SPIP.
Indiquez l’intérêt que vous portez à cette réponse

0

dreline

Mai 2012

Non, je peux pas, on va les perdre sinon, on a plus de 200 secteurs :D

Justement, je les rattache à la rubrique qui est à la racine du secteur, ça permet de pas trop déranger. Puis il n’y en a que trois dans ce cas, et toutes dans le même secteur.

Au fait, j’ai refait toute ma procédure en repartant de ma sauvegarde de base de donnée, et ça marche nickel, on va pouvoir debugguer le squelette maintenant.