Changer de thème Drupal à la volée
Le changement de thème à la volée est un must pour tous site un peu évolué. Dans sa version basique cela consiste à séparer le thème d'administration (backoffice) de celui du site lui-même (frontoffice). De manière plus évoluée cela permet de gérer proprement différents jeux de régions (entre la page d'accueil et les pages intérieurs par exemple), ou encore de proposer un thème spécifique pour les navigateurs mobiles.
À partir de sa version 6 (5?) Drupal propose une séparation de sélectionner un thème pour le backoffice avec la possibilité d'englober les formulaires d'édition de contenu. Pour aller plus loin dans la logique de sélection d'un thème en fonction de l'url, du user-agent ou de la position de la lune, il faut passer par du code custom.
A la mode Drupal 6
En Drupal 6 ou 7, tout commence par la création dans votre projet d'un module custom que nous appellerons ici mon_module.
Ensuite, dans le fichier mon_module.module il nous faut implémenter un hook_init. Ce hook est appelé à chaque démarrage de drupal, juste après l'activation du module, et avant toute autre opération. C'est donc l'endroit idéal pour opérer notre changement de thème.
/** Implémentation du hook_init. */
function mon_module_init() {
}Le module de base
Maintenant pour le changement du thème en lui-même, attention, c'est super compliqué :
/** Implémentation du hook_init. */
function mon_module_init() {
// Si l'URL est node/*/track
if (drupal_match_path($_GET['q'], 'node/*/track') {
// On bascule sur le thème défini dans admin/settings/admin
$GLOBALS['custom_theme'] = variable_get('admin_theme', 'garland');
} elseif
// Sinon, si le nom de domaine est m.XXXX (site mobile)
if (preg_match('#^m(.*).(.*)$#i', $_SERVER['HTTP_HOST'])) {
// On bascule sur le thême mobile
$GLOBALS['custom_theme'] = 'mon_theme_mobile';
}
}Le module de base
En fait non, cela n'a rien de compliqué du tout, et c'est ici un bon exemple de l'intérêt à coder ses propres modules plutôt que d'utiliser systématique des brouettes de modules contribs dont il faudra gérer les bugs.
Comme vous l'aurez compris, la variable globale custom_theme (après on se moquera de WordPress et de son usage des Globals ;-) est utilisé par Drupal pour basculer sur un autre thème que le thème principal, sous réserve que celui-ci soit activé ou paramétré comme thème de maintenance.
Au passage notez la fonction drupal_match_path bien pratique pour valider une chaîne de caractères par rapport à une liste de motifs (séparés par des \\r\\n) et variable_get('admin_theme', 'garland') permettant de lire dans la configuration le thème d'administration configuré dans admin/settings/admin.
A la mode Drupal 7
Avec Drupal 7 le principe est strictement le même sur ses fondamentaux mise à part que l'usage de hook_init est à remplacer par un hook spécialisé pour cet usage :
/**
* implémentation du hook_custom_theme.
*/
function mon_module_custom_theme() {
// Si l'URL est node/*/track
if (drupal_match_path($_GET['q'], 'node/*/track') {
// On bascule sur le thème défini dans admin/settings/admin
return variable_get('admin_theme', 'garland');
} elseif
// Sinon, si le nom de domaine est m.XXXX (site mobile)
if (preg_match('#^m(.*).(.*)$#i', $_SERVER['HTTP_HOST'])) {
// On bascule sur le thême mobile
return 'mon_theme_mobile';
}
}Implémentation de hook_custom_theme
Comme vous le voyez c'est encore plus simple grâce à hook_custom_theme qui remplace notre bricolage avec hook_init. Son fonctionnement est très simple, il suffit de faire nos tests et de renvoyer le nom du thème sélectionné.
Conclusion
Voilà donc, c'est à peu prés tout. Alors c'est vrai que les modules qui permettent de faire ce "travail" peuvent avoir leur utilité dans le cadre d'une utilisation "wordpressienne" de Drupal, mais pour un projet professionnel où il est rare de ne pas avoir au moins un module custom, cela fait l'économe d'un poignée de modules en échange d'un hook et d'une dizaine de lignes de code, plutôt rentable non ?