Club Drupal

--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.

{{toc}}

h1. Planification

{{warning(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**

h1. Préparation

h2. 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 [[Utilisation_de_Drupal_multi-site#Choisir-et-implémenter-la-bonne-méthode-de-téléchargement-drupal-6|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

h3. 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 !

h3. Un environnement de tests en local

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

Vérifier les points suivant :

* vérifier htaccess

* <code>mkdir d6up (drupal 7)</code>

* <code>drush dl drupal dans ce site</code>

* <code>cp settings d6 -> settings d7</code>

* 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 :

 * <code>drush @d6 en update</code>

 * <code>drush @d6 sup @d6up</code>

h3. Méthode alternative

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

h3. 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<br />

# ---- [É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é

h1. 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")

h1. Mise à jour

h2. 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.

h2. 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

h2. 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

h1. 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.

h1. 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

h1. 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 !

h1. Trucs divers

h2. 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

<pre>

<code class="bash">

drushall pml |grep Enabled | grep -v Core >> modules.txt

</code>

</pre>

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]]

h2. 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

<pre>

ls sites/all/modules > modules.txt

</pre>

# 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

<pre>

<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>

</pre>

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

<pre>

sh makehtml.sh

</pre>

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

h2. 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 : 

<pre>

<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>

</pre>

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

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

<pre>

usep tarski

</pre>

h2. Script changement thème

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

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

h1. Après le D7

h2. Retester la méthode création de sous site

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

h2. retester le script de Maj des modules

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