Le 18 Juin 2011 à eu lieu à Paris un DrupalCamp (= un barcamp Drupal), dans les locaux de Linagora. D’abord un remerciement à tous les sponsors qui ont permis que cet évènement ait eu lieu. Comme j’ai eu la chance d’y participer, je me sens obligé d’en faire un rapide compte-rendu.

Première session animée par Maxime Topolov en crocs: Sites à haut trafic, systèmes de cache…

2 Types de sites (et de traffic):  Trafic anonyme vs Trafic connecté.

Un fort trafic anonyme permet l’utilisation de cache statique, comme Varnish. Pour ce dernier, pas besoin de module drupal. C’est un soft à installer sur son serveur; Il vient se placer sur le port 80, et intercepte les requêtes destinée à Apache pour servir une version caché, et donc beaucoup plus rapidement.
Pour Varnish, on peut utiliser le standard ESI, permettant de definir une durée de vie (TTL) par zone de la page. Par exemple, un header/footer avec une grande durée de vie, mais le bloc « derniers articles » avec une courte durée de vie. Le module ESI permet de mettre ca en place.
On peut également utiliser le module Boost, qui enregistre « physiquement » sur le serveur les pages HTML  pour les servir au visiteur. Boost est moins performant que varnish car, étant un module, il implemente necessairement le bootstrap drupal.

Memcache: Le module cache_router permet de déporter les tables de cache de drupal (cache_*) en mémoire vive, afin de décharger le serveur SQL. (Il s’utilise quel que soit le type de trafic.)

MongoDB: Base de donnée orientée document (clé|valeur), No SQL. Le module Drupal MongoDB existe, mais necessite du code custom. On peut, par exemple, stocker l’intégralité d’un node, avec ces champs, comme un document MongoDB. (ca reste assez flou pour moi;)

2 modules à tester pour cacher les pages avec un trafic connecté: authcache et easy_authcache

HTML5 & mobilité dans drupal

On retrouve l’initiative Drupal-HTML5 : http://groups.drupal.org/html5

Le problème fondamental est celui qu’on avait (ou qu’on a toujours) en desktop, soit les differences de rendu entre les differents navigateurs. Le web mobile est visible sur un encore plus grand nombre de terminaux. Lors de cette session, nous nous sommes mis d’accord pour ne parler ni de WAP/WML, ni d’appli native (iOS, Android), mais bien de web: HTML & CSS (et donc HTML5 & CSS3)

Theming: 2 manières de faire ont été abordées, soit un changement de thème, en fonction du user-agent (mobile tools, ou themeKey), soit un theme adaptatif à base de @media-queries. A noter que mobile_tools s’integre à context, et permetterait de jouer sur les blocs en fonction du terminal de lecture. On pourrait aussi jouer sur les profiles image_cache (ou style d’image, en D7) afin d’envoyer au client des images d’un taille adaptée à son lecteur (mobile, tablette, desktop, wide-screen..)

Coté HTML5/CSS3, afin de savoir quelle propriété est disponible sur quel navigateur, on peut noter le site http://caniuse.com/

Reflexion interessante sur l’aspect business: Avant, on trouvait des agences web, et des agences mobiles. Ces dernières avaient une grande expertise pour le developpement d’application mobile, WAP ou natives. Maintenant que le web s’améliore de ce coté la, les agences web « traditionnelles » peuvent s’attaquer au marché mobile, en proposant des applications riches basées sur des languages web (HTML5/CSS3/JS)

Liens en vrac: jQuery mobile, titanium, bkml, le Financial Times abandonne les applications natives pour proposer une application HTML5,

Staging, Déployement

Eternel problème avec Drupal, on fait face à 2 problèmes: La migration de la configuration, et la migration des contenus.

Migration de configuration

Features, hook_update, backup_migrate, le tout avec drush, et des scripts bash.

Features (enfin en version stable!) permet de packager un ensemble fonctionnel sous la forme d’un module drupal (des types de contenus, de la taxonomie, des menus, des vues, des profiles imagecache …).
Les hook_updates permettent d’effectuer des actions en base de données qui n’ont pu être exportées avec une feature. En gros les « cases a cocher » dans l’interface d’admin de drupal.
Backup’n'migrate, avec des profils spécifiques, permet d’exporter uniquement quelques tables. C’est utile, par exemple, pour les tables de la traduction, ou pour la table des permissions. De l’avis général, on utilise backup_migrate en dernier recours.

Migration de contenu

Pour la migration de contenu d’une instance à une autre, on utilise les modules Feeds, Migrate, ou Deploy. Ces modules peuvent aussi être utilisé pour migrer d’un autre CMS à Drupal.

i18n, multilinguisme

Info sur le module translation_table, qui propose une meilleure UI pour l’interface de traduction de drupal6.

Drupal7 propose la traduction des nodes par champ (translatable fields), avec d’avoir un seul et unique nid par contenu multilingue. Intéressant car le body est devenu un field en D7; Reste le problème du titre, car $node->title n’est pas un champ.

Une bonne pratique à été conseillée: Toujours mettre l’anglais comme langue par défaut, même si on veut le français comme langue par défaut sur le front. En effet, avoir autre chose que l’anglais comme défaut posait des problème pour la traduction de certains éléments (label de champs, termes et vocabulaire, nom de menus…)

En vrac

• Un module de gestion des médias, utilisé par radio-france: Scald
• Des montages photos sensationnels : http://www.flickr.com/photos/julien-dubois/5849562651/in/photostream/
• La migration D6 -> D7 n’est pas si simple (citation), et c’est éventuellement le moment de faire une refonte fonctionelle du site, afin de n’avoir qu’une migration de contenu à faire.
• La défense, un samedi matin, quand il bruine, c’est triste !

Si j’ai raconté des conneries, ou s’il faut que je complète certaines infos, n’hesitez pas, les commentaires sont fait pour ça! (Egalement en cas de faute d’orthographe qui fait saigner les yeux)