Changement de version majeure 2.0.9 -> 3.2.16

Bonjour,

Je suis actuellement en train de suivre le tuto pour changer de version majeure.

Et je bloque au passage de la mise à niveau de la base.

La config actuelle est un hébergement sous php 5.6.40, la version du spip est la 2.0.9.

J’ai suivi le tuto avec les 2 solutions, celle du transfert des fichiers par FTP et celle par le spip_loader, les 2 me mènent à la même issue quand j’arrive à ce point.

Mise à niveau de la base

En fonction du type de mise à jour, une procédure de mise à niveau de la base de données vous sera proposé en accédant à l’espace privé. Suivez les indications.

  1. Consulter votre site. Normalement, il devrait s’afficher (sous l’apparence des squelettes par défaut de SPIP)
  2. Se connecter sur l’interface privé de SPIP avec un compte administrateur (en cas de difficulté, se rendre à l’url /ecrire du site).

Je rencontre les difficultés quand je veux me connecter à la partie admin du site et l’url /ecrire du site. Mes navigateurs Edge, Opera, Firefox et Chrome me renvoient tous la même erreur 302 « TOO_MANY_REDIRECTS » et je n’arrive pas à aller plus loin.

Quelqu’un aurait une piste ?

Merci d’avance pour l’aide apportée.

Ça vient peut-être de ton .htaccess, renomme le pour le désactiver pour voir si ça règle le problème…

Bonjour,

Solution déjà envisagée.

Il s’agit d’un .htaccess personnalisé qui me permet la redirection vers une page indiquant que le site est en maintenance. Voici son contenu.

# Activation du moteur de redirection
RewriteEngine On

# Changement du fichier de démarrage
DirectoryIndex Maintenance.html

Lorsque ce fichier est actif et que je souhaite accéder à la page /ecrire, je tombe sur l’affichage type dossier avec tous les fichiers du dossier /ecrire.

Lorsque je désactive mon .htaccess personnalisé, j’ai l’erreur 302 « TOO_MANY_REDIRECTS ».

Il existe un plugin pour ça En travaux - Plugins SPIP :slight_smile:

Bonjour,

Merci pour le plugin, je viens de voir la page que vous me proposez cependant si je suis bien la logique je peux pas vraiment l’utiliser puisque j’essaie de passer de la 2.0.9 à la 3.2.16, et il y a un plugin compatible avec la 2 et un autre pour la 3.

Dans la procédure de changement de version majeure justement on déplace le dossier plugins, d’où ma démarche avec la page et le htaccess perso.

Mais en omettant ma page de maintenance personalisée, le problème de redirection reste entier.

Bonjour, si le changement de version se passe mal, je ferais tout mon possible pour installer la version la plus haute sous Spip2 (il y a une version 2.0.20 je crois, puis une version 2.1.xxx ) et ensuite je passerai à la version 3.
Perso j’ai déjà eu des problèmes avec spip_loader pour des versions de spip2, et donc j’aurais également tendance à charger les fichiers par FTP
Ensuite, je commencerais par faire cette évolution « en local » (j’ai l’impression que tu fais la mise à jour sur le site en prod)
Au risque de paraître trop prudent, au moins tu fais cela par étape, et s’il y a un problème, il est plus facile de voir d’où il vient.
Tu as bien désactivé tous les plugins avant le changement de version ?
Éric LM

Bonjour,

si le changement de version se passe mal

Malheureusement, pour le moment c’est le cas.

je ferais tout mon possible pour installer la version la plus haute sous Spip2 (il y a une version 2.0.20 je crois, puis une version 2.1.xxx ) et ensuite je passerai à la version 3.

Je vais essayer cette solution, c’est vrai que c’est pas mentionné dans le tuto donc j’y ai pas vraiment prêté attention.

Perso j’ai déjà eu des problèmes avec spip_loader pour des versions de spip2, et donc j’aurais également tendance à charger les fichiers par FTP

J’ai essayé les deux solutions du tuto de changement de version, c’est-à-dire le spip_loader et le chargement de la version 3 par FTP. Mais je tombe sur le même problème au même moment. La partie publique est dispo, se connecte bien à la BDD puisque je vois les articles mais impossible de me connecter à l’administration quelque soit la méthode employé pour la mise à jour.

Ensuite, je commencerais par faire cette évolution « en local » (j’ai l’impression que tu fais la mise à jour sur le site en prod)

