Maintenir un environnement de développement est toujours délicat lorsqu’il doit convenir à plusieurs projets et leurs pré-requis. Cela se vérifie d’autant plus qu’il nous faut désormais jongler avec des projets hybrides (PHP, Ruby, Node.js, etc). Le cas de figure se rencontre lorsque des projets PHP font appels au préprocesseur Sass et Compass, son framework CSS3, tous deux en Ruby.

Les amateurs de Ruby dirons que des outils existent pour simplifier la tâche. Et ils ont raison ! Cependant, tout le monde n’est pas rubiste dans l’âme et c’est pourquoi je vous présentais il y a quelques mois une méthode pour maintenir plusieurs versions de Compass. Je reviens sur cette question épineuse parce que je suis arrivé à la limite de la solution.
En effet, je dois aujourd’hui gérer de nombreuses versions de Compass disséminées dans bien des projets. Et autant le dire clairement, consulter un README pour me rafraîchir la mémoire quant à la version de Compass (et autres outils en Ruby) requise par un projet me fatigue. Il en va de même pour mes collègues.

Heureusement pour nous, l’évolution des outils que sont RVM et Bundler offre désormais une gestion simplifiée de projets Sass et Compass, voire automatisée !

Mettre à jour RVM

Avant toute chose, vérifiez votre version de RVM :

$ rvm --version

Puis suivant la version retournée :

• supérieure ou égale à 1.10.3, vous pouvez passer directement à la section suivante. Je vous conseille néanmoins de donner un coup de fraîcheur à votre RVM
• inférieure à 1.10.3, il va vous falloir mettre à jour RVM.

Afin de profiter des dernières améliorations de RVM, il vous faut le mettre à jour, ce qui résume à relancer une installation du script :

$ cd
$ \curl -L https://get.rvm.io | bash -s stable

L’antislash en début de la commande curl n’est pas une erreur, veillez à le saisir.

La mise à jour réalisée, re-chargez RVM (ou ouvrez une nouvelle fenêtre de terminal) :

$ rvm reload

Pour information, vous pourrez désormais mettre à jour RVM à l’aide de la commande rvm get stable :

$ rvm get stable
$ rvm reload

Important :
Je ne fais pas appel à la commande sudo, vous non plus ! RVM s’installera ainsi dans votre espace utilisateur et vous affranchira de l’appel à sudo pour un oui ou pour un non (pour simplifier).

Gestion par projet des versions de Sass et Compass

La gestion simplifiée de la version de notre pré-processeur CSS préféré est le résultat de 2 évolutions de RVM :

1. RVM installe la gemme Bundler en cas de besoin.
2. À chaque ouverture de dossier, RVM vérifie la présence d’un fichier Gemfile et le cas échéant le parse pour identifier la version de ruby et le gemset à charger.

Gestion des dépendances avec Bundler

Bundler nous permet de maintenir les dépendances Ruby (les gemmes) d’un projet à l’aide d’un simple fichier j’ai nommé Gemfile :

source :rubygems
gem "compass"
gem "oily_png"

La syntaxe de cet exemple est concise, mais retenez que Bundler offre bien plus d’options. Ici, on indique simplement que le projet nécessite les dernières versions connues de Compass et la gemme OilyPNG.

Si vous devez employer une version spécifique d’une gemme, il est possible de la préciser :

source :rubygems
gem "compass", "0.12.1"
gem "oily_png"

voire même d’indiquer à Bundler que le projet accepte toute nouvelle version mineure à l’aide du sélecteur pessimiste ~> (connu sous le doux nom de spermy operator) :

source :rubygems
gem "compass", "~> 0.12.1"
gem "oily_png"

Plus clairement, toute version supérieure ou égale à 0.12.X et strictement inférieure à 0.13 sera acceptée. Une définition équivalente est donc ">= 0.12.1", "< 0.13".

Le fichier Gemfile est a déposer à la racine du répertoire depuis lequel vous lancez Sass ou Compass. Ainsi, RVM le chargera dès que vous vous positionnerez dans le répertoire.

Dédier un gemset par projet avec RVM

Maintenir de multiples gemsets (idéalement un par projet même si en pratique on en crée un par version de Compass) est chronophage et peu être source d’erreurs. Surtout lorsqu’il y a plusieurs intervenants sur le projet ; les configurations des machines et des gemmes installées n’étant pas obligatoirement identiques.

C’est pourquoi RVM a évolué pour supporter des commentaires spécifiques dans le fichier Gemfile afin de déterminer la version de Ruby ainsi que le nom du gemset à charger pour le répertoire courant :

source :rubygems

#ruby=1.9.2
#ruby-gemset=customer1-project1

gem "compass", "~> 0.12.1"
gem "oily_png"

En pratique, lorsque vous vous positionnez dans un dossier (en shell, of course), RVM lit le fichier Gemfile et

• charge la version de Ruby requise ;
• charge ou à défaut crée le gemset précisée.

Vous avez bien lu, RVM va permettre la création d’un gemset dédiée à votre projet si celui-ci venait à manquer
Un exemple, en supposant que mon fichier Gemfile est déposé dans projects/my_project/ :

$ cd projects/
$ rvm gemset name
/Users/mehdi/.rvm/gems/ruby-1.9.2-p320
$ cd my_project/
$ rvm gemset name
customer1-project1
$ cd ..
$ rvm gemset name
/Users/mehdi/.rvm/gems/ruby-1.9.2-p320

Note :
La version de Ruby est obligatoire et peut être précise : #ruby=ruby-1.9.2-p320.

Si la version de Ruby requise est absente de votre environnement, RVM vous invite a l’installer et bien évidemment aucun gemset n’est créé :

