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.

Il peut arriver, pour milles et une raisons, d'avoir à étendre le formulaire de configuration d'un type de contenu de sorte à ajouter des réglages qui lui sont spécifiques. Les cas d'usages sont nombreux et dépendent des projets, mais on peut par exemple imaginer un champ "responsable" qui permet de sélectionner un utilisateur Drupal en charge des contenus d'un type donné. Je n'ai pas dit que l'exemple serait intelligent ;-)

CCK, comme tout drupalien le sait, permet d'étendre un type de contenu en ajoutant toute sorte de champs (dates, textes, images, liens, etc.). Ces champs portent un "nom machine" (field_XXX) utilisé comme nom de table ou de colonne dans la base de données, et bien évidement dans le code (généralement du thème).

Tout cela est très bien sauf qu'au bout d'un temps, entre les fautes de frappe, les modifications de spécifications, les nouvelles fonctionnalités, le nommage de ces champs peut manquer cruellement de cohérence. Et étrange, vous avez dit étrange, il n'existe dans CCK aucun moyen de les renommer.

Je ne vais pas revenir sur mon amour immodéré pour views, ce n'est plus trop la peine. Views est ce qu'il est et il arrive parfois que le choix de l'utiliser ne se pose pas, il est là, enraciné dans un projet, indéboulonnable sous peine d'exploser les charges. Et à chaque modification un peu conséquente c'est la même histoire, un temps de dingue à trifouiller en tout sens cette interface maudite pour obtenir à grand coup de prévisualisation une requête que j'ai en tête depuis le début. Passé un moment, on se lasse d'une telle gymnastique et je me suis donc mis à chercher, sans grande conviction, un moyen d'injecter mes propres requêtes dans Views. Et la bonne nouvelle est que oui, c'est faisable !