[spip-dev] Des tests préalables à la mise à jour ?

Salut,

Ces derniers jours, plusieurs cas se sont présentés de mises à jour
compliquées vers SPIP3.

Les causes que j'ai relevées:
- version php
- informations inconsistantes en table rubriques => crash sur calcul de
profondeur
- y en a-t-il d'autres qui ont été identifiées ?

A mon sens, vu les 20000 sites encore en SPIP2, et vu que ces deux
problèmes ne peuvent ou ne doivent pas être gérés de manière
automatique, préparer un peu le terrain pourrait être sympa pour nos
tendres utilisateurs.

J'ai rassemblé quelques tests via des boucles pour identifier ces
enregistrements inconsistants. Ils sont en pièce jointe...

Je n'aurai probablement pas de temps dans les prochains jours pour
continuer ça mais je vous en fait part:
- bonne idée (ça il me semble que oui) ?
- Où "brancher" ça ? Sur le spip_loader ? En plugin ? Dans la procédure
de màj, avant lancement de l'install/upgrade (mais ça, c'est déjà tard,
pour php, si les fichiers SPIP sont installés, cfr corrections aux
rubriques et affichage cassé du privé sous php4) ?
- si d'aucuns veulent plancher dessus, on fait ça sur la zone ?

Mes 2 sous

Tot ziens,

Suske

tests_avant_maj.html (1.13 KB)

Salut !

Je pense au contraire qu’il faut détecter et régler ces problèmes dans la fonction de màj.
Sinon on va introduire une “peur de l’upgrade” qui posera encore plus de problèmes.

Hello,

Je pense au contraire qu'il faut détecter *et régler* ces
problèmes dans la fonction de màj.

Pour les infos incohérentes dans spip_rubriques, cela pose le souci de quel choix faire.
- rubrique dont l'id_secteur n'existe pas
  => si privée, on peut la mettre à la racine
  => si publiée, on fait quoi ?
- rubrique qui est son propre parent
  => si privée, on peut la mettre à la racine
  => si publique, on fait quoi ?

Dans les 2 cas, prévoir affichage d'un message explicite sur la première connexion au privé.

Pour la version php:
- si spip_loader, on peut tester avant màj des fichiers
- si ftp / svn, peut-on imaginer de bloquer l'install si la version php n'est pas ok ?

Sinon on va introduire une "peur de l'upgrade" qui posera encore plus
de problèmes.

La multiplication des plugins fait qu'amha une page de test qui t'affiche "tout va bien" ou "ceci n'est pas ok" et qui en outre listerait les plugins actifs et indiquerait la disponibilité (ou les alternatives), voire qui préparerait le boulot, ça serait compliqué à faire peut-être mais bcp plus "rassurant" non ?

Bonjour,
Ayant vu passer des problèmes de fichiers obsolètes, je me demandais pour info, si spip_loader supprimait les anciens fichiers v2 non utilisés par v3 ?
Pat

Je ne pense pas et au survol du code je ne vois pas qu'il le fasse mais bon... Moi et php on est potes, pas amis :wink:

Donc à noter pour cette idée: un système de rm les_fichiers_perimes.php

...

Je remonte un problème récent qui apparaît depuis que des hébergeurs tels que Ouvaton et 1&1 ont choisi de passer à PHP5.4 :
il semble qu’il faille que les données soient encodées en UTF8 à cause du changement de fonctionnement de htmlentities()
A vérifier lors d’une mise à jour (d’autant plus que le lien « convertir la base en utf8 » a disparu en SPIP3)

2013/2/18 Suske

A noter, le souci définitif pour les sites en iso8859 lors du passage à
php5.4 http://forum.spip.net/fr_248791.html

=> Appliquer d'office lors d'une màj la fonction "utf8_convert" jadis
proposée en SPIP2 ?

En SPIP 3 il n'y a plus de champs BLOB et *normalement* le passage en utf8 se fait simplement en 2 opérations :
- déclarer utf-8 comme charset du site
- ajouter dans spip_meta la valeur (nom='charset_sql_connexion',valeur='utf8')
INSERT INTO spip_meta (nom,valeur,impt) VALUES ('charset_sql_connexion','utf8','non');

Et c'est mysql qui automagiquement fourni des données au format utf8 au lieu de isotruc.

Les vieux scripts de conversion étaient nécessaires parce que l'on stockait autrefois les données en BLOB et non en TEXTE, et mysql ne pouvait de ce fait pas fournir les données dans un charset autre que celui sous lequel elles sont stockées.

Cédric

Cela dit, ça ne dispense pas de corriger le bug car même sous PHP 5.4 un site en isotruc devrait continuer à fonctionner !

Cédric

En particulier, à l'occasion d'une préparation de màj, je note

1. les plugins suivants sont utilisés sur SPIP 2.1 mais ne sont plus nécessaires car intégrés en SPIP 3 (au moins les fonctionnalités utilisées sur mon 2.1), ou adaptées, mais SANS besoin de plugin SPIP 3

- Bandeau 2.1 => intégré
- Barre typo V2 => porte-plume intégré
- Google Sitemap => Spip a son sitemap (depuis longtemps)
- Interface d'aministration des forums => intégré
- Itérateurs => intégrés (sauf démos)
- Job queue => intégré
- mediabox => intégré
- médiathèque => intégré
- Prévisualisation en cours de rédaction => intégré
- Slogan => intégré

2. Des cas moins nets mais où a priori on a pas besoin en SPIP 3 et sinon SVP devrait s'en charger via les dépendances:

- cfg
- SPIP bonux

3. Des solutions alternatives en SPIP3 par rapport à l'équivalent en SPIP2:

- lecteur multimédia => mp3 ok et vidéo avec plugin suppl; pour les vidéos: ajouter "Vidéo accessible"
- Newsletter et tutti quanti pour les listes de diffusion e-mail (avec reprise au moins partielles de l'existant - à détailler, j'ai pas encore eu le temps: quelqu'un ?)

En conclusion, sur *ce* site, mes 44 plugins SPIP 2.1 sont soit disponibles pour SPIP3 soit intégrés à la distribution SPIP, alors qu'il y en a une dizaine que l'on chercherait en vain à installer.

Cool.

SPIP c bôôôô.