Mise à jour Yacs Macnana RC3

L'objectif : mettre à jour www.gresivaudan.org. Dans cette première étape, il s'agit de faire un test de mise à jour, tranquillement, sur une copie locale du site.

Le contexte du site en production : Yacs version 8.4beta30.4, PHP 5.2.6, MySQL 4.1.22-log (hébergement mutualisé chez Nuxit). L'arborescence de Yacs est placée dans un dossier "yacs" (sur lequel pointe le domaine), les tables de la base de données n'ont pas de préfixe.

Le contexte du site de test (serveur local sur une debian etch) : PHP 5.2.0-8+etch11, MySQL 5.0.32-Debian_7etch6-log, Apache/2.2.3 (Debian).

La démarche

• Création en local d'un répertoire test et d'une base de donnée test.
• Récupération par ftp de l'arborescence Yacs distante (site en production) dans le répertoire test local. Un coup de chown pour changer le propriétaire des fichiers pour que ça fonctionne (sur debian, c'est www-data le propriétaire du répertoire /var/www).
• Export de la base de données distante et import dans la base de données test locale.
• test du site local : tout est grosso-modo ok, à part les vignettes et autres icônes de pages qui nécessiteraient de recréer les chemins, les titres des boîtes extra et de navigation (cf plus bas), des codes yacs obsolètes.
• Récupération de l'archive Yacs version 8.6beta30.31.31 (tgz), placée dans le répertoire local test/inbox/yacs
• Mise à jour à partir du répertoire inbox/yacs

Lors de la mise à jour, des erreurs sont relevées. Je ne suis pas en production, alors je n'hésite pas à poursuivre la mise à jour malgré les erreurs. En voici le compte-rendu (je n'ai gardé que les passages "à erreur").

Mise à jour des scripts :

Erreur : impossible de mettre à jour le fichier control/htaccess/basic/index.php
control/htaccess/index.php (141 lignes) a été mis à jour
Erreur : impossible de mettre à jour le fichier control/htaccess/indexes/index.php
Erreur : impossible de mettre à jour le fichier control/htaccess/options/index.php
...
(plus bas)
...
Erreur : impossible de mettre à jour le fichier help/index.php
...
542 fichiers mis à jour.

Recherche des extensions : sans problèmes.

Mise à jour de la base de données :

DESCRIBE values
1064 : you have an error in you SQL syntax, check the manual that corresponds to your MySQL server version for the right syntax to use near 'values' at line 1.

Scripts à exécution unique :

Run-once
080629_ajax_update.php
Mise à jour de AJAX
Impossible d'obtenir include/browser/swfoject.js
1 fichier on été traités

Je refais une passe de mise à jour, à partir de l'archive placée dans inbox/yacs :

• les fichiers qui étaient en erreur sur la mise à jour des scripts sont traités, sans erreur - mais il reste un problème lié au menu "aide" qui refuse de pointer sur la page help.php, bien que celle-ci soit accessible en la saisissant dans la barre d'adresse. La solution est simple : modifier le menu en remplaçant help.php par help/, et ça fonctionne.
• j'ai toujours la même erreur sur la mise à jour de la base de données.
• je ne me souviens plus s'il y a eu un run_once :(

Concernant l'erreur SQL Christophe Battarel me signale avoir eu le même type de message sur un autre serveur Yacs, mais sur la table 'tables', et l'a contournée via un renommage.

Il se trouve que mes tables n'ont pas de préfixe, et que cela fait hurler yacs depuis plusieurs mises à jour - sans perturber le fonctionnement - à chaque visite du panneau de controle système (il me suffit de ne pas enregistrer ou, si je dois modifier quelque chose, de bien remettre le champ préfixe de table à "").

Je décide de tenter la mise à jour de mon fichier sql pour ajouter un préfixe yacs_ à toutes les tables (et donc toutes les instructions, ça me prend un bout de temps, mais je m'étais juré de le faire un jour ). Ré-import de la base ainsi modifiée. J'ai deux erreurs dues à des oublis : je modifie et ré-importe la base : cette fois tout est OK, plus de message d'alerte SQL sur la table 'values' ni aucune autre.

En fait si, il me reste un message, et il y a le même ici en ce moment, sur la page des codes dynamiques des codes de contrôle :

SELECT * FROM yacs_files AS files WHERE (files.id = section:default)
1064: 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 ':default)' at line 1

Si ça se trouve, il en traîne encore d'autres, j'ai pas tout épluché encore.

Par contre, j'ai des horreurs sur les titres des boîtes de navigation, boîtes extra, qui m'affichent ceci :

EXTRA_BOX_TITLE_PREFIXMontitredeboîteEXTRA_BOX_TITLE_SUFFIX

Cela est du à un changement dans le code de skins/skin_skeleton.php pour la construction des boîtes : On est passé de

// always add a header
$text .= '<dt>'.EXTRA_BOX_TITLE_PREFIX.Skin::strip($title).EXTRA_BOX_TITLE_SUFFIX."</dt>\n";

à

// always add a header
$text .= '<dt><span>'.Skin::strip($title)."</span></dt>\n";

Cette fonction a été modifiée sur gresivaudan.org, et pour faire cela, elle a été copiée puis complétée dans le fichier /skins/monstyle/skin.php. J'ai donc modifié le skin.php de mon style en conséquence, sur les construction des boîtes de navigation et des boîtes extra, et tout est rentré dans l'ordre.

En conclusion de cette première étape

• Je suis surprise des erreurs SQL, et surtout, j'aimerai bien comprendre l'origine de l'erreur sur la table 'values', ou encore celle relevée sur la page des codes dynamiques. Et ce d'autant plus que Tof l'a eu, mais sur une autre table.
• les erreurs sur les mises à jour des scripts m'ont peu inquiétée sur un site de test facile à vider et repeupler, et elles se sont bien résolues avec une deuxième mise à jour.
• Sur le site en production, je ne garde que les skins skeleton et monstyle (pour pouvoir le cas échéant basculer sur un style natif en cas de besoin). C'est ce que j'ai rapatrié en local. Lors de la mise à jour, tous les autres styles ont été ré-importés. Finalement, bien que ce soit assez accessoire puisqu'il suffit de les supprimer, je me demande si j'apprécierai pas de pouvoir choisir les styles que je veux installer/mettre à jour lors des procédures du même nom
• Comme je le disais plus haut, je ne me rappelle pas s'il y a eu à nouveau le script à éxécution unique relatif à l'erreur sur le fichier swfobject.js (probablement non). Toujours est-il que ce fichier est bien présent dans mon arborescence - daté du 23 mais 2008.

Ben voilà, c'est pas si mal. Il me reste :

• à vérifier les templates et feuilles de style pour éventuellement finir les mises à jour - et en profiter pour passer avec les jolis boutons que je n'ai toujours pas mis,
• vérifier l'auto-complétion des étiquettes qui ne fonctionne plus depuis la dernière mise à jour du site en production - ça serait bien que ça remarche complètement, c'est vraiment trop pratique !
• et faire le grand tour du propriétaire, en testant autant de choses que possible (j'ai vu de nouveaux codes yacs qui s'intéressent drôlement et plein d'autres choses qu'il faut que j'essaye !).