Projet

Général

Profil

Historique

Archives »

De Drupal6 vers Drupal7 » Historique » Version 1

Version 1/7 - Suivant » - Version actuelle
Julien Enselme, 04/04/2013 18:36

--[[Utilisateur:Ismaeil|ismaeil]] 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.

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

h1. Planification

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

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

h3. Un environnement de tests

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 !

--[[Utilisateur:Ismaeil|ismaeil]] 23 mai 2011 à 14:39 (CEST)

h2. Méthode alternative

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

h3. Nettoyage

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 (mdv) : 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 http://ginfo.centrale-marseille.fr/wiki/index.php/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 Drupal7 en suivant les recommandations du UPGRADE.txt de DRUPAL7 (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 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 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 feautures) sur un autre module car on est pas sur 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é. E 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 sur 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

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

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

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


#!/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 "$project" >> sortie.html
#The file from which we read is in the next line
done < modules.txt

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 !

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 :

si pas d'arguments :

if [ $# -lt 1 ]; then
echo "usage: $0 "
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

Puis, nous avons créé un script plus efficace, nommé [ Scripts_et_tâches_planifiées#usep | usep ].

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

usep tarski

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

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

[[Catégorie: Club Drupal]][[Catégorie: Projet Multi-assos]]