Rendre un thème compatible avec cette horreur d'IE6 a un coût certain et je n'avais pas, mais alors pas du tout envie de me lancer dans l'aventure pour le nouveau look d'artisan. La solution qui m'est paru plus saine, vu que ce brouteur est de toute façon en fin de vie (dieu merci), c'est d'utiliser spécifiquement pour lui, le vieux thème du site et ainsi laisser par défaut le nouveau pour ceux qui respectent un tant soit peu les standards. Et tout cela en restant dans un module, sans modifier le code de Drupal de préférence.

Stratégie de cache

Comme vous devez le savoir, Drupal dispose de trois niveaux de cache allant de désactiver à agressif. Le cache des pages permet d'améliorer énormément les performances sur un site à fort trafic en court-circuitant de manière plus ou moins profonde tout traitement en PHP. Ce cache n'est utilisé que pour les connexions anonymes.

Le problème est que le cache étant par essence une version pré calculée d'une page, il va rentrer clairement en conflit avec notre module de changement de thème. Cependant, pour rester progressif, je vous propose d'abord une version qui implique de désactiver le cache. Nous verrons ensuite, dans un prochain article, comment modifier ce module pour qu'il puisse aussi fonctionner en mode "haute performance".

Le module de base

Pour construire notre module, nous allons comme d'habitude créer un dossier du genre sites/all/modules/mes_modules/ie6_theme_hack et y ajouter le fichier de description :

Ceci fait, créons un deuxième fichier, le module à proprement parler, avec pour l'instant juste ce qu'il faut pour l'activer :

Comme d'habitude, un petit tour dans ?q=/admin/build/modules, on coche le nouveau module et on enregistre.

Changement dynamique de thèmes

Changer un thème sous Drupal est très simple. Le panneau de configuration ?q=/admin/build/themes permet de sélectionner autant de thème "actifs" que l'on désire et en choisir un "par défaut". Il vous suffit donc de cocher votre thème "spécial IE6" pour le rendre disponible mais non actif par défaut.

Ensuite, le "truc" réside en une variable globale non documentée dans Drupal, $custom_theme. Lorsque elle est renseignée, son contenu vient écraser le non de thème par défaut. Une chose que nous pourrions faire dans le hool_menu de notre menu. Mais ce n'est pas "si" simple

En effet, la seule chose un peut délicate est que cette variable doit être renseignée très tôt dans le cycle de vie d'une page Drupal, bien avant que n'importe quel hook ne soit appelé sur notre module.

N'importe quel hook, sauf heureusement hook_init et hook_exit. Si un module possède ces deux fonctions, il sera considéré par Drupal comme prioritaire (aussi appelé module "bootstrap") et ces méthodes seront appelées avant même que le cache ne soit initialisé. Nous allons donc utiliser ces deux hooks dans notre nodule :

Comme vous le voyez, hook_exit n'est pas utilisé mais il doit être présent pour que le module soit déclaré comme prioritaire. Le corps du hook_init est lui assez simple. Une petite interrogation de la variable $_SERVER['HTTP_USER_AGENT'] nous permet de déterminer s'il s'agit d'un IE5 ou IE6, et si c'est le cas, on positionne la variable $custom_theme avec le nom du thème alternatif, celui qui vous avez coché en plus du thème par défaut.

Il ne reste alors plus qu'à sauver. Pour tester, prenez soin de déconnecter le cache dans la section performances de l'administration. Ensuite, en fonction du navigateur soit c'est le thème par défaut qui sera utilisé, sinon c'est celui spécifique au navigateur cible.

Conclusion

Les deux hooks "init" et "exit" définissant un module "bootstrap" sont très précieux pour effectuer des opérations très bas niveau sans pour autant torpiller systématiquement le code de Drupal, en restant dans le cadre d'un module distribuable. Ceci dit, même si l'on cherche généralement à l'éviter, il n'est pas toujours possible d'éviter la modification du coeur de Drupal, c'est ce que nous allons voir au prochain épisode pour pouvoir réactiver le cache.

Commentaires