$ cd my_project2/
ruby-1.9.2-p290 is not installed.
To install do: 'rvm install ruby-1.9.2-p290'

Enfin, tout sous-répertoire d’un projet hérite du gemset demandé à RVM.

Initialisation du projet

Le fichier Gemfile étant créé, déplacez-vous à sa racine puis lancez l’installation des gemmes du projet à l’aide de la commande bundle install :

$ cd projects/my_project/
$ ls
  foo/   bar/  Gemfile
$ bundle install
  …
$ ls
  foo/   bar/  Gemfile  Gemfile.lock

Les gemmes sont désormais installées et un nouveau fichier Gemfile.lock est créé. Ce dernier est une sorte d’instantané des versions des gemmes employées, qui accélère les futures gestion de dépendances. Il permet surtout de s’assurer qu’une tierce personne installera via Bundler des versions identiques des gemmes.
Ce fichier est donc lui aussi à versionner.

Automatisation

Chaque projet possédera désormais son gemset dédié sans trop se fatiguer. C’est très bien, mais peut mieux faire. En effet, il nous faut lancer l’installation des gemmes manuellement et maintenir leurs mises à jour lorsque les besoins du projet évoluent (à l’aide d’un bundle install).

Cette tâche est automatisable en ajoutant dans votre fichier ~/.rvmrc la ligne :

rvm_autoinstall_bundler_flag=1

Dès lors, RVM va systématiquement lancer la commande bundle install lorsqu’il rencontre un fichier Gemfile \o/
Attention cependant, autant un pur intégrateur y verra un intérêt, autant un développeur qui checkout régulièrement des projets Ruby par simple curiosité n’activera pas cette option : il ne souhaitera pas pourrir son environnement Ruby par défaut de toutes les gemmes requises par les dits projets.

Supprimer le gemset d’un ancien projet

Voici la marche à suivre pour supprimer un gemset dédié a un projet qui s’est (bien — naturellement ) terminé et pour lequel vous n’aurez plus à intervenir.

En premier lieu, et ce depuis n’importe quel emplacement, affichez la liste des gemsets :

$ rvm list gemsets

rvm gemsets

=> ruby-1.9.2-p180 [ x86_64 ]
   ruby-1.9.2-p180@global [ x86_64 ]
   ruby-1.9.2-p320 [ x86_64 ]
   ruby-1.9.2-p320@customer1-project1 [ x86_64 ]
   ruby-1.9.2-p320@customer1-project2 [ x86_64 ]
   ruby-1.9.2-p320@customer2-project1 [ x86_64 ]
   ruby-1.9.2-p320@customer3-project1 [ x86_64 ]
   ruby-1.9.2-p320@customer4-project1 [ x86_64 ]
   ruby-1.9.2-p320@global [ x86_64 ]

Vous souhaitez supprimer le gemset dédiée au projet customer3-project1 :

$ rvm gemset delete customer3-project1
/Users/mehdi/.rvm/gems/ruby-1.9.2-p180@customer3-project3 did not previously exist. Ignoring.

sans succès… Effectivement, une lecture attentive du listing précédent nous informe que la version de Ruby active est ruby-1.9.2-p180 alors que la version associée à votre gemset est ruby-1.9.2-p320. Lancez maintenant la commande en précisant le couple version_de_ruby@gemset (bref, un copié/collé) :

$ rvm gemset delete ruby-1.9.2-p320@customer3-project1
Are you SURE you wish to remove the entire gemset directory 'customer3-project1' (/Users/mehdi/.rvm/gems/ruby-1.9.2-p320@customer3-project1)?
(anything other than 'yes' will cancel) > yes
Removing gemset customer3-project1

Tout simplement

Continuez votre lecture sur des sujets similaires

• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass au quotidien
• Compass : supprimer le cache buster des sprites
• Instances multiples de Compass avec Ruby Version Manager (rvm)
• Support de présentation de l’atelier « Compass, sauvez l’intégrateur ! »

Je réalise actuellement un thème Drupal 6 en HTML5 et vient le moment de déclarer comme il se doit le charset du document. Sachant que Drupal 6 déclare une la balise meta destinée à un doctype XHTML, mon premier réflexe est d’appliquer une simple substitution depuis mon implémentation du hook theme_preprocess_page() :

1
2
3
4
5
6
7
8
9
10
11

<?php
/**
 * @file template.php
 */
function MYTHEME_preprocess_page(&$vars) {
  $vars['head'] = str_ireplace(
    '<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />',
    '<meta charset="utf-8">',
    $vars['head']
  );
}

Mais le résultat n’est pas vraiment celui escompté.

Une meta Content-Type en trop pour mon thème HTML5

Voyez vous-même :

1
2
3
4

<!DOCTYPE html>
<html lang="fr">
  <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Ok, il y a bien une couille dans le pâté comme dirait l’autre. Mon charset XHTML est toujours là.

Note :
Certains modules comme Nodewords doublent la déclaration du charset. Ainsi la précédente substitution fonctionnera, mais un charset XHTML demeurera.

Une mesure de sécurité peu flexible

Il s’avère que pour prémunir toute attaque par charset, il a été décidé d’injecter en dur et de manière peu élégante la déclaration de charset depuis le core, dès la fin de la première balise ouvrante <head> rencontrée.
Tout cela se passe après le traitement du dernier hook disponible, avec l’appel à la méthode drupal_final_markup().

À première vu je l’ai dans l’os. Et ce ne sont pas les thèmes estampillés « Drupal 6 + HTML5 » qui me seront d’une grande aide puisqu’aucun ne génère un markup HTML5 valide. Vous pourrez vérifier, tous arborent la belle déclaration de charset XHTML, en plus de la déclaration HTML5 bien évidemment.

La solution

