J'ai enfin pris le temps de passer sur les forums d'IBM developerWorks et de laisser quelques commentaires aux auteurs de l'excellente série d'articles sur le développement d'un site avec Drupal. Ils vont jusqu'au développement de modules, y compris l'explication du système de hooks de Drupal, ce qui fait plaisir à voir.
Voici les commentaires que j'ai laissés :
La figure 2 montre le répertoire « modules » de base avec un tas de modules supplémentaires.
La bonne pratique consiste plutôt à placer tous les modules qui ne font pas partie du cœur dans votre répertoire sites local. Ainsi, pour domain.com, vous placeriez tous les modules hors cœur dans /sites/adtech.internet.ibm.com/modules. Cela garde la base principale de Drupal propre et facile à mettre à jour : vous pouvez remplacer ou mettre à niveau tout ce qui n'est pas dans le répertoire de base sans vous inquiéter.
De plus, depuis la version 4.7, Drupal prend en charge les fichiers .install, qui contiennent le SQL nécessaire pour initialiser automatiquement les tables de la base de données. Il faudrait les utiliser au lieu du fichier .sql illustré.
Ce petit message sur le fait de garder tous les modules dans votre dossier « sites » local n'est donc que le début des bonnes pratiques. Presque toutes les installations Drupal sur lesquelles je travaille sont multisites. Beaucoup utilisent un ensemble de modules semblable, mais pas identique. Pour travailler à partir d'une seule base de code, voici comment j'organise les choses :
/var/www/html/[installation Drupal de base, extraite du CVS]
/var/www/modules/[modules contribués individuels, extraits avec CVS]
/var/www/themes/[thèmes individuels, extraits avec CVS]
/var/www/html/sites/[tous les sites]
/var/www/html/sites/domain.com/modules/[lien symbolique vers chaque /var/www/modules/$modulename]
Maintenant, pour mettre à jour mon Drupal de base, je n'ai qu'à lancer une commande cvs update. Je peux faire de même module par module. J'utilise la commande CVS suivante :
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-4-7 -d modulenamehere contributions/modules/modulenamehere
Parfois, vous voudrez la version CVS d'un module : retirez simplement « -r DRUPAL-4-7 » de la commande. Vous trouverez plus de détails sur l'utilisation du dépôt CVS des contributions sur Drupal.org.
Mais si vous voulez utiliser des versions différentes? Ou peut-être développer un module? Ou remplacer ou corriger un module du cœur? Eh bien, pour utiliser une version CVS avec un seul site (disons beta.domain.com), extrayez-la simplement sous /var/www/modules/module-CVS et créez un lien symbolique vers cette version plutôt que vers la version étiquetée.
Remplacer un module du cœur ne pose aucun problème. Tout module du cœur que vous placez dans /var/www/html/sites/domain.com/modules remplacera le module du cœur de l'installation principale. C'est une façon sûre d'avoir des modules du cœur corrigés sans vous demander si vous aurez des problèmes en mettant à jour votre installation principale de Drupal.
J'espère que ces précisions sur d'autres bonnes pratiques vous seront utiles. Le service Bryght Hosting (eh oui, il n'est pas encore tout à fait lancé publiquement; il est conçu pour offrir un hébergement de qualité production aux sites Drupal), propulsé par Firebright, est préconfiguré selon cette structure, et nous maintenons aussi une Bryght Base dans notre SVN public, que nous gardons corrigée et à jour. Par exemple, TinyMCE y est installé avec toutes les configurations nécessaires pour le plugiciel img_assist, la vérification orthographique et le bouton drupalbreak.
Et ce n'est qu'un survol de quelques bonnes pratiques. Vos questions sont les bienvenues!