Cette boîte à outils ne contient que ce qui est spécifique à Drupal et ne touche à l'environnement de développement à proprement parler.
Documentation
- Documentation des API
- Vous trouverez ici une documentation complète des principales API Drupal (forms, batch, cron, etc.). lien.
- Référence des API
- Absolument indispensable, ce guide organisé par version de Drupal permet de rechercher un hook particulier et d'en étudier la documentation. Les sections sur le côté gauche permettent aussi de chercher dans le code, les constantes, etc... lien.
- Recherche un hook
- Ce n'est pas une resource à proprement parler mais une astuce bien pratique. Allez sur google et tapez le nom du hook sous sa forme "prototype", par exemple hook_menu. Le premier lien renvoyé par Google est souvent la référence Drupal. exemple
- Les guides de développement
- La référence, en anglais, sur tout ce qu'il faut savoir pour développer thèmes et modules. lien.
- Tutoriels Drupal
- Ceux là sont pas toujours terribles mais ont le mérite d'être écris en français. lien.
Outils
- Recherche un module contrib
- Là aussi c'est juste une utilisation intelligente de Google. Dans la zone de recherche tapez site:drupal.org inurl:project taxonomy. Et vous obtiendrez la liste de tous les modules contrib qui parlent de taxonomy.exemple
- Auditer la qualité de votre code
- Un module extrêmement pratique est Coder. Une fois installé dans Drupal, il vous permet d'opérer une revue de code sur un ou plusieurs modules et de vous donner la liste des erreurs ou avertissements qu'il aura détecté. Ce miraculeux module permet aussi de lister les portions de code qui ne sont plus fonctionnelles d'une version à l'autre de Drupal et ainsi d'accélérer grandement la migration de vos modules. lien
- Traduction d'un module
-
Cet outil en ligne de commande permet d'extraire d'un module les chaînes éligibles à une traduction automatique par Drupal. lien.
Astuces
Debugger du code
Un moyen pratique de debugger du code Drupal sans debugger pas à pas est de passer par les messages du site. Par exemple pour lister le contenu d'un objet :
drupal_set_message
("<pre style='overflow:auto;max-height:200px'>".print_r($mon_objet,1)."</pre>");
Dans la même idée, un problème classique est de vérifier les requêtes SQL émises, ce qui n'est pas toujours simple du fait de l'utilisation des motifs (%d) et des accolades Drupal. La solution est de créer un wrapper autour de db_query :
function debug_query($query) {
$query = db_prefix_tables($query);
if (isset($args[0]) and
is_array($args[0])) { // 'All arguments in one array' syntax
$args = $args[0];
}
_db_query_callback($args, TRUE);
drupal_set_message("<pre style='overflow:auto;max-height:200px'>".$query."</pre>");
return db_query($query,$args);
}
Et après d'utiliser debug_query en lieu et place de db_query. Ne pas oublier de retirer cela lorsque le module est corrigé.
Gérer les caches
Pour améliorer sa vitesse de rendu, Drupal fait une utilisation intensive des caches. Il est donc pratique de pouvoir les vider pour observer le rendu réel du code que l'on produit. La première chose à faire est donc sur votre site de développement de déconnecter toutes les options de performances (cache page, css, js, etc.).
Ensuite il est possible de vider les tables de cache (cache_*) par du code. Par exemple pour la table cache_page :
cache_clear_all(NULL,'cache_page'); // Vide le cache des page
Enfin, plus spécifiquement, nous pouvons forcer la relecture des hook_theme par un drupal_rebuild_theme_registry(); et les hook_menu par un menu_rebuild();.
Sites de développement et de production
Il est toujours malin d'éviter de modifier un site actuellement en production. Il est donc important de disposer d'au moins deux environnements, l'un pour tester, l'autre pour déployer. Une bonne manière de gérer cela sans trop de problèmes est d'utiliser un outil de gestion de version, comme subversion et d'y mettre votre version de Drupal. Ainsi lorsque vous avez validé vos modifications, vous pouvez commiter vos changements d'un côté et les déployer de l'autre en deux commandes.
Dans l'autre sens, une autre bonne astuce est d'utiliser SSH/RSync pour synchroniser votre base en production avec la base en développement. Cela se fait très simplement par un scripte de ce type :
update-database.sh
#! /bin/sh
dropdb $1 -U postgres
createdb --encoding=UNICODE -U postgres $1
ssh mon_serveur_de_production "pg_dump -U postgres $1 -h localhost | gzip" | gunzip | psql -U postgres $1
Ensuite, il ne reste plus qu'à lancer la commande en passant en paramètre le nom de la base à remonter.
- répondre
Daniel , le 26 May, 2008 - 07:27Pour info, dans la même veine...
Après m'être construit ma propre fonction de debug
que j'appelais avec par exemple
j'ai découvert http://drupal.org/project/devel qui fait ça, mais aussi l'affichage des requêtes sql, les temps d'exécution et la RAM consommée.
Il permet aussi de voir les fonctions du thème appelées pour chaque bloc.
Il fait planter mon firefox3-ß5, mais ça à l'air de marcher correctement avec epiphany.
A regarder également (pas encore eu le temps de tester réellement) : simpletest, Form inspector et drush (drupal shell, pour manipuler les modules façon apt-get ou urpmi, vider le cache, etc.).
- répondre
Ulhume, le 26 May, 2008 - 18:00Excellentissime !! Merci
Je vais regarder tout cela.
Poster un nouveau commentaire