mise à jour très vieille version

Chris972

Avril 2021

Bonjour,

Ma question est simple. J’ai mis en place un site sous SPIP il y a très très longtemps, et sa dernière mise à jour date de (attention, ça va piquer) 2007. Non, pas 2017, mais bien 2007. Version 1.9.2.

Ce site est toujours vivant, et documenté par ses utilisateurs depuis. Moi-même je n’en reviens pas que l’hébergeur ait pu tenir sa version apache/php/mysql pour que ça continuer à tourner, mais ça tourne et ce n’est pas la question ;)

Maintenant, je voudrais le migrer ailleurs, et évidemment en profiter pour mettre SPIP à jour, évidemment, sans perte, parce que je n’ai jamais réutilisé SPIP depuis, et que ça m’arrangerait bien de ne pas devoir me replonger trop dedans juste pour le migrer.

La question est donc : est-ce envisageable/raisonnable/possible ou pas ?
Et si oui, comment ? Par la procédure de MAJ normale en croisant les doigts, ou inenvisageable de la sorte et il faut passer par une autre procédure ?
Je parle bien de faisabilité, sachant que la migration se fera sur un serveur dédié, et que j’aurai donc la main sur tout, et c’est donc à l’expérience des connaisseurs que je fais appel.

Merci d’avance !

Par note Par date Par date chronologique

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

0

Jack31

Avril 2021

Bonjour,
Oui bien sûr c’est possible et il y a plusieurs façons de faire .
La BDD se mettra à jour de 1.9.2 sans problèmes. Par contre côté squelettes il faudra sans doute mettre les mains dans le cambouis...

Je ferais d’abord l’action en local avant de migrer en ligne pour voir comment ça se comporte. Et je migrerais en conservant une copie de l’ancienne bdd.

On peut mettre à jour en utilisant spip_loader.php. Une possibilité est d’installer un nouveau SPIP sur la dernière stable (3.2.11) puis de brancher la BDD et SPIP effectuera les maj de la BDD...
Indiquez l’intérêt que vous portez à cette réponse

0

Chris972

Avril 2021

@Jack31 : Merci pour ta réponse.

Je vais essayer de m’en sortir, et je reviendrai si jamais je coince quelque part.
Indiquez l’intérêt que vous portez à cette réponse

0

Chris972

Avril 2021

Bon et bien, ça ne marche pas si mal que ça, même si j’ai un peu pataté sur la migration d’un MySQL 4, et le spip_loader qui n’a jamais voulu se lancer. J’ai fini par repartir d’une version vierge, en remettant mon /squelettes et il semble que je n’ai rien perdu.

Par contre, j’ai un petit truc qui m’embête. Avant, j’utilisais les liens en "URL propre", ce qui correspondait à "Titre article.html"

Or, maintenant, c’est "Titre article -Rubrique-.html"
(ou "Titre article -Rubrique-") mais plus le format que j’utilisais.

C’est embêtant pour le référencement.
Y a un moyen de jouer là dessus ?

Merci d’avance.
Indiquez l’intérêt que vous portez à cette réponse

0

Jack31

Avril 2021

Bonjour,
Je suis étonné de ce que tu dis il me semblait que seule la longueur par défaut des urls avaient changé.
Il faudrait que tu actives la gestion avancée des urls : il est possible de jouer sur la longueur, et surtout tu peux modifier l’url de chaque article.
En migration il devrait être possible de conserver les anciennes urls (stockées dans la table spip_urls) et en avoir de nouvelles avec les nouvelles longueurs.
Indiquez l’intérêt que vous portez à cette réponse

0

Chris972

Avril 2021

Bonjour,

Bon, en fait, laissons tomber cette affaire d’URL, car ça vient manifestement de l’utilisateur qui n’a lui même pas respecté le cahier des charges qu’il m’avait donné, et qui s’est amusé à créer des sous-rubriques qui étaient proscrites car ça casse la navigation (squelettes etc...).

Par contre, j’ai un autre problème, et plus sérieux.
Certains articles (mais pas tous) ne sont pas éditables.
Enfin, on peut passer en mode édition, mais on ne peut pas cliquer sur le bouton enregistrer. Il n’est pas cliquable. Comme si un élément dans la fiche l’empêchait.
Les articles en question, pour ce que j’en ai vu, font référence à des documents. Ces documents sont bien en place, puisqu’ils sont correctement affichés dans l’article sur le site.
Peut-être est-ce quelque chose de connu comme problème lors d’une migration ?
En fait, pour récupérer les personnalisations et contenus du site, j’ai non seulement migré la BDD, mais aussi récupéré tout le IMG/ et squelettes/. Ça semblait tout contenir, mais aurais-je oublié quelque chose ?
Indiquez l’intérêt que vous portez à cette réponse

0

Jack31

Avril 2021

Pas de problème connu lors d’une migration, mais peut-être y-a-t-il un formulaire "formidable" avec des champs obligatoires et le html5 est-il activé sur ces articles ?

C’est un bug qui a été réglé sur la 3.3 dev (4.0 beta à sortir prochainement)
Indiquez l’intérêt que vous portez à cette réponse

0

Chris972

Avril 2021

Alors, j’ai passé quelques heures à comprendre qu’en fait, tout bêtement, c’est ENCORE la faute de l’utilisateur du site (virus du pebkac) qui s’est amusé à mettre du code HTML dans les articles en questions, et bien évidemment, du code invalide.

Du coup, ça bloque totalement l’édition de l’article, ce qui pour moi est quand même un bug, puisque l’utilisateur ne peut donc jamais corriger son erreur. Il faut aller taper directement dans la BDD, ce qui n’est pas forcément recommandé pour celui qui fait déjà de telles conneries ;)

Concernant la rédaction, je constate un problème avec le filtre image |largeur=XXX mais je ferai sans doute un post séparé puisque ça n’a aucun rapport avec la migration.
Indiquez l’intérêt que vous portez à cette réponse

0

Chris972

Avril 2021

Je viens de voir ta réponse que je n’avais pas vue avant de poster ma conclusion.
Et non, le html5 n’était pas (encore) activé sur le site au moment où j’avais ce problème.
De toutes les façons, tout roule maintenant, comme je l’ai dit précédemment.
Merci pour toute ton aide.