Préparer le passage en SPIP 3.1 ou 3.2

[brunob]

Je viens de tester un passage en 3.2 sur une version locale et ça fonctionne bien après les quelques commits que j'ai envoyé ici https://github.com/seenthis/seenthis_squelettes/tree/spip31

Ce qu'il reste à faire :

• [x] https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/plugins_seenthis/date_relative_dynamique utilise encore $.cookie() qui a été remplacé par Cookies.get() / Cookie.set() dans SPIP 3.2. La compat est assurée mais ça génère des warnings dans la console. À terme, il faudra au choix : créer une branche spécifique à SPIP 3.2 pour ce plugin, ou le modifier dans le trunk et indiquer qu'il n'est plus compatible < 3.2 ; ref https://core.spip.net/projects/spip/repository/revisions/23328 & https://core.spip.net/projects/mediabox/repository/revisions/101685/diff/javascript/splash.mediabox.js => réglé https://zone.spip.net/trac/spip-zone/changeset/115851/spip-zone
• [x] modifier la borne de compat de https://github.com/seenthis/seenthis_importer_flux/blob/spip31/paquet.xml après l'avoir testé en 3.2
• [x] tester ces 3 plugins que je n'utilise sur aucune de mes instances seenthis https://github.com/seenthis/seenthis_sphinx + https://github.com/seenthis/seenthis_opencalais + ~https://github.com/seenthis/seenthis_arbo_anglais~

[brunob]

Log de ce que j'ai fait pour la migration en 3.2 :

-x basculer la dev en 3.2 en l'état -x switch le SPIP dev en 3.2 + svn up de tous les plugins + switch de branche pour seenthis & seenthis_squelettes -x bloquer l'envoi de mail sur la dev define('_TEST_EMAIL_DEST', ''); dans config/mes_options.php -x rsync IMG seenthis vers dev rsync -av /var/www/seenthis.net/public_html/IMG/ /var/www/stdev.zoo-logique.org/public_html/IMG -x poster un message d'annonce depuis le compte seenthis -x bloquer la prod en mv tmp/sesssions tmp/_sessions & touch tmp/sessions -x lancer une synchro vers la dev (dont la base reste en 2.1 tant qu'on ne lance pas l'upgrade) 15h30 -x lancer base_repair pour forcer l'upgrade des tables spip -x request_terminate_timeout = 300 dans conf/php dev (retiré) -x lancer l'upgrade SPIP + admin_plugin -x l'upgrade de la base ayant foiré, lancer un mysqlcheck --repair --databases stdev puis suppression du connect et lancement de la phase d'install pour que l'upgrade de base se fasse enfin -x mise à jour de conf/nginx/rewrites.conf -x copier les conf de seenthis.net vers la dev sauf php -x mettre à jour le mes_options de la dev -x sync export de seenthis vers dev rsync -av /var/www/seenthis.net/public_html/export/ /var/www/stdev.zoo-logique.org/public_html/export

sur stdev après migration

• modif du load de 2 à 3 dans ecran_securite
• modif de mes_options pour fix pb redirect 302 // régler le bug de redirige_par_entete avec nginx cf https://core.spip.net/issues/2529#note-5 define('_SERVER_APACHE', true);
• suppression de la table spip_resultats qui n'avait pas migré proprement lors de l'upragde (champs non présents) et recréation à partir de la structure de la table issue d'un SPIP 3.2

diff conf/

• spip : done
• logrotate : diff user => todo à mettre à jour
• mysql : idem, rien à faire
• nginx : plein
• php : copier la prod vers la dev et modifier la valeur de php vers 7 => done

  pm.max_children = 60
  pm.start_servers = 10
  pm.min_spare_servers = 10
  pm.max_spare_servers = 30
  pm.max_requests = 1000

[brunob]

Hop,

net :: seenthis.net :: Disk usage in percent
    OKs: /srv is 89.47.

Le disque du serveur est bien plein depuis la migration vers SPIP 3.2, l'espace occupé par l'ancienne version pourrait être libéré, au moins en supprimant le dossier IMG qui a été synchronisé d'un site à l'autre. Votre avis ?

[rastapopougros]

Bé oui, pas besoin de l'avoir en double à priori. Et pareil pour la base, si ça a été installé dans une autre.

[brunob]

Et donc la question : a-t-on besoin d'une instance de dev sur le serveur ? :)

[rastapopougros]

Ajout de ce qu'on a fait pour Sphinx : 1) Le schéma de l'index avait changé, et le plugin SPIP attendait un champ "date_indexation" qui n'existait pas. On a donc changé la déclaration dans /var/local/shpinx puis on a supprimé l'index et on a tout ré-indexé à zéro avec le script PHP du plugin seenthis_sphinx (car le stockage attendu est fait uniquement avec des fonctions persos, donc on utilise pas les choses du plugin : il va falloir remettre ça au propre) 2) Dans les squelettes, la balise #PROPERTIES de la boucle SPHINX passe désormais par un filtre automatique pour json_decode le contenu. Et dans les anciens squelettes, il y avait ce filtre ajouté après, et sans étoile sur la balise. Du coup c'était appliqué deux fois, et ça ne sortait rien d'utilisable. Soit il faut #PROPERTIES tout court, soit il faut #PROPERTIES*|json_decode…

[rastapopougros]

@brunob le principe de pré-prod est utile surtout quand on fait un gros changement, juste avant de passer en vraie prod, pour pouvoir tester avec pile exactement les mêmes conditions. Pour le dev/test de base, ça peut être sur un autre serveur, avec des données de test, etc.

Il sera toujours temps de re-dupliquer plus tard, un jour où on aura vraiment besoin de tester une pré-prod sur le même serveur.

[brunob]

Parfait, je ferai le ménage dans la semaine.

[brunob]

Comme je le disais sur la liste :

C'est un problème de rewrites rule non transposée en nginx. La rewrite apache originale qui gère les urls arbos de SPIP (et donc celles de seenthis) est ici :

https://core.spip.net/projects/spip/repository/entry/spip/htaccess.txt#L86

Je remarque aussi que la rewrite rule qui prend en charge le robots.txt de SPIP n'est pas fonctionnelle cf https://seenthis.net/robots.txt

Alors que le robots.txt semble avoir été accessible sur la version 2.1 cf https://web.archive.org/web/20190701000000*/https://seenthis.net/robots.txt

Il semble aussi que les rewrites pour les sites déconnent :

https://seenthis.net/sites/1116845 KO https://seenthis.net/spip.php?page=site&id_syndic=1116845 OK

=> corrigé par https://github.com/seenthis/seenthis/commit/6c7da0015a61e5f3a1c32f67ef8e8c33cec2ce59 pour les urls des sites

[brunob]

Je viens de supprimer IMG dans l'ancien seenthis, ça permet déjà de gagner de l'espace => /dev/sdb1 394G 189G 187G 51% /srv

[brunob]

Trouvé pour l'accès au robots.txt, il suffisait de décommenter la ligne location = /robots.txt { access_log off; log_not_found off; } dans conf/nginx/drop.conf. Il faudra penser à mettre à jour toutes ces infos dans le wiki https://github.com/seenthis/hebergement/wiki/Configuration-nginx => done https://github.com/seenthis/hebergement/wiki/Configuration-nginx/745cbb0512adeaf3eea9c9afc415a3dd2ef6696a

[brunob]

Maintenant que la migration est faite, je pense qu'on peut fermer le ticket passer à l'étape suivante "ménage et réorganisation" cf #23 :)