Bonnes pratiques CMS Drupal

Les bonnes pratiques avec Drupal

1 octobre 2010 par Adrien

Article spécial développeur : lorsque l’on commence avec Drupal, on s’attaque à un CMS avec une courbe d’apprentissage très raide, les premiers balbutiements de modification de code sont souvent hésitants et on ne connaît pas toujours la portée de ce que l’on touche.

Il est vrai que Drupal est connu pour être très flexible, il existe par conséquent de nombreuses manières de réaliser une même fonctionnalité. Cependant toutes ces méthodes ne sont pas forcément adaptées et on peut rapidement se retrouver avec de sérieux problèmes de référencement, de performance et surtout de maintenabilité.

Chacun bénéficie de ses propres méthodes de codage sous Drupal autant dans le code proprement dit que dans l’organisation de son développement. C’est avec la pratique et l’expérience que l’on acquière l’expertise Drupal, en s’inspirant des modules de la communauté et en respectant la façon de coder spécifique à Drupal. Voici les principales bonnes pratiques à respecter lors du développement d’un site Drupal :

Modules

- Évitez d’installer une quantité astronomique de modules. Au chargement de chaque page, Drupal va systématiquement vérifier chaque module activé (hooks, menus, themes, ...). Chaque module activé inutilement est donc une perte de temps.

- Vous pouvez utiliser plusieurs fois le même champ pour des types de contenu différents pour éviter de recréer plusieurs fois la même méthode. Par exemple pour un type de contenu « vidéo » et un type de contenu « audio » vous pouvez utiliser le champ commun « durée ».

- Avant de commencer à développer un module personnel, faites une recherche poussée pour être certain qu’aucun module testé et validé par la communauté ne réponde déjà à votre besoin.

Développement

Cela semble évident pour certains mais il ne faut jamais modifier les modules du core et de la communauté de Drupal car il y a des mises à jour régulières. Lorsqu’un module dont le code a été modifié est mis à jour, les changements sont écrasés, on ne peut donc pas maintenir aisément (ou même pas du tout) un site dont les fichiers ont été modifiés. La solution pour modifier le comportement de Drupal est de :

- Créer systématiquement un module pour toute modification du code, Drupal est tellement flexible que l’on peut complètement modifier son comportement à partir d’un module personnel et la création d’un module est très simple (deux fichiers à créer). Certains font leurs modifications dans le thème de leur site mais les modifications fonctionnelles sont à réaliser dans un module, le thème étant réservé pour l’affichage. Si l’on change de thème, on doit pouvoir retrouver le fonctionnement.

- Les grosses fonctions associées aux menus doivent être de préférence sorties du fichier module pour les mettre dans un fichier inc en utilisant l’attribut file dans un objectif de performance.

- Les noms de fonction doivent commencer par le nom du module pour éviter de retrouver deux fois le même nom et de générer une erreur.

- Les fonctions d’aide propres aux modules peuvent être préfixées par un _ (underscore).

Theming

- Utiliser les « starting theme » pour créer votre thème personnalisé (à moins que vous ne partiez d’un thème de la communauté que vous améliorez), il est plus simple de modifier un thème simple conçu pour être modifié qu’un thème comme Garland ou Bluemarine. Les meilleurs thèmes pour démarrer sont http://drupal.org/project/zen et http://drupal.org/project/basic

- Dans un but de clarté, il est préférable de séparer l’admin du front-office et pour cela autant utiliser un thème spécialement conçu pour le back-office Drupal comme Rootcandy http://drupal.org/project/rootcandy pour tous les projets, vous allez garder les mêmes repères en conservant le même back-office. Pour choisir un thème différent pour l’administration allez sur : Configuration du site >> Thème de l’administration.

Ne jamais rien envoyer à l’écran sans utiliser la fonction theme() qui permet d’assurer une séparation nette des informations brutes de contenu et les choix de présentation propres au site tout en laissant au themeur la possibilité de surcharger les fonctions de thème.

Vue

- Regrouper les affichages de vos vues, c’est à dire ne créez pas des vues inutilement. Par exemple, pour un même type de contenu, choisissez de préférence deux affichages d’une même vue plutôt que deux vues différentes.

- Utiliser le style champs plutôt que le mode nodes, en effet le style nodes charge systématiquement tous les champs et tous les attributs du nœud alors que le style champs ne va chercher que les éléments demandés, l’exécution et le traitement de la requête construite par views sont dont plus rapides.

Système de fichier

- Ne pas placer vos thèmes personnels directement dans /themes mais dans /sites/all/themes

- Placer les modules de la communauté dans /sites/all/modules/contrib et les modules que vous avez réalisé dans /sites/all/modules/custom

Traduction

- Toujours entourer le texte visible par l’utilisateur de la fonction t() : cette fonction permet de rendre traduisible simplement un module. Le contenu de cette fonction doit être impérativement en anglais, c’est la langue fournie pas Drupal (même si la langue par défaut du site est le français).

Base de données

- Une bonne méthode pour sauvegarder et charger vos bases de données est d’utiliser le module « backup and migrate » qui possède plein d’avantages. Il sauvegarde vos bases de données dans un répertoire du site sans les tables de cache qui alourdissent les dumps inutilement, avant de faire une manipulation risquée on peut faire un backup de la base pour pouvoir revenir en arrière au cas où et finalement ce module permet en configurant le programme CRON de faire une sauvegarde automatique régulièrement de la base, en cas de problèmes cela peut s’avérer très utile.

- Pour des raisons de sécurité (injections SQL, …) Drupal fournit une couche d’abstraction pour les accès à la base de données, une requête SQL classique :

“SELECT n.nid, n.title, n.created FROM node n WHERE n.uid = $uid”

devient sous Drupal :

“db_query(‘SELECT n.nid, n.title, n.created FROM {node} n WHERE n.uid = %d’, $uid);”

On remarque deux choses : les accolades autour du nom de la table et l’extraction de la variable de la requête.

Pour en savoir plus sur les requêtes SQL sous Drupal : http://api.drupal.org/api/group/database/6

Avant la mise en production

- Désactiver les modules de développement tels que Devel, ils ne seront plus utiles en production.

- Activer le cache (Configuration du site >> Performance), la compression des pages, le cache des blocs et l’optimisation des fichiers CSS et JS.

À lire

- La bonne façon de coder sous Drupal : http://drupal.org/coding-standards

- Comment traduire un module : http://drupal.org/node/220341

Rubrique