J'ai entrepris le passage d'un site de 1.7.1 à 1.8.3
L'upgrade de la base a réussi, et la partie privée fonctionne.
Seul étonnement : il n'y a pas de prévisualisation possible.
ça devrait pourtant sur une 1.8.3 ?
Mais surtout, la partie publique reste désespérément vide :
blanc complet, source vide, partout où ça passe par spip.
J'ai essayé diverses choses pour débloquer ça :
- vider le cache
- effacer ecrire/inc_meta_cache
- effacer le contenu de CACHE
- vérifier le mes_fonctions.php3 à la racine (yen a un)
et le mes_options dans ecrire (yen a pas)
et aussi pour aller dans le sens du progrés :
- virer les dist qui trainaient
- mettre les squelettes html dans le dossier squelettes
Dans le spip.log je vois pas d'erreur à part des échecs d'indexation
des documents mais c'est peut être du à l'absence de parsers systèmes :
"Echec de l'extraction de 'IMG/doc/doc-2.doc'"... ou xxx.pdf
Dans le fichier mysql.log ya plein de trucs bizarres
je les met à la fin de ce mail. Peut êtr ça vous causera ?
Car je sais plus quoi faire, le site public est en rade complète,
pouvez vous m'aider ?
JL
Voici les trucs bizarres dans les mysql.log :
- Unknown column 'rub.date_tmp' in 'where clause' - SELECT rub.id_rubrique AS id,
max(fille.date_heure) AS date_h
FROM `passerelleco`.spip_rubriques AS rub, `passerelleco`.spip_breves AS fille
WHERE rub.id_rubrique = fille.id_rubrique
AND rub.date_tmp <= fille.date_heure AND fille.statut='publie'
GROUP BY rub.id_rubrique
- plein de :
GET /spip_background.php3
Unknown column 'statut_tmp' in 'field list' - UPDATE `passerelleco`.spip_rubriques
SET statut_tmp='publie', date_tmp='2004-08-12 10:47:25'
WHERE id_rubrique=67
pour toutes les rubriques en fait.
(yaurait un lien avec l'absence de prévisu ?)
- POST /ecrire/upgrade.php3
- Unknown table 'spip_id_message_caches' - DROP TABLE `passerelleco`.spip_id_message_caches
- Unknown table 'spip_id_rubrique_caches' - DROP TABLE `passerelleco`.spip_id_rubrique_caches
- Unknown table 'spip_id_signature_caches' - DROP TABLE `passerelleco`.spip_id_signature_caches
- Unknown table 'spip_id_syndic_article_caches' - DROP TABLE `passerelleco`.spip_id_syndic_article_caches
... et puis aussi des :
- Can't DROP 'texte'; check that column/key exists - ALTER TABLE `passerelleco`.spip_versions DROP texte
- Can't DROP 'ps'; check that column/key exists - ALTER TABLE `passerelleco`.spip_versions DROP ps
...
et enfin
- You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right - syntax to use near 'ADD INDEX idx (idx)' at line 1 - ALTER TABLE `passerelleco`.spip_forum ADD ADD INDEX idx (idx)
J'ai entrepris le passage d'un site de 1.7.1 à 1.8.3
L'upgrade de la base a réussi, et la partie privée fonctionne.
...
mais la partie publique reste désespérément vide :
blanc complet, source vide, partout où ça passe par spip.
mysql.log :
- Unknown table 'spip_id_message_caches' - DROP TABLE `passerelleco`.spip_id_message_caches
- Unknown table 'spip_id_rubrique_caches' - DROP TABLE `passerelleco`.spip_id_rubrique_caches
- Unknown table 'spip_id_signature_caches' - DROP TABLE `passerelleco`.spip_id_signature_caches
- Unknown table 'spip_id_syndic_article_caches' - DROP TABLE `passerelleco`.spip_id_syndic_article_caches
Effectivement, ces tables n'existent pas dans la bdd.
Elle devraient ?
... et puis aussi des :
- Can't DROP 'texte'; check that column/key exists - ALTER TABLE `passerelleco`.spip_versions DROP texte
- Can't DROP 'ps'; check that column/key exists - ALTER TABLE `passerelleco`.spip_versions DROP ps
Effectivement, ces champs n'existent pas dans la table spip_versions.
Ils le devraient ?
J'ai entrepris le passage d'un site de 1.7.1 à 1.8.3
L'upgrade de la base a réussi, et la partie privée fonctionne.
...
mais la partie publique reste désespérément vide :
blanc complet, source vide, partout où ça passe par spip.
mysql.log :
- Unknown table 'spip_id_message_caches' - DROP TABLE `passerelleco`.spip_id_message_caches
- Unknown table 'spip_id_rubrique_caches' - DROP TABLE `passerelleco`.spip_id_rubrique_caches
- Unknown table 'spip_id_signature_caches' - DROP TABLE `passerelleco`.spip_id_signature_caches
- Unknown table 'spip_id_syndic_article_caches' - DROP TABLE `passerelleco`.spip_id_syndic_article_caches
Effectivement, ces tables n'existent pas dans la bdd.
Elle devraient ?
Bon j'ai tout vidé et réinstallé une 1.8.3 clean
et ces tables n'ont pas été installées non plus.
Elles semblent ne pas devoir exister
sauf dans une version intermédiaire
d'ailleurs elles ne sont référencées nulle part
sauf pour être effacées pendant l'upgrade...
Mauvaise piste.
Peut être ça vient des fichiers php3 de l'ancienne version 1.7
qui interfereraient avec les nouveaux php3 ou php de la nouvelle 1.8.3 ?
Après avoir essayé plein de trucs je dois reconnaître l'échec.
J'ai réinstallé la version 1.7 et restauré la base via la sauvegarde spip.
Je vais maintenant essayer scrupuleusement la procédure décrite
ci après le 02/04/2005... on sait jamais.
Je vais cette fois aussi passer par une version 1.8 intermédiaire
au cas où ce serait plus facile, avant de passer à la 1.8.3
Si vous avez des conseils, c'est toujours bienvenu.
JLuc
rpapa a écrit :
> > je crois que nous devrions définir ensemble une procédure de passage de
> > spip 1.7 à spip 1.8
> > je vous propose d'ammender la mienne et de l'améliorer
> >
> > la mienne (testée sur plusieurs sites)
> > - d'abord une sauvegarge de la base de données
> > - réinstallation en local de cette base de données avec spip 1.7
> > l'objectif avoir une sauvegarde correcte
> >
Je teste la mise à jour en local sur une seconde copie locale.
> > procédure de mise à jour avec spip 1.8
> > - effacer le répertoire racine de spip (spip 1.8 n'utilise pas les m^mes
> > fichiers au meme endroit
> > - sauvegarder inc-connect.php3 (pour ma part je le pose temporairement
> > dans IMG)
> > - sauvegarder si necessaire mes_fonctions.php3 et mes_options.php3 si
> > vous les utilisez
> > - effacer le contenu de /ecrire/
> > - effacer le répertoire cache
> > - installer spip1.8 (je n'utilise pas le spip_loader)
> > - remettre inc_connect.php3
> > - se loguer dans /ecrire/
> > - spip 1.8 va réinitialiser la base de données (parfois ça plante!!!,
> > moi je n'ai pas eu de gros pb)
> > - retourner dans le site public
> > et la en général ça a marché
> >
> > PS -n'oubliez pas de réinstaller les fichiers mes_fonctions et
> > mes_options mais avant vérifiez que certaines des options que vous
> > préréglier sont encore utiles
> >
Je justifierais ta méthode parce qu'avec des mises à jours successives, au fil des versions, des tas de petits fichiers sont venus et certains sont inutiles et peuvent parfois poser problème. (une liste non exhaustive en avait été donnée)
Il conviendrait tout de même de sauver les squelettes (les couples .php3 et .html)
Mettres les .html dans le dossier (a créer) squelette (avec ou sans S je ne sais plus)
Après avoir essayé plein de trucs je dois reconnaître l'échec.
J'ai réinstallé la version 1.7 et restauré la base via la sauvegarde spip.
Pourquoi n'essaies-tu pas la version 1.92 qui récupère bien les anciennes bases? SPIP 1.9.2 - SPIP
Ce serait grand luxe pour l'accés aux pluggins et au compilateur ++.
Et la version 1.92 affirme en effet implémenter une
"restauration fiable des anciennes versions ou créées
par phpmyadmin (au format XML)"
et une "restauration accélérée et corrigée sur son traitement
des entités HTML."
Cependant il y a tant de choses modifiées depuis la 1.7
que je préférais y aller par petits bouts :
- fichiers et répertoires renommés ou déplacés
- appels diffénrents (par spip.php au lieu de par article.php3)
- nouvelle gestion des caches etc...
ça fait plein d'obstacles en même temps et en général c'est pas conseillé
de sauter trop de versions à la fois.
Mais vu le temps que j'y ai déjà passé, ok je tente le coup
en me sentant un peu îvre de témérité !
Mais vu le temps que j'y ai déjà passé, ok je tente le coup
en me sentant un peu îvre de témérité !
Là j'ai upgradé vers la 1.9.2a.
pour la première fois je me suis servi du spip_loader
et c'est ma foi bien pratique.
Tout s'est bien passé concernant la bdd
mais j'ai perdu toute la mise ne page des squelettes !
L'avantage c'est qu'avec la 1.8.3, la partie publique
était vide de chez vide, alors qu'avec la 1.9.2,
elle apparait avec les squelettes de la fraichdist...
bon faut tous adapter les squelettes maintenant,
et corriger toutes les incompatibilité de versions
dans les appels etc ...
Est-ce que tu fais tout ça directement sur ton site en ligne ou passes-tu par une version en local ?
Je travaille sur le passage d'un 1.7 à 1.92 et je fais tout sur ma machine avec Easyphp avant de basculer.
je profite d'un changement d'hébergeur pour mettre à jour la version.
j'ai donc la nouvelle version en ligne aussi, mais pas à l'adresse publique.
JLuc