Voici l’astuce, que dis-je, le palliatif quick & dirty que j’ai utilisé pour obtenir un en-tête HTML5 valide : puisque la fonction drupal_final_markup() insère la déclaration de charset à la suite de la première balise <head> rencontrée, et bien je lui en donne une fausse a modifier :

1
2
3
4
5

<!DOCTYPE html>
<!--<head>-->
<html lang="fr">
  <head>
    <meta charset="utf-8">

Pour obtenir ma déclaration de charset HTML5 et rendre inactive la meta Content-Type de Drupal 6.

1
2
3
4
5
6

<!DOCTYPE html>
<!--<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />-->
<html lang="fr">
  <head>
    <meta charset="utf-8">

La substitution vu en début d’article est désormais inutile, je déclare mon charset directement dans mes templates.

Attention :
N’insérez jamais de commentaire avant la déclaration du doctype sous peine de faire basculer IE en quirks mode.

Continuez votre lecture sur des sujets similaires

• Drupal 6 : utiliser une iframe comme contenu de page
• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass au quotidien
• Les angoisses du theming sous Drupal 7
• Compass : supprimer le cache buster des sprites

Compass attire — à juste titre — un nombre croissant d’intégrateurs WordPress et une problématique s’impose à chaque création de thème : comment organiser mes fichiers Sass tout en respectant les contraintes du moteur de blog ?

En effet, un thème WordPress requiert à sa racine un fichier style.css muni d’un bloc de commentaire en en-tête pour stocker ses métadonnées. Rien de bien compliqué jusque là. Imaginons maintenant que vous souhaitez aussi générer d’autres feuilles de styles dans sous-répertoire css/.

Il existe des solutions mais elles sont complexes, lorsqu’une connaissance du fonctionnement de Compass suffit.

Crédits : Manhattan depuis Brooklyn Bridge par Marie Olive

Initialiser un thème WordPress à la sauce Compass

Dans un premier temps, générons l’arborescence du thème (avec la console, c’est tellement plus rapide :p) :

$ cd votre-racine-wordpress/wp-content/themes
$ mkdir -p your-theme/{img,sass/{css,partials}}
$ cd your-theme
$ touch index.php config.rb sass/{style,partials/_{base,grid,typography},css/sub-section}.scss

L’arborescence obtenue :

your-theme/
├── img/
├── sass/
│   ├── css/
│   │   └── sub-section.scss
│   ├── partials/
│   │   ├── _base.scss
│   │   ├── _grid.scss
│   │   └── _typography.scss
│   └── style.scss
├── config.rb
└── index.php

Oui, tous les fichiers Sass sont regroupés au sein du répertoire éponyme et aucun fichier style.scss n’est présent à la racine du thème.

Conserver un commentaire après compilation Sass

Renseignez les métadonnées de votre thème dans le fichier sass/style.scss, en veillant à commencer le bloc de commentaire par la chaîne /*! :

/*!
Theme Name: Your Theme
Author: your team
etc…
*/

Le marqueur /*! indique à Sass (et non Compass) de conserver le bloc de commentaire dans la feuille de styles générée, impeccable

Note :
Le commentaire est également conservé lorsque l’environnement Compass est défini à production. Aussi, le marqueur /*! est remplacé par une ouverture de commentaire normale /*.

Configurer le projet Compass

Le travail le plus important reste à faire : indiquer à Compass où trouver les fichiers sources Sass et la destination des fichiers compilés. Habituellement, en tant qu’utilisateur de Sass ou Compass, on désigne un répertoire de destination pour réceptionner toutes les feuilles de styles présentent à la racine du dossier des sources Sass. Par exemple, tous les fichiers non préfixés par un _ situés à la racine de sass/ seront générés dans le dossier css/.
Dans le cas présent, nous souhaiterions obtenir un fichier style.css à la racine du thème et un fichier sub-section.css dans le répertoire css/, donc à deux emplacements. Soit l’arborescence :

your-theme/
├── css/
│   └── sub-section.css
├── img/
├── sass/
│   ├── partials/
│   │   ├── _base.scss
│   │   ├── _grid.scss
│   │   └── _typography.scss
│   └── style.scss
├── config.rb
├── index.php
└── style.css

Deux subtilités du fonctionnement de Compass vont aider à résoudre aisément ce petit problème :

1. tout fichier non préfixé par un tiret bas _ sera généré, quelque-soit son niveau de profondeur. Son arborescence sera elle aussi créée.
2. un chemin dans les options de configuration du projet peut être vide (ou égal à .) pour indiquer le chemin courant.

Ainsi, éditez le fichier config.rb comme ci-dessous pour préciser une cible vide pour l’option css_dir :

sass_dir   = 'sass'
css_dir    = ''
images_dir = 'img'
relative_assets = true

Note :
Je vous invite à consulter le billet Compass au quotidien pour découvrir des options de configuration complémentaires.

Compiler les styles Sass du thème WordPress

Le thème est désormais correctement initialisé, vous pouvez le compiler en vous positionnant au préalable dans le répertoire de votre thème :

$ cd your-theme
$ compass compile
directory css/ 
   create css/sub-section.css 
   create style.css

Comme prévu, Compass a bien créé les fichiers css/sub-section.css et style.css \o/

Quid du chemin des images ?

N’ayez aucune inquiétude, Compass s’assurera du bon chemin d’accès des images, à condition que vous ayez bien configuré le chemin des images via l’option images_dir.

Continuez votre lecture sur des sujets similaires

• Gestion avancée de Sass et Compass avec RVM et Bundler
• Compass au quotidien
• Compass : supprimer le cache buster des sprites
• Instances multiples de Compass avec Ruby Version Manager (rvm)
• WordPress : autoriser l’upload de fichiers au format non-supporté

J’ai eu la chance de donner la semaine dernière un atelier sur Compass à l’occasion de la 4ème édition du Web Event Lyon.

Retrouvez le support l’atelier : Compass, sauvez l’intégrateur !.

Bien que de courte durée, l’atelier a pu se prolonger avec barcamp improvisé de 2h. Les nombreuses questions posées me font dire que Compass et Sass sont enfin pris au sérieux en France \o/ Tous deux attirent de plus en plus l’attention de mes confrères développeurs web et c’est une bonne nouvelle.

C’est pourquoi ce support n’est pas figé dans le marbre. Je le complèterai régulièrement lorsqu’un problème ou une question deviendra récurrente.

Continuez votre lecture sur des sujets similaires

• Gestion avancée de Sass et Compass avec RVM et Bundler
• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass au quotidien
• Compass : supprimer le cache buster des sprites
• Instances multiples de Compass avec Ruby Version Manager (rvm)

Sass et Compass éveillent de plus en plus la curiosité des intégrateurs Web et développeurs front-end français. Malheureusement je ne peux que constater une certaine réticence de leur part à sauter le pas.
La faute en incombe généralement à une frayeur démesurée de la ligne de commande et, il est vrai, à un manque de ressources francophones qui expliquent comment intégrer l’outil dans son processus métier.

Je vous propose ici la méthode de travail générique que j’utilise depuis maintenant 2 ans dans mon environnement professionnel. Je précise bien générique parce que certains projetss peuvent imposer une organisation différente.

Crédits : Post-it Marilyn par Peter Hellberg sous licence CC BY-SA 2.0

Initialiser un nouveau projet Compass

Mon projet est généralement contenu dans un projet plus conséquent, comme par exemple un thème Drupal pour lequel j’ai déjà créé son répertoire. Il me suffit ainsi d’initialiser un nouveau projet Compass, chose aisée grâce à sa commande init :

$ compass init --prepare --sass-dir sass --css-dir css --images-dir img --relative-assets
directory css/ 
directory sass/ 
   create config.rb

Puisque je ne souhaite pas que Compass me génère de feuilles de styles par défaut, j’utilise ici l’option --prepare qui limitera son action à créer :

• le fichier de configuration du projet config.rb ;
• le répertoires accueillant les sources SCSS nommé ici sass ;
• le dossier de destination des feuilles de styles générées css.

Cela fait, j’édite le fichier de configuration pour paramétrer les 2 environnements de déployement (development et production, sachant que development est celui par défaut) et pour empêcher Compass d’ajouter un éventuel cache buster :

if environment == :production
  output_style = :compressed
else
  output_style = :expanded
  sass_options = { :debug_info => true }
end

# Désactiver l'ajout du cache buster sur les images appelées via la fonction image-url().
asset_cache_buster :none

Note :
La ligne qui contient :debug_info me permet d’utiliser le plugin pour Firefox FireSass.

Ok, mon projet Compass est presque prêt. Il ne me manque plus qu’à créer quelques répertoires et fichiers que j’utilise habituellement :

$ mkdir -p sass/partials/{reset,ui}
$ touch sass/{style,reset,partials/_{base,reset,ui}}.scss

Mon arborescence finale :

$ tree -F
.
├── config.rb
├── css/
└── sass/
    ├── partials/
    │   ├── _base.scss
    │   ├── _reset.scss
    │   ├── _ui.scss
    │   ├── reset/
    │   └── ui/
    ├── reset.scss
    └── style.scss

Méthodologie de travail avec Compass

Après toute modification qui nécessite une vérification du résultat de ma part¹, je lance une compilation des sources Sass par une simple commande :

$ compass compile

Comme aucun fichier de configuration n’est précisé, la commande compile lit le fichier de configuration config.rb (ou compass.rb).

Lorsque mon fichier de configuration n’est pas standard, je précise son emplacement avec l’argument -c : $ compass compile -c sass/theme.rb

Il est aussi possible de ne compiler qu’une seule feuille de styles, en précisant simplement son équivalent Sass :

$ compass compile sass/styles.scss

Cette opération pouvant être répétitive, Compass offre une commande watch qui possède les même options que sa sœur compile mais qui se charge de surveiller mon projet et lancer la compilation dès que cela est nécessaire :

$ compass watch

Un petit Ctrl+C stoppera la surveillance.

Partager son projet Compass

Jusqu’ici je ne travaillai qu’en local. Il me faut maintenant pousser mon travail sur le dépôt centralisé pour permettre à mes collègues d’en bénéficier.
Oui, je pourrai pousser le travail en l’état, mais non je ne le fait pas. Puisque ces mêmes ressources sont destinée à être déployées sur le serveur de production je relance une compilation en précisant l’environnement production :

$ compass compile -e production --force

L’argument --force m’assure que toutes les ressources seront bien compilées.

J’obtiens ainsi des feuilles de styles compressées, idéales pour les webperf et décourageantes pour la personne qui souhaiterait directement les éditer en se cognant du projet Compass parce que ça l’emmerde de s’y mettre²

Webperf un jour, webperf toujours !

Dernière opération avant de pousser mon travail : j’optimise les sprites modifiés depuis la dernière fois. Évoluant sous MacOSX, j’utilise l’excellent ImageOptim. Sous Linux vous pouvez vous tourner vers son équivalent Trimage et PNGGauntlet sous Windows.

Au secours, j’ai un conflit !

Après un svn up ou git pull il peut arriver un conflit . Il y a 98% de chances pour qu’il porte sur un fichier généré par Compass, à savoir une feuille de styles ou une image de sprite.
Pas de problème, j’accepte la version entrante ou supprime ma version locale. Je peux ainsi visualiser dans un navigateur la dernière version récupérée et dans tous les cas il me suffit de lancer une compilation pour que mon travail soit à nouveau pris en compte (puisque les modifications entrantes des sources Sass ont été correctement fusionnées).

En résumé

Finalement, une fois le projet initialisé, travailler avec Compass revient à exécuter un ridicule jeux de commandes :

$ compass watch
CTRL+C
$ compass compile -e production --force
$ open -a "ImageOptim" img/*.png

Rien de sorcier, n’est-ce pas ?

Bonus de Compass

Il peut arriver que je souhaite supprimer tout fichier généré par Compass : fichiers de cache, sprites et feuilles de styles. Rien de plus simple à l’aide de la commande clean :

$ compass clean

Parce que les statistiques sont toujours révélatrices de points forts ou faiblesses d’un projet :

$ compass stats

Notes :
N’oubliez pas de préciser le fichier de configuration s’il n’est pas standard.

Continuez votre lecture sur des sujets similaires

• Gestion avancée de Sass et Compass avec RVM et Bundler
• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass : supprimer le cache buster des sprites
• Instances multiples de Compass avec Ruby Version Manager (rvm)
• Git : des alias pour aller plus vite

Le système de theming de Drupal 7 est un gâchis. Jacine Luisi, co-auteure du livre The Definitive Guide to Drupal 7, résume dans son article Let’s Do Something About Drupal’s Theme System le fond de ma pensée. Au lieu de retranscrire son article ici même, je vais plutôt vous présenter de quoi il retourne.

Crédits : Kaos - Chaos paiting (ii) par Kristina Alexanderson sous licence CC BY-NC-SA 2.0

Pourquoi le theming Drupal est-il si compliqué ?

Depuis que je travaille sur Drupal 7, il ne se passe pas une semaine sans que j’ai à pester contre son système de thème. Comme le souligne Jacine, les nombreux points d’entrées et la multiplicité de niveaux d’interactions font qu’il est souvent difficile de trouver où intervenir.

Quel preprocess appeler ? Celui-ci ?
Perdu. Testons dans un autre ou dans un hook_alter.
Toujours rien. Peut-être dans un hook_process ?
Finalement, il me faut surcharger un hook_theme parce que je ne peux agir sur ce pre-render…

J’exagère un peu, quoique, pas tant que ça finalement.
Vous allez me dire qu’avec Drupal 6 nous étions habitué à cette gymnastique mentale, ce à quoi je réponds oui, mais. Mais, c’était moins anarchique. Exemple.

Un exemple tout bête

Pour un type de contenu spécifique, un client demande à pouvoir insérer librement du code JavaScript et des styles CSS depuis l’espace de contribution. Pas de problème, il me suffit de récupérer le contenu des champs et de les attacher à la page à l’aide des fonctions drupal_add_js et drupal_add_css en précisant un type inline et les scopes appropriés. Ni une ni deux, je m’exécute et fais le nécessaire dans une implémentation de hook_preprocess_node() et, sans surprise, cela fonctionne.

Note : les extraits de codes qui suivent sont simplifiés pour se focaliser sur le sujet.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<?php
/**
 * @file template.php
 */
/**
 * Implements hook_preprocess_node().
 */
function MYTHEME_preprocess_node(&$vars) {
  // Nous utilisons la propriété `value` au lieu de `safe_value` qui encode les quotes.
  if (!empty($vars['field_inline_css'][0]['value'])) {
    drupal_add_css($vars['field_inline_css'][0]['value'], array(
      'type'       => 'inline',
      'group'      => CSS_THEME,
      'every_page' => false,
      'media'      => 'all',
      'preprocess' => false, // ne pas aggréger avec les autres styles
    ));
  }
  // -- snip --
}

Malheureusement le markup HTML des champs est malgré tout généré dans le flux du contenu. Ok, il me suffit de les masquer (au sens Drupal 7 du terme). Je regarde pour appliquer un coup de hide() sur mes champs depuis mon implémentation du preprocess_node. Mince, ces derniers sont déjà marqués comme rendus, leurs contenu calculé, etc. Pas mieux depuis un hook_page_alter(), ni depuis le fichier de template dédié. Pourtant la documentation officielle ne cesse de montrer comme il est facile de gérer la visibilité des champs.

Que faire ? Dois-je perdre du temps pour rendre un à un tous les champs à afficher pour ce type de contenu, ou est-ce que je pousse un peu l’investigation ? J’opte pour la seconde option tellement cette situation me paraît ridicule.

Rapidement, je trouve que je peux masquer mes champs en implémentant le hook_node_view_alter(). Tout fonctionne.

1
2
3
4
5
6
7
8
9
10
11

<?php
/**
 * @file template.php
 */
/**
 * Implements hook_node_view_alter().
 */
function MYTHEME_node_view_alter(&$build) {
  hide($build['field_inline_css']);
  hide($build['field_inline_js']);
}

Cependant, gérer ces champs à deux endroits n’est pas des plus lisible. Je rapatrie donc le code ajouté dans l’implémentation du hook_preprocess_node() dans mon hook_node_view_alter.
Déconfiture : seule l’injection du JavaScript est prise en compte. Celle des styles CSS est tout bonnement ignorée ;!

WTF Drupal (╯°□°）╯︵ ┻━┻

Et c’est ainsi que je me suis résigné à scinder cette étape de theming en 2 emplacements distincts. Le tout agrémenté d’explications en commentaires pour ne pas m’y perdre dans quelques mois ou tout simplement pour aider mes collègues à s’y retrouver.

Comment en est-on arrivé là ?

La faute en incombe en partie à une structure de données non normalisée couplée à un système de render array alléchant mais qui ne tient pas ses promesses. Tout module gère ses données à transmettre à l’API render comme bon lui chante. De ce fait il existe presque autant de cas de figure qu’il y a de modules :-/ Au niveau des fichiers de template, nous avons le droit à une soupe de variables au type simple et de render array.

Également, les modules peuvent transformer la structure des render array et nous mettre des bâtons dans les roues pour le theming (les modules Field Group et Display Suite en sont de bons exemples).

Pour finir, bien des situations complexes pourraient être évités si le core de Drupal exploitait systématiquement les render array. Il arrive toujours un moment où, alors que nous cherchons à modifier le #prefix d’un élément, l’on tombe sur du pur HTML. Tout ça parce qu’une implémentation du hook_theme() ne retourne pas de render array, comme theme_links() par exemple…

L’avenir du theming avec Drupal 8

FIXME. C’est l’idée
Jacine propose une standardisation de composant qui aura le bénéfice de simplifier le templating en rationnalisant la construction d’une page et, surtout, chaque module pourra arrêter de nous noyer sous des kilomètres de classes CSS “au cas où…”.

Continuez votre lecture sur des sujets similaires

• Drupal 6 : résoudre le problème du double charset dans un thème HTML5
• Drupal 6 : utiliser une iframe comme contenu de page

Facebook a annoncé la suppression des profils d’applications au 1er février 2012. Vous ne pourrez plus associer une application onglet à une page fan comme vous le faisiez actuellement. En effet, la page de profil d’une application mettait à disposition un lien pour ajouter cette dernière à/aux page(s) fan de votre choix.

Facebook propose bien de créer manuellement une page associée à votre application, mais vu son utilité autant s’en passer. À la place, et pour éviter 50 clics supplémentaires, je vous propose, amis Community manager, un bookmarklet qui permet d’associer aisément vos applications à des pages fan Facebook.

Mises à jour

20 juin 2012
L’API JavaScript de Facebook ayant évoluée, le bookmarklet n’était plus fonctionnel. Il fonctionne à nouveau en forçant l’appel au domaine https://www.facebook.com.

16 mars 2013
La page de gestion des applications FaceBook a évolué fonctionnellement (rien de visible pour l’utilisateur). Correction du bookmarklet.
Merci @GoPro-Amateur pour me l’avoir signalé.

Mise en place du bookmarklet

Glissez-déposez simplement le lien ci-dessous dans les favoris de votre navigateur ; dans votre barre personnelle par exemple.

Utilisation du bookmarklet Facebook Add Page Tab

Rendez-vous sur la page de configuration de votre application¹ puis cliquez sur le bookmarklet. Ce dernier vous redirige vers une page Facebook vous demandant les pages qui accueilleront votre application. L’association faite, vous serez redirigés sur l’accueil de Facebook, et pourrez accéder à votre/vos page(s) mise(s) à jour via le moteur de recherche ou le manager de pages.

Page de configuration d’une application Facebook

Continuez votre lecture sur des sujets similaires

• Dailymotion Download Bookmarklet
• JavaScript : optimiser le calcul de l’intersection de tableaux de grandes tailles
• Une console JSLint pour aider vos validations JavaScript
• Optimiser le chargement des AdSense
• Du RGBA dans vos animations avec le plugin jQuery Color

Le générateur de sprites de Compass 0.11.3¹ crée des images dont le nom a pour format <map>-<hash>.png où <map> correspond au nom du répertoire qui contient les images du sprite et -<hash> à un hash qui :

• assure l’unicité du fichier généré ;
• fait office de cache buster.

Seulement voilà, chaque modification de sprite (par un ajout ou décalage d’image par exemple) va générer une image avec un hash différent², ce qui rend la gestion du dépôt d’un projet versionné assez prise de tête.
Heureusement, il est possible de ruser.

Pour ce faire, il suffit d’implémenter les callbacks on_sprite_saved et on_stylesheet_saved dans le fichier de configuration du projet, comme suit :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#
# config.rb
#
 
# Réaliser une copie des sprites avec un nom dépourvu du hash d'unicité.
on_sprite_saved do |filename|
  if File.exists?(filename)
    FileUtils.cp filename, filename.gsub(%r{-s[a-z0-9]{10}\.png$}, '.png')
  end
end
 
# Remplacer dans les feuilles de styles générés les références aux sprites par
# leurs équivalents dépourvus du hash d'unicité.
on_stylesheet_saved do |filename|
  if File.exists?(filename)
    css = File.read filename
    File.open(filename, 'w+') do |f|
      f << css.gsub(%r{-s[a-z0-9]{10}\.png}, '.png')
    end
  end
end

Ainsi, après chaque génération de sprite par Compass, une copie de l’image dépourvue du hash d’unicité est réalisée. Cela s’accompagne bien évidemment par un remplacement de leurs appels dans les feuilles de styles.
Il ne reste plus qu’à ignorer les images ayant un hash au niveau de votre repository pour ne pas polluer ce dernier.

Je suis conscient qu’il y aurait plus secure (je pense notamment aux substitutions dans les feuilles de style), mais disons que cela me convient dans l’immédiat, et qu’accessoirement je ne fais pas de ruby

Continuez votre lecture sur des sujets similaires

• Gestion avancée de Sass et Compass avec RVM et Bundler
• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass au quotidien
• Instances multiples de Compass avec Ruby Version Manager (rvm)
• Drupal 6 : résoudre le problème du double charset dans un thème HTML5

Vous devez intégrer sous Drupal 6 des pages en provenance d’un site externe. Le web scraping est à exclure et de ce fait le chargement en iframe des pages externes a été retenu.
Marche à suivre.

Déclarer un menu de type callback

En premier lieu, il vous faut créer la page virtuelle qui aura la charge de faire appel au service externe via une iframe. Cela se fait en implémentant le hook_menu pour y déclarer une entrée de type MENU_CALLBACK. La fonction callback associée, _mytheme_load_iframe() ici¹, prendra 3 arguments :

1. url : l’URL de la ressource externe à charger dans l’iframe ;
2. width : la largeur en pixels de l’iframe, de type String obligatoirement ;
3. height : la hauteur en pixels de l’iframe, obligatoirement de type String.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<?php
/**
 * template.php
 */
/**
 * @implements hook_menu()
 */
function mytheme_menu() {
    return array(
        'drupal/page/path' => array(
            'title'            => 'Mon contenu externe',
            'page callback'    => '_mytheme_load_iframe',
            'page arguments'   => array(
              'url'    => 'http://example.com/service',
              'width'  => '700',
              'height' => '1000',
            ),
            'access arguments' => array('access content'),
            'type'             => MENU_CALLBACK,
        )
    );
}
 
/**
 * Loads an external resource into an iframe.
 *
 * @param string $url   URL to load in the iframe.
 * @param string $width The width of the iframe.
 * @param string $height The height of the iframe.
 */
function _mytheme_load_iframe($url, $width, $height) {
    return theme('mytheme_simple_iframe', $iframe_url, $width, $height);
}
 
?>

Comme vous pouvez le lire, la méthode de callback fait appel à la fonction theme() sur un hook mytheme_simple_iframe qui n’existe pas.

Création d’un hook de thème

La création d’un hook permettant de faire appel à un fichier template est des plus simple, grâce au hook_theme. Définissez dans votre fichier template.php (ou dans un fichier de module) le hook mytheme_simple_iframe :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<?php
/**
 * template.php
 */
/**
 * @implements hook_theme()
 */
function mytheme_theme() {
    return array(
      'mytheme_simple_iframe' => array(
        'template'  => 'simple_iframe',
        'arguments' => array(
            'url'    => null,
            'width'  => '700',
            'height' => '500',
        ),
      ),
    );
}
?>

Simple de compréhension, on déclare un fichier de template simple_iframe auquel 3 variables seront passées. Les arguments width et height ont une valeur par défaut de précisée, ce qui permet de les omettre dans la définition de la ressource externe dans le hook_menu.

Enfin, créez le fichier de template qui affichera une iframe.

1
2
3
4
5
6
7
8

<?php
/**
 * simple_iframe.tpl.php
 */
?>
<div class="iframe">
  <iframe src="<?php print $url ?>" width="<?php print $width ?>" height="<?php print $height ?>" frameborder="0" align="left"></iframe>
</div>

Désormais, tout accès à l’URL /drupal/page/path chargera le template simple_iframe.tpl.php lorsque Drupal effectuera le rendu de la variable $content du fichier page.tpl.php.

Continuez votre lecture sur des sujets similaires

• Drupal 6 : résoudre le problème du double charset dans un thème HTML5
• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass au quotidien
• Les angoisses du theming sous Drupal 7
• Compass : supprimer le cache buster des sprites

Dans le cadre de mon travail à Clever Age j’utilise dans plusieurs projets Compass, le framework Sass, dans sa version 0.10.6. Mais voilà, cette version a laissé place à la branche 0.11 qui, malheureusement, s’accompagne de son lot de mixins obsolètes voire de bugs avec certaines extensions.

Mes nouveaux projets feront appels à la dernière version en date de Compass mais il me faut conserver une branche 0.10 sur mon poste pour assurer le support des anciens projets. Il est actuellement inconcevable de proposer aux clients une mise à jour des fichiers SCSS vers la branche 0.11.

Comment faire cohabiter les deux versions de Compass et leurs dépendances ? C’est là qu’intervient Ruby Version Manager, un gestionnaire d’environnements pour Ruby.

Installer RVM

L’installation de RVM est des plus simples : il suffit de suivre la documentation.
Je préfère installer RVM pour l’utilisateur courant (moi) et non pour tous les utilisateurs du poste, qui n’auront pas les mêmes besoins. Accessoirement, cela me permet de manipuler les gem sans invoquer sudo.

$ cd
$ bash < <(curl -sk https://rvm.beginrescueend.com/install/rvm)
$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
$ source .bash_profile
$ type rvm | head -1
rvm is a function

J’en profite pour installer la dernière version stable de Ruby :

$ rvm install 1.9.2
Installing Ruby from source to: /Users/mehdi/.rvm/rubies/ruby-1.9.2-p180, this may take a while depending on your cpu(s)...

ruby-1.9.2-p180 - #fetching 
ruby-1.9.2-p180 - #downloading ruby-1.9.2-p180, this may take a while depending on your connection...
…
Installing rubygems dedicated to ruby-1.9.2-p180...
…
Installation of rubygems completed successfully.
ruby-1.9.2-p180 - adjusting #shebangs for (gem irb erb ri rdoc testrb rake).
ruby-1.9.2-p180 - #importing default gemsets (/Users/mehdi/.rvm/gemsets/)
Install of ruby-1.9.2-p180 - #complete 

À ce point, la version de Ruby active sur le système est pourtant celle fournie par Apple (je suis toujours sous OSX :p) :

$ ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

En effet, RVM a bien réalisé l’installation de Ruby 1.9.2 mais il faut déclarer explicitement notre souhait de l’utiliser en remplacement de la version système¹ :

$ rvm use 1.9.2 --default
Using /Users/mehdi/.rvm/gems/ruby-1.9.2-p180
$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0]

Installation de la dernière version en date de Compass

Classique, l’installation de Compass se fait via gem :

$ gem install compass
Fetching: sass-3.1.1.gem (100%)
Fetching: chunky_png-1.2.0.gem (100%)
Fetching: fssm-0.2.7.gem (100%)
Fetching: compass-0.11.1.gem (100%)
Successfully installed sass-3.1.1
Successfully installed chunky_png-1.2.0
Successfully installed fssm-0.2.7
Successfully installed compass-0.11.1
4 gems installed
Installing ri documentation for sass-3.1.1...
Installing ri documentation for chunky_png-1.2.0...
Installing ri documentation for fssm-0.2.7...
Installing ri documentation for compass-0.11.1...
Installing RDoc documentation for sass-3.1.1...
Installing RDoc documentation for chunky_png-1.2.0...
Installing RDoc documentation for fssm-0.2.7...
Installing RDoc documentation for compass-0.11.1...
$ gem list

*** LOCAL GEMS ***

chunky_png (1.2.0)
compass (0.11.1)
fssm (0.2.7)
rake (0.9.0)
sass (3.1.1)

Une petite vérification d’usage :

$ compass version 
Compass 0.11.1 (Antares)
Copyright (c) 2008-2011 Chris Eppstein
Released under the MIT License.
Compass is charityware.
Please make a tax deductable donation for a worthy cause: http://umdf.org/compass

Ok, mon environnement par défaut est prêt. Voyons comment faire cohabiter une ancienne version de Compass.

Création d’un Gemset dédié à l’ancienne version de Compass

En premier lieu, je me positionne sur l’environnement ruby voulu. Ici, il s’agit du Ruby que j’ai défini par défaut.

$ rvm default
$ rvm gemset name
/Users/mehdi/.rvm/gems/ruby-1.9.2-p180

Recherchons la dernière version de la branche qui m’intéresse² (0.10 pour rappel) :

$ gem query -ran ^compass$

*** REMOTE GEMS ***

compass (0.11.1, 0.11.0, 0.10.6, 0.10.5, 0.10.4, 0.10.3, 0.10.2, 0.10.1, 0.10.0, 0.8.17, 0.8.16)

Ok, il me faut la 0.10.6.
RVM donne accès à des gemsets qui sont des espaces cloisonnés de gems pour une version de Ruby donnée. Pratique, j’ai justement besoin d’isoler les gems de la version 0.10.6 de Compass à celles de la dernière version en date.

Je crée un gemset au nom assez explicite et l’utilise :

$ rvm gemset create compass0.10.6
$ rvm gemset use !$
$ rvm gemset name
compass0.10.6

La création d’un gemset fourni un nouvel environnement vierge de gems (ou presque, rake restant disponible) :

$ gem list

*** LOCAL GEMS ***

rake (0.9.0)

Je peux maintenant installer Compass 0.10.6³, ses dépendances et autres extensions en toute tranquillité.

$ gem install compass --version 0.10.6 --no-rdoc --no-ri
Fetching: haml-3.1.1.gem (100%)
Fetching: compass-0.10.6.gem (100%)
Successfully installed haml-3.1.1
Successfully installed compass-0.10.6
2 gems installed
$ gem list

*** LOCAL GEMS ***

compass (0.10.6)
haml (3.1.1)
rake (0.9.0)

La petite vérification d’usage :

$ compass version
Compass 0.10.6
Copyright (c) 2008-2009 Chris Eppstein
Released under the MIT License.

Installer l’extension Lemonade pour Compass 0.10.6

Il ne me reste plus qu’à installer l’extension lemonade que j’utilise dans mes projets :

$ gem install lemonade --version '< 0.3.5' --no-rdoc --no-ri
…
4 gems installed

J’installe ici la version strictement inférieur à 0.3.5 de lemonade car cette dernière lève directement une erreur pour indiquer que la gem lemonade est désormais dépréciée au profit de Compass Sprites. Le hic étant que ce dernier n’existe pas dans Compass 0.10.6.

Malheureusement, la gem de lemonade ne précise pas les bonnes versions de ses dépendances, et, de ce fait, on se retrouve avec un environnement incapable de générer les images des sprites. Pour corriger cela, on commence par downgrader la version de chunky_png :

$ gem uninstall chunky_png --version 1.2.0
$ gem install chunky_png --version '< 1.0.0' --no-rdoc --no-ri
…
1 gem installed  

La gem haml installée avec l’extension lemonade est incompatible avec Compass 0.10.6 et risque de générer une erreur du genre :

compile scss/screen.scss
  error scss/screen.scss (Line 2087: Not a valid color stop: #bcd712 74%)

Il suffit donc d’installer la dernière version de la branche 3.0 :

$ gem install haml --version '< 3.1' --no-rdoc --no-ri
$ gem uninstall haml --version 3.1.1
$ gem list

*** LOCAL GEMS ***

chunky_png (0.12.0)
compass (0.10.6)
fssm (0.2.7)
haml (3.0.25)
lemonade (0.3.4)
rake (0.9.0)
sass (3.1.1)

Utilisation

Par défaut, en ouvrant un shell, Compass sera disponible en version 0.11. Si j’ai à travailler sur un projet en 0.10 il me suffit d’ouvrir un nouveau shell et d’activer temporairement le gemset compass0.10.6 :

$ rvm gemset use compass0.10.6

À l’avenir, je maintiendrai à jour la version de Compass dans l’environnement par défaut et, si besoin est, je figerai dans un nouveau gemset la version de Compass devenu obsolète.

Continuez votre lecture sur des sujets similaires

• Gestion avancée de Sass et Compass avec RVM et Bundler
• Compass : supprimer le cache buster des sprites
• Utiliser Compass dans un thème WordPress, la bonne méthode
• Compass au quotidien
• Support de présentation de l’atelier « Compass, sauvez l’intégrateur ! »