J’ai tenté les deux, d’abord en local mais j’ai un souci de version PHP trop élevé (8.1), c’est un problème que j’essaie de résoudre pour revenir à une version supportant la 2 et la 3 pour effectuer la mise à niveau, je pense que le 5.5 ou la 5.6 sont compatibles avec la 2 et la 3. Puis j’ai tenté en prod d’où la page de maintenance et l’hébergeur étant sous PHP 5.6 c’était bon pour la mise à niveau.

Au risque de paraître trop prudent, au moins tu fais cela par étape, et s’il y a un problème, il est plus facile de voir d’où il vient.

On est jamais trop prudent, j’ai 3 sauvegardes du site en version d’origine de prod 2.0.9 sur des supports différents pour revenir rapidement à ce qui fonctionnait.
Je note les étapes sur papier et je teste à chaque fois si ça me remonte des erreurs ou non avant de passer à la suite pour justement identifier les éventuels problèmes. Mais là hormis une indication du navigateur :face_with_raised_eyebrow: même pas une erreur de spip.

Tu as bien désactivé tous les plugins avant le changement de version ?

Il n’y en avait pas d’installé sur le site sur lequel je travaille. Oui j’ai récupéré le site d’une petite association et ma tâche est de le mettre à jour.

Dans ce cas, essaie d’avoir un site de test sur l’hébergement de prod avec un sous domaine (attention aux bases !)

Personnellement, je pratique comme te le conseille Eric Le Meur.
Un changement de version majeure prend généralement en compte la dernière itération de la version précédente. Même Krosoft ou apple te le spécifie et quand ce n’est pas le cas, c’est qu’ils ont fait une combo et qu’ils lancent bêtement les versions intermédiaires les unes derrière les autres à ta place.

Là, je tique fortement : la version 2.1.0 est indiquée comme apportant la compatibilité avec PHP 5.3, donc la 2.0.9 a des chances de fonctionner sur des versions en dessous. et là, vous la faites tourner sous du PHP5.6 ?
Même si le « tout venant » fonctionne, tu comprend bien que tu risques d’avoir des soucis en montée de version
Qu’en pensent les dev ?

Bonjour,

La version en 8.1 c’est mon serveur local, là j’ai pu installer une version de php en 5.6.40 comme le serveur de prod pour effectuer les manipulations de mise à jour mais le tout en local pour essayer d’identifier la source du problème.

D’après la page des compatibilités, je suis dans les clous. La 2.0 est compatible php 5.6 et d’après cette même page, je peux monter jusqu’à la 3.2. Après j’ai récupéré le site dans cet état de config.

Non pas vraiment puisqu’en terme de config annoncée tout à l’air bon. C’est pour ça que je cherche d’où peut venir le problème.

Là pour le moment, j’ai mis mon serveur en php 5.6.40 donc je vais me lancer sur la piste d’Eric Le Meur :

Et je reviendrais poster ce qu’il en est.

Bonjour,
Je prends la discussion en cours de route, mais il ne semble pas utile de passer par toutes les versions 2.*.*
Avec php 5.6.40 il est possible de monter jusqu’à SPIP 3.2 (en une seule fois en principe)
Ensuite une fois qu’on est en 3.2 changer de version php et s’il est possible d’avoir au minimum php 7.4 on peut upgrader direct en SPIP 4.1.5. Attention pour SPIP 4.1.5 vérifier qu’on a bien l’extension Sodium activée.

Bonjour,

Moi aussi je partage ton avis, mais visiblement il en serait autrement.

J’ai peut-être identifier le problème des redirections.

Sur mon serveur local, j’ai refait la marche à suivre du tuto. Et j’ai vu que les fichiers de log (tmp/spip.log) grossissaient rapidement au moment des redirections.

Apparement, au moment de la connexion à la partie admin (/ecrire/) après la mise à jour des fichiers, le système essaient de se connecter à des tables (*_jobs) qui n’existent pas. Et c’est cette connexion récurrente qui crée les redirections.

Donc une mise à jour intermédiaire comme le suggère Eric Le Meur résoudrait peut-être le problème de tables. Là je suis en train de fouiller les archives du site à la recherche des dites versions.

J’avais bien compris et c’est pour cela que je te conseillais de voir à installer un spip de test sur le serveur de prod

Oui et non, c’est valable pour la dernière version de la branche.
Par exemple, il est bien spécifié dans l’article correspondant que la version 2.1.0 apporte la compatibilité avec PHP5.3, ce qui signifie

  1. que les versions 2.0x ne sont pas compatibles au delà de 5.2x à la date de sortie de la 2.1
  2. que la version 2.1 n’est pas compatible avec les versions php supérieures à 5.3
    Par exemple, il faut attendre la version 2.1.24 pour avoir la compatibilité avec PHP 5.5 et non PHP5.6 (ici)

Effectivement, comme Eric l’a dit, on conseille seulement d’installer la dernière version de chaque branche (2.0.xx; 2.1.xxx… )

Bonsoir à tous, oui, c’est cela, il ne s’agit pas d’installer toutes les versions les unes après les autres, mais simplement les dernières.

Et effectivement, en théorie on peut passer de la 2.0.6 à 3.2.16. Mais comme il y a un problème, je me dis qu’il y a peut-être des étapes intermédiaires sur lesquelles les différentes mises à jour s’appuie, et si on saute ces étapes intermédiaires en passant directement de la 2.0.6 à 3.2.16, ça peut planter.

Ou encore, avec ces mises à jour progressives, on va peut-être déceler des erreurs de config (serveur, base, etc) qui seront plus faciles à déceler que lors d’un grand saut.

Bon courage ! (y’a pas de raison que cela ne marche pas, et le plus compliqué c’est de trouver pourquoi)

Bonsoir,

Au temps pour moi, j’avais pas vu cette nuance là. Cependant, comme la version 2.0.9 fonctionne sans erreur sous PHP 5.6 du serveur de prod, je suis effectivement pas allé plus loin.
Et comme je récupère le site d’une association, je ne suis pas au fait de ce que la précédente personne avant moi a fait il y a 10 ans. Donc il y a peut-être eu des modifications pour s’adapter plutôt que les mises à jour. D’où la difficulté de mon travail à l’heure actuelle.

Oui, c’est que je vais faire car comme je l’ai dit dans mon message précédent, le problème serait du à des tables (*_jobs, notamment) qui n’existent pas et qui ne sont pas créées entre temps. Elles ont du apparaitre soit à la 2.1, soit à la 2.2 et ça me permettra de passer à la 3 une fois que je l’ai.

Bonjour,

Je reviens vous donner quelques nouvelles.

J’ai pu faire les tests en local sur des installations vierges de Spip.

Le passage de la 2.0.9 à la 3.2.16 plante, même souci qui m’a amené ici.

Le passage de la 2.0.9 à la 2.1.0 fonctionne, ce qui me permet donc d’essayer le passage à la dernière 2, la 2.1.30, ça fonctionne aussi nickel, la base de données se met à jour comme il faut.

Puis je tente le passage de la 2.1.30 à la 3.2.16 et … ça fonctionne aussi.

Donc comme disait Eric Le Meur, le spip_loader a pas l’air d’aimer spip2, je me rajoute donc à la liste de ceux qui ont ces problèmes.

Comme dit plus haut, ces tests ont été fait sur des installations neuves donc maintenant je vais m’atteler à le faire sur une copie du site en local et après tout mettre en prod une fois que les mises à jour seront effectuées et stable.

Je reviendrais vous donner les retours.

1 « J'aime »

Bonjour,

Vous savez quoi ? Et beh c’est bien la merde.

En local tout fonctionne et en prod tout plante…

Je retombe sur le problème récurrent des erreurs 302 « TOO_MANY_REDIRECT ». Du coup, j’ai eu l’idée de passer outre la partie accueil de l’administration.

Le raisonnement est le suivant, à chaque mise à jour, on passe par la partie admin pour avoir le message qui nous dit que les fichiers sont à jour et qu’on peut passer à la mise à jour de la base de données. Effectuant cette opération en passant par pleins de versions intermédiaires, je sais que les fichiers sont à jour. DONC… si je rentrais directement le lien pour la mise à jour de la base de données et ce après m’être connecté.

Et oui, quand on se connecte, on n’est pas encore dans la partie /ecrire/ mais toujours sur le site. Donc en rentrant l’agrégat suivant, je passe outre la page d’accueil de l’administration qui génère à ce moment les fameuses erreurs 302.

/ecrire/?exec=upgrade&reinstall=non

Ainsi je passe directement à l’étape qui me dit que je peux lancer la mise à niveau de ma base.

A ce stade, et de cette façon, j’ai pu passer de la version 2.1.30 à la 3.0.0 et enfin à la 3.2.16. Les erreurs 302 ne se produisant qu’à partir de la 3.0.0 et la 3.2.16, je n’ai pas eu à utiliser ce stratagème pour les versions 2.x.xx.

Maintenant je vais m’occuper des squelettes pour les passer sur la 3.2.16.

Je reviendrais vers vous pour d’autres retours sur mon périple.

Bonjour,

Les squelettes sont majoritairement compatibles de la 2.0.9 à la 3.2.16, je dois faire le tour du site pour régler un ou deux problèmes dans les squelettes.

Mais voilà qui clôture le sujet.