Projet xxx
/-- conf
-- drush
-- patches
-- scripts
-- sql
-- src
-- www
composer.json
composer.lock
.editorconfig
.gitignore
En général, tous les fichiers sont versionnés, saut /conf/drupal/local.php qui contient des paramètres spécifiques au poste de développement (mysql etc.).
Desfois, dans /www/ se trouve des répertoires comme /www/static/media, /www/static/pdf etc. Le /static/ permet de gérer plus facilement les confs au niveaux http.
Le répertoire config contient tous les fichiers de configuration de Drupal, serveur Web, Varnish, cron..., souvent partiels. Ces fichiers sont appelé depuis les fichiers principaux (www/sites/default/settings.php, /etc/apache2/apache2.conf ou symlink depuis /etc/apache2/sites-enables/xxx, etc.)
Même si on n'utilise pas, par exemple pour des raisons de sécurité, par exemple un fichier conf Varnish, on garde dans ce répertoire une copie à jour.
Le fichier .gitignore en racine et les fichiers de conf Apache permet de ne pas toucher les fichiers .gitignore, .htaccess et robots.txt du core.
Le fichier conf de Drupal se situant à www/sites/default/settings.php, est versionné et ne change jamais (qui permet de garder le répertoire www/sites/default en mode lecture seule -- ce que fait Drupal) ne contient de deux lignes :
<?php
require __DIR__ . '/default.settings.php';
require __DIR__ . '/../../../../conf/drupal/settings.php';
Le fichier /conf/drupal/settings.php contient des configs globaux et inclut aussi local.php. Les configs globaux peuvent ẽtre divisés en plusieurs fichiers en fonction de besoin.
/-- conf
-- inc
autoload.php
devel.php
localize.php
rewrite.php
settings.php
local.php
settings.php peut inclure les paramètres de prod (memcache etc. sauf les clés/mots de passe). Ces paramètres, versionnés, sont "annulés" par devel.php. On dispose alors une historique des modifications/optimisations des paramètres de prod.
devel.php contient des paramètres "locaux communs" pour le poste de dev. Il n'est pas inclu par settings.php mais peut ẽtre inclu par local.php. Il est là juste pour des convenients. Par exemple on y met l'url pour stage_file_proxy, unset l'option de memcache ou mettre l'accès Solr en lecture seule.
localize.php contient les customisations de la langue par défaut.
rewrite.php contient les redirects de bas niveau (sans avoir à bootstrapper Drupal en mode full). Dans Drupal 6, c'est l'endroit pour mettre les fonctions comme custom_url_rewrite_inbound.
Les variables qu'on veut garder sous les yeux et qu'on n'a pas besoin de modifier par UI, on les met dans un fichier de conf au lieu d'exporter avec Strongarm.
Le fichier autoload.php est un class loader custom, qui autoload les composants ows, xxx et inclut le class loader de Composer dans /src/vendor/autoload.php. Il pourrait aussi autoload les classes dans sites/all/modules/custom suivante une convention (@todo à définir). Un exemple d'autoload :
<?php
/**
* PSR-0 autoloader to load classes in src/OWS/*.
*/
spl_autoload_register(function($class) {
if (file_exists($filename = '../src/' . preg_replace('#\\\|_(?!.+\\\)#', '/', $class) . '.php')) {
include $filename;
}
else {
return FALSE;
}
});
// Composer autoloader.
require __DIR__ . '/../../src/vendor/autoload.php';
Ce répertoire contient drushrc.php et des fichiers de commande foobar.drush.inc.
/www/sites/all/drush/drushrc.php contient une seule ligne :
<?php
require __DIR__ . '/../../../../drush/drushrc.php';
/drush/drushrc.php contient des options, et particulièrement cette ligne :
$options['include'] = array(__DIR__);
-- src
-- ows
-- xxx
-- vendor
-- guzzle
-- etc.
Chaque composant est une bibliothèque indépendante de Drupal, ou au moins de la version de Drupal.
ows contient les composants qu'on veut utiliser dans plusieurs projets. Par exemple \OWS\Utility\Text::implode(array('a', 'b', 'c')) retourne "a, b et c".
Ils sont dans sites/all/modules forcément. On a comme hiérachie :
-- www/sites/all/modules
-- contrib
-- custom
-- devel
Tous les modules contribs, patchés ou non, se trouvent dans contrib/. Les patches sont dans /patches/ et préfixés par le nom de module.
Les modules dans devel sont ajoutés à la volonté. Par défaut ils ne sont pas activés en prod. Exemples des modules dans devel/ : admin_menu, backup_migrate, coder, devel, stage_file_proxy.
Les modules customs sont préfixés par xxx_. On trouve toujours dans un projet ces modules :
- xxx_common : les hook_update_N pour l'intégration continue, les blocs et les alters communs du site. Y se trouve aussi l'export des variables de base.
- xxx_backoffice
En règle générale, on essaye de garder les fichiers .module petits et rend les opérations unitaires en les mettant comme méthodes statiques d'une classe. Cela permet de tester plus facilement une opération. Par exemple, pour chaque bloc, on crée une classe avec comme méthodes : info() (pour hook_block_info()), view() (pour hook_block_view()) et les implémentations de hook Drupal ne sont que des "wrapper" qui appellent ces méthodes.
Dans un module, les classes sont organisées selon la norme PSR-4 :
-- xxx_foo
-- src
-- Block
Author.php
xxx_foo.info
xxx_foo.module
Author.php correspond à la class \Drupal\xxx_foo\Block\Author.
Il n'y a pas d'instinction entre une feature et un module custom. Généralement, il y a une feature par type de contenu, sauf s'il y a un lien étroit (deux CT de "product display" et des types de produit Commerce, ou 3 CT différents de ressource).
Dans une feature se trouve les hooks, les blocs et les alters concernant celle-ci.
Ne jamais coder en dur les ID (tid, role id etc.). Utiliser une constante, ou mieux, une constante d'une classe.
RAS en l'état. On préfère SASS avec Compass et utilise au maximum les variables, mixins et @extend pour faciliter la maintenance.