La base de données

Tout d'abord, si j'ai un conseil à donner, c'est de bien sauvegarder votre base comme il se doit avant de commencer à migrer. En effet, vu le nombre de changements, sur les 7 sites que j'ai converti, 3 sont partis en sucette live... Un problème très sûrement lié à l'histoire des sites en question et certaines incohérence qui sont apparues en base au fil du temps. Toujours est il que j'étais bien content de pouvoir revenir en arrière lorsque j'ai par exemple découvert que la taxonomy de tous les nodes avait volée...

Dans la série trucs étranges lors de la conversion, j'en ai eu deux assez surprenant. Tout d'abord l'impossibilité de créer plus de deux nouveaux nodes. La raison était que l'entrée correspondant dans node_revision avait un vid=0. Au deuxième coup donc, la contrainte de non duplication des ID s'est levée, et les nodes sont rejetés. La raison en était que sur 3 sites sur 5 le champs VID n'était pas en mode "auto incrémentation". Pour régler cela (sous postgresql) :

La deuxième chose est que mes nodes étaient invisibles pour les anonymes. Et là aussi pas pour tous les sites, ce qui localise le problème à la conversion de la base. La cause en est cette fois que la table node_access était vide. Pour régler cela et ajouter la régle de base pour rendre les nodes visibles à tous :

Ensuite, de temps en temps, je me suis retrouvé dans l'impossibilité d'accéder à quoi que ce soit. L'astuce que j'ai trouvée est de relancer l'update (update.php) à vide.

Les thèmes

Ce détail mis à part, la conversion se passe globalement sans encombres. C'est après que les soucis commencent Déjà avec les thèmes et phptemplate qui voit ses identifiants un peu changer (par exemple $sidebar_right devient $right). Il faut bien étudier les thèmes fournis en standard pour retrouver un affichage correcte. De manière sous-jacente, c'est tout le moteur de thème qui a été descendu au niveau du core de Drupal. Faites donc aussi attention si vous utilisez des fonctions de thème dans vos modules et allez voir le nouveau hook_theme.

Dernier point pour porter vos thèmes, il faut maintenant un fichier .info par dossier de thème, comme pour les modules. Prenez exemple sur ceux qui sont fournis en standard.

Les modules

Enfin, le gros du temps passé l'a été à convertir les modules. Pas mal de petites choses ont bougées et le résultat est qu'aucun ne passait. Déjà une nouvelle information est apparue dans le fichier .info : core=\"6.x\". Sans cela, le module ne s'active pas. Autre changement, pour les dépendances, le mot clef devient dependencies[]=.... Et contrairement à ce que laisse supposer son nom, cette propriété ne prend qu'une dépendance à chaque fois.

L'autre point problématique est la nouvelle gestion des menus. Il y a eu là une pure et simple ré-écriture du moteur. Un changement en profondeur vous obligeant à revoir complètement les hook_menu. L'idée principale est que la notion de $may_cache disparaît au profit d'un système de motifs. Plus d'information à ce sujet ici. A noter que maintenant hook_menu n'est plus systématique invoqué, il faut pour cela désactiver/activer le module correspondant.

Dans la même série, la fonction l(...) ne prends plus que 3 paramètre au lieu de 6. Le troisième étant le classique tableau d'attribut qui reçoit maintenant les 3 anciens paramètres (ex 'html'=>true).

Dernier point, il était de coutume de mettre dans la partie !$may_cache du hook_menu, des choses qui n'avaient au fond rien à faire comme des chargements de feuilles de styles ou javascript. Il faut maintenant placer ce type de code dans le hook_init.

Conclusion

Voilà pour le plus gros. Il ne me reste maintenant plus qu'à tester tout cela et à reconnecter au fur et à mesure les fonctions qui sont passées à l'as sans que je ne m'en aperçoive.