Accueil / Blog / Métier / 2015 / Ecrire du code Drupal compatible avec plusieurs versions

Ecrire du code Drupal compatible avec plusieurs versions

Par Simon Georges — publié 23/04/2015
Aux #drupaldevdays 2015, @OSInet présente une méthode de réutilisation du code sur plusieurs versions de Drupal (ou même Symfony, Silex, ...).
Ecrire du code Drupal compatible avec plusieurs versions

Contexte

Cette méthode est utilisatble pour les développeurs de site Drupal 6 ou 7 déjà en production (qu'on ne peut pas updater en Drupal 8). Ou pour ceux qui continuent de faire du Drupal 7 aujourd'hui, et qui n'ont pas les moyens de construire le site en Drupal 8 en parallèle. Cette méthode est utilisable jusqu'à l'utilisation de Drupal 8 en production directement.

Périmètre

On se concentre sur le code uniquement métier, le reste n'étant pas réutilisable. On va avoir, appoximativement :

  • 70 à 80% de code orienté objet réutilisable ;
  • 10 à 15% de code lié à la configuration (qu'il faudra migrer en CMI) ;
  • 10 à 15% de code à usage unique remplacé complètement en Drupal 8 (code complètement perdu).

Avertissement

Attention de ne pas en faire trop (inutile par exemple d'utiliser le module Twig en Drupal 7, il est probable que la couche front sera de toute façon refaite en Drupal 8, inutile également d'essayer de réécrire CMI ou WSCCI en D7).

Boîte à outils

  • git (surtout en utilisant des dépots isolés pour le code métier et des submodules Git pour les inclure) ;
  • composer (et la clause repositories du composer.json) ;
  • utiliser un class-loader PSR-4 (celui de Composer, disponible sur Drupal 6 également) ;
  • pour les tests unitaires : PHPUnit ;
  • pour les tests fonctionnels : Behat (sera peut-être un standard D8 standard (voir #2302545), Mink & Goutte y sont déjà).

Back-end

L'idée est de considérer que le module (au sens du fichier .module) Drupal ne représente que la partie du code qui ne sera pas récupéré, et implémente juste des bouchons :

  • implémenter les hooks pour récupérer les bons paramètres
  • récupérer une instance de ServiceManager
  • invoquer une méthode sur l'instance en lui passant les paramètres du hook.

La logique métier est donc dans des méthodes d'instance.

"Don't be STUPID, be SOLID"

STUPID et SOLID sont deux acronymes représentant une liste de pratiques. Les STUPID sont plutôt à éviter. Frédéric (et d'autres) préconisent plutôt d'adopter SOLID (dont les 2 premiers sont les plus importants) :

  • Single-responsibility principle : chaque classe est en charge d'une seule chose (une classe par formulaire, une classe par block, un controller pour les pages d'administration, un pour les pages standard, un ServiceManager par service).
  • Open / Closed principle : Open for extension, Closed for modification, recommande l'utilisation d'Interfaces.

Pour les logs, utilisez le standard PSR/3 (par exemple la librairie Monolog).

Certaines des fonctions Drupal peuvent vous manquer : t(), variable_..., cache_..., url(), l(). La meilleure solution est pour cela d'implémenter un sous-ensemble du \Drupal de Drupal 8 (et pas plus que ce dont vous avez besoin !).

Pour le stockage !

  • Utilisez des entités : en utilisant l'Entity API, vous pourrez implémenter des classes que vous pourrez réutiliser en Drupal 8.
  • Séparez votre "configuration" entre configuration, état & paramètres, pour les adapter plus rapidement en D8.

Front-end

Javascript

Pas de plan spécifique. Essayez simplement d'utiliser les dernières versions de toutes vos bibliothèques et de limiter votre utilisation de jQuery.

CSS

Adoptez des principes SMACSS.

Theme

N'utilisez pas de fonction process_*, n'utilisez que du preprocess_*.

Retours d'experience

Tout cela est difficile, vous aurez probablement à aider les développeurs habitués aux anciennes pratiques.

Cela dit, cette technique a déjà été utilisée au moins deux fois :

  • Certaines bibliothèques développées pour Commerce 2.x sont également utilisés par Sylius ;
  • Pour un système de commentaires sur un gros projet français : au final, 23% de code à jeter, et 77% de code réutilisable.
ABONNEZ-VOUS À LA NEWSLETTER !
Voir aussi
Varnish et Drupal 9 : le vidage de cache ciblé Varnish et Drupal 9 : le vidage de cache ciblé 31/12/2020

La mise en place d'un cache de pages anonymes Varnish devant un Drupal 9 permet une mise en place ...

Varnish et Drupal : gérer un cache anonyme étendu Varnish et Drupal : gérer un cache anonyme étendu 14/03/2018

Le rôle d'un Reverse Proxy Cache Varnish dans une architecture Web (type Drupal).

Migration d'un site Drupal 7 en Drupal 9 Migration d'un site Drupal 7 en Drupal 9 31/12/2020

Trucs, astuces et bouts de code pour migrer votre site web de Drupal 7 à Drupal 9

Drupal & Gatsby : retour d'expérimentation Drupal & Gatsby : retour d'expérimentation 01/09/2020

Gatsby est une solution montante pour créer des sites statiques. Voyons dans quelle mesure il est ...

Sortie de Drupal 9 : préparez-vous ! Sortie de Drupal 9 : préparez-vous ! 28/05/2020

Dans quelques jours, le 3 juin 2020, aura lieu la sortie de Drupal 9 en version stable. À quels ...