Historique

--iabouljamal 19 mars 2011 à 07:08 (CET)

La communauté Drupal ne fournit pas le support des versions Drupal éternellement. Le jour de la sortie de Drupal8, la version 6 sera totalement abandonnée et le projet multi-asso ne bénéficiera plus des avantages pour lesquels Drupal a été choisi.

Il nous est donc important de bien planifier la mise à jour vers Drupal 7 et de l'effectuer avant Février 2012 si possible. EDIT du 5 avril 2013 : avant la fin de support de drupal 6.

Cet article a donc pour but de lister les problèmes qu'on rencontrera et les solutions qu'on a trouvé. En particulier les fonctionnalités des modules D6 qui ne passeront pas à D7 doivent être listées et les alternatives proposées.

Des bouts de code, scripts et astuces pour les tâches à effectuer en masse sont particulièrement les bienvenues.

Planification¶

Ce planning peut être accéléré si les modules de drupal7 sont déja satisfaisants. Mais Le retarder serait comme prendre le risque de devoir passer à drupal8 deux mois après le passage à drupal 7 (enfin si le planning annoncé par la communauté est respecté !)

Réunion de validation de cette procédure (Team Assos -CRI) : MARS-AVRIL
Blinder cette procédure : MARS-AVRIL
Début de l'étape Préparation : AVRIL-MAI
Fin de l'étape Préparation : FIN MAI
Étape Tests des MAJ : MAI-Octobre

Passage définitif à Drupal 7: Novembre-Décembre

Préparation¶

Veille sur le sujet¶

De le lecture des blogs/forums et retour des autres drupaliens, on dresse une TODO de ce qu'on doit checker, ce qui pourrait poser problème :

La procédure de UPGRADE.TXT contient des conseils sur les fichiers à virer et quelques remarques sur le .htaccess. Il faut donc savoir le rapport avec ce qu'on a fait ici. Et meux que le upgrade.txt: la documentation sur le Upgrade process: http://drupal.org/node/570162

Les modules qui sont désormais dans le core (Ex: CCK) ne s'auto-upgradent pas pendant la MAJ 6-7. CCK sera seul responsable de sa propre MAJ (cf smbjorklund .no/node/53) La documentation sur les modules qui ont rejoint le core : http://drupal.org/node/895314

Un retour d'expérience d'un site .edu avec pas mal de modules : drupal.ucar.edu/docs/node/154

des changements dans le thème Garland D7 font afficher des erreurs dont on se débarasse en rebuildant le registre du thème http://drupal.org/node/1147158

http://rocktreesky.com/upgrading-drupal-7

Un environnement de tests (sur assos)¶

Cette action peut être entamée dès MAINTENANT

Contrairement aux mises à jour D6.X D6.Y, je ne pense pas que le passage à D7 sera sans perte ; j'ai des doutes quant à l'existance d'une version D7 de certains modules utilisés par les associations ECM. Par conséquent, je ne pense par que la team doit prendre le risque de faire les MAJ directement sur les sites en ligne et je propose les étapes suivantes :

Extraire une version de la base de données et la copier dans une nouvelle base de donnés créée spécialement pour l'occasion (la restriction sur les sites les plus importants est suffisante : le forum et les sites des associations).
Copier intégralement le repertoire html de 'assos' dans un nouveau repertoire dans html ou dans le html d'un compte test.
Faire en sorte que la nouveau repertoire et la nouvelle base (copie) se parlent bien (que les sites fonctionnent)

On a donc un environnement où on effectuera les tests de passage de Drupal6 à 7 sans aucune crainte !

Un environnement de tests en local¶

Suivre tout d’abord les consignes données ici pour reproduire le site en local. Pour plus d’informations sur drush, voir ici.

Vérifier les points suivant :

vérifier htaccess
mkdir d6up (drupal 7)
drush dl drupal dans ce site
cp settings d6 -> settings d7
copier la base de données d6 car elle va être écrasée
voir du côté de conf.d et de etc/host
attention aux base_url
alias drush pour mettre à jour :
drush `d6 en update
- drush `d6 sup @d6up

Méthode alternative¶

http://build2be.com/content/how-get-site-localhost

Nettoyage (Terminé)¶

Il faut d'abord que D6 soit clean pour limiter les problèmes de migration:

DONE Il faut disparaitre les derniers liens symboliques fr.truc
DONE Il faut supprimer les modules/thèmes qui n'ont pas d'équivalent D7 dans du serveur après être sûr que personne ne les utilise plus! cf Article_help_1_migration_6_7 (--[[Utilisateur:Ismaeil|ismaeil]] 21 avril 2011 à 00:48 (CEST) ça a pris du temps mais plus de la moitié des projets qui n'ont pas de version D7 (thèmes et modules) ont été supprimés car non utilisés ou seulemnt utilisé par des sites tests !)
DONE Il faut voir le cas des rares sites qui ont un thème propre ou un module propre dans leur répertoire
---- [État : Terminé]

Un cas intéressant est apparu lors du traitement du point 2 : un thème non utilisé, non D7isé et donc supprimable, et dès qu'on le supprime, des problèmes apparaissent car des thèmes ne sont que des surcharges du projet à supprimer.

Conclusion : une tâche à ajouter serait de renommer tous les thèmes qui ne sont qu'une surcharge. Le nom doit commencer par les nom du thème père puis le nom mignon qu'on trouve.
done [[Utilisateur:LiNux =!|LiNux =!]]

Par contre, attention, il reste des cas susceptibles de poser problème : certains thèmes viennent directement avec des sous-thèmes intégrés (cas aboutpeople et about), et on a un cas de surcharge de ce sous-thème : je n'ai pas renommé le sous-thème intégré

Réunions d'information¶

Réduire au maximum la liste des projets incompatibles en en parlant aux webmasters Article_help_1_migration_6_7
Dire aux wabmasters qu'on a l'intention de passer à Drupal 7 pour différents raisons

mail
Réu en amphi (faut savoir que celà à un impact direct sur leur site : le thème va changer de look !)
Invitation aux D&D (pour régler les problème du genre "ce module disparait mais la fonctionnalité dois rester car fondamentale pour le site")

Mise à jour¶

Le café¶

Il est strictement interdit (article L.3.2.1 du réglement intérieur) d'attaquer les mises à jour sans avoir pris du café ou thé.

Il est strictement interdit (article L.3.2.2 du réglement intérieur) d'attaquer les mises à jour si on n'a dormi que 5 heures la veille.

Test des MAJ¶

Sauvegarder l'environnement des tests précédemment créé !
Effectuer une mise à jour vers Drupal 7 en suivant les recommandations du UPGRADE.txt de DRUPAL 7 (18 étapes) ou mieux : http://drupal.org/node/570162
Noter tous les problèmes rencontrés et les solutions trouvés et si pas de solution : trouver un contournement, l'essayer, le valider.
Hacker les sites de l'environnement de test : Écraser le mot de passe d'admin, se connecter et voir si la vie est belle de l'autre coté ou si c'est rouge !
Une fois les problèmes réglés, Répéter cette étape avec une nouvel environnement de test et s'assurer qu'on maitrise vraiment le passage 6=>7

Enfin Drupal7 !¶

Alerter la liste drupal, voire webmasters de l'heure planifiée des mises à jour.
Mettre les sites sous le mode maintenance 15 minutes avant le massacre !
S'assurer que l'étape des Tests des Maj est bien effectuée et avoir la liste des problèmes rencontrés et leurs solutions sous les yeux !
Sauvegarde des fichiers du repertoire html de 'assos' et des bases de donnés Forum et webassos.
Croiser les doigts (mais le décroiser pour bien effectuer les étapes suivantes)
Effectuer la mise à jour
S'assurer que les sites de l'étape "Test des MAJ" survivent tous sans problème.
supprimer CHANGELOG.TXT de l'installation

Tests massifs¶

Après avoir silloner les sites des associations et être sur qu'il y a pas de mort.

Un mail de communication sera envoyé à la liste drupal, voire webmasters... encourageant les webmasters à découvrir la nouvelle plateforme et de reporte à assos@centrale les problèmes rencontrés.

Réécriture des documentations¶

Du fait du grand changement (au niveau de l'interface, mais aussi des terminologies de certains concepts) introduit par le passage à D7, une grande partie de nos tutoriels (wiki + site default) devront être mis à jour

Conclusions pour Drupal 8¶

Et oui, ce qui fait que le passage D6->D7 n'est pas aussi immédiat et risque d'être douloureux c'est principalement le nombre de projets qu'on a. Et si les thèmes peuvent être changés et adaptés voir re-développés, les modules quant à eux apportent des fonctionnalités dont on ne peut pas se passer parfois.

Il faut alors tout de suite redéfinir les régles de l'ajout d'un module en s'appuyant sur les problèmes rencontrés lors du D6->D7.

Je (iabouljamal) met des idées au hazard :

Quand une fonctionnalitée peut être faite à l'aide des modules du core, toujours privilégier cette méthode (ou features) sur un autre module car on est pas sûr qu'il sera dispo pour D8 ! Il y a une tonne d'exemples à cela : tous les modules notify-like peuvent être remplacé par actions et triggers, les evenements par calendar, fields et views…
être plus exigeant lors du choix d'un module : voir qui l'a développé, quel est l'état des autres projet qu'il développé. Est ce que la société pour qui il a développé ce module encourage les MAJ (par exemple si le module est sponsorisé par acquia on est sûr qu'il sera à jour avant même la nouvelle version !)
features : ne pas en abuser, mais quand ça permet d’éviter un nouveau module on l'utilise . Attention cela veux dire qu'on doit réfléchir à la manière de les mettre à jour, un bout sql pour updater les tables !!! => c'est lourd et contraignant ! espérons que features sera plus clean dans le futur !

Trucs divers¶

Les modules tiers utilisés¶

En parcourant tous les sites, afficher les modules activés autres que ceux du noyau et écrire le résultat dans un fichier

<code class="bash">
drushall pml |grep Enabled | grep -v Core >> modules.txt
</code>

Liste des modules et thèmes utilisés par le multi-asso qui n'ont pas encore une version D7 : Article_help_1_migration_6_7

Vérifier l'existance d'une version 7¶

--[[Utilisateur:Ismaeil|ismaeil]] 12 avril 2011 à 03:12 (CEST)

On a plus d'une centaines de modules et thèmes et je ne trouve pas un moyen magique pour vérifier l'existance d'une version 7 que d'aller directement sur la page du projet : l'astuce est donc comment faciliter cette tâche lourde !

Voici la démarche que j'ai entreprise pour les modules (c'est la même pour les thèmes)

# Avoir la liste des modules tiers dans un fichier text

ls sites/all/modules > modules.txt

# Transformer ce fichier en un fichier html qu'on peut ouvrir avec un navigateur web et cliquer simplement sur des liens vers les pages des projets.
On commence par créer le script makehtml.sh

<code class="bash">
#!/bin/bash
while read ligne
do
set $(echo $ligne)
project=$(eval echo $1)
#The file on which we write is in the next line
echo "<a href=\"http://drupal.org/project/$project\" target=\"_blank\">$project</a><br/>" >> sortie.html
#The file from which we read is in the next line
done < modules.txt
</code>

Puis on lance le script dans le même répertoire que modules.txt

sh makehtml.sh

On aura un fichier sortie.html qu'on ouvre avec un navigateur web et on peut alors cliquer sur les liens !

Script utilisation projet¶

Il nous faut un script qui prend pour entrée le nom d'un projet (module thème) et qui liste les sites qui ont activé ce projet.

Au début, nous utilision un script proche de drushall qui ressemblait à ça :

<code class="bash">
# si pas d'arguments :
if [ $# -lt 1 ]; then
  echo "usage: $0 <drush args>"
  exit 1
fi

cd [drupal_directory]/sites

for x in $(ls -1 | grep -v 'all' | grep -v other directories); do
  if [ -d $x -a ! -L $x ]; then
    cd $x;
        echo $x
        drush pml | grep $*
    cd -;
  fi
done
</code>

Puis, nous avons créé un script plus efficace, nommé [Scripts_et_taches_planifiees#usep|usep ].

Utilisation pour avoir l'état d'utilisation du theème tarski par rapport à tous les sites de l'installation :

usep tarski

Script changement thème¶

Il nous faut un script qui active un autre thème : drush en le_theme puis qui définit ce dernier thème activé comme thème par defaut : drush vset theme_default nom-de-mon-thème . Enfin qui désactive le thème d'un site : drush dis le_theme et, plus un autre qui définit le thème d'administration au thème par defaut par exemple drush vset admin_theme nom-de-mon-thème

Ce script sera utilisé pour changer les thèmes des sites dont on peinera à trouver le webmaster pour passer à un thème D7 friendly !

Après le D7¶

Retester la méthode création de sous site¶

La mettre à jour et update de la doc sur le wiki

retester le script de Maj des modules¶

Le mettre à jour et update de la doc sur le wiki

Fichiers (1)

Projet

Général

Profil

Club Drupal

Wiki

Planification¶

Préparation¶

Veille sur le sujet¶

Un environnement de tests (sur assos)¶

Un environnement de tests en local¶

Méthode alternative¶

Nettoyage (Terminé)¶

Réunions d'information¶

Mise à jour¶

Le café¶

Test des MAJ¶

Enfin Drupal7 !¶

Tests massifs¶

Réécriture des documentations¶

Conclusions pour Drupal 8¶

Trucs divers¶

Les modules tiers utilisés¶

Vérifier l'existance d'une version 7¶

Script utilisation projet¶

Script changement thème¶

Après le D7¶

Retester la méthode création de sous site¶

retester le script de Maj des modules¶