Drupal 8 – partie 2 : architecture et composants

drupal8_logo

Dans un précédent article, nous avons eu un aperçu des innovations fonctionnelles apportées par Drupal 8. Si certaines sont importantes, les changements cruciaux induits par cette nouvelle version du CMS relèvent davantage de la transformation complète de son socle technique : Drupal s’avère plus que jamais être un CMF (content management framework).

Caractéristiques techniques générales

Refonte du code PHP

Drupal 8 requiert PHP en version 5.4.5 minimum (contre 5.2.5 pour Drupal 7). En effet, Le code de D8 est orienté objet de manière prépondérante : il utilise les classes, les interfaces et les traits. Par ailleurs, les namespaces et la norme PSR-4 sont également usités : tout ceci est le signe qu’on a affaire à une véritable ré-architecture de Drupal, et pour cause : seulement 20% du code originel de Drupal 7 a été conservé !

Outre la modernisation du code PHP (enrichi au passage d'utilitaires tels que PHPUnit et Composer), notons que Drupal 8 utilise de manière native HTML5 et jQuery 2.1.3 (une version à jour, contrairement à celle présente dans Drupal 7).

Nouvelle architecture de fichiers

Le nouveau Drupal est 4 fois plus lourd que son prédécesseur (44,0 Mo au lieu de 11,8 Mo), et contient 10 fois plus de fichiers (12 279 contre 1087), symptomatique de l’utilisation de nombreuses librairies externes, mais aussi d’un meilleur découpage puisque le nombre de lignes de code moyen par fichier a été divisé par 3.

On observe par ailleurs des changements dans l’arborescence des fichiers : le dossier contenant les modules se trouve désormais à la racine (sauf en cas d’installation multi-sites, pour laquelle le dossier sites/all/modules a encore sa place), de même que les thèmes. Les dossiers correspondant au cœur de Drupal ont été basculés dans un dossier core à la racine. L’architecture est donc plus lisible, avec des dossiers davantage cloisonnés.

arborescence_d7

Différences d'arborescence à la racine entre D7 (à gauche) et D8 (à droite)

 

Une base de données revisitée mais sans changements fondamentaux

En ce qui concerne la structure de la base de données, si divers changements ont été effectués (par exemple la table users a été subdivisée en plusieurs tables), le système « 1 nouveau champ créé en backoffice = 1 table SQL générée » est conservé (en réalité il y a même deux tables qui sont générées si on prend en compte la table de révisions). Cela préserve la souplesse de Drupal dans sa définition de nouveaux types de contenus (et des champs qui vont avec), au risque d’avoir de nombreuses jointures lors de requêtes SQL (la plupart des CMS préfèrent le système « 1 champ = 1 colonne SQL dans la table du type de contenu »).

 L'arrivée de Symfony2

Contrairement à ce qui a pu se dire, Drupal 8 n'est pas basé sur Symfony2 (au contraire d'eZ Publish). Mais ce framework a été partiellement intégré à Drupal, avec certains de ses composants comme le routing, la gestion de dépendance, l’event-dispatcher et des librairies qu’il utilise (Twig, Doctrine).

La syntaxe des contrôleurs, des entités et des formulaires, qui utilisent largement la POO, sont proches de la syntaxe préconisée par Symfony2, où se côtoient classes et namespaces :

core_drupal8

Extrait du coeur de Drupal 8

 

Un CMS orienté RestFull

A la dernière session de Drupagora, nous avons appris que Drupal 8 se dirigeait vers une architecture orientée services. De multiples micro-services sont coordonnés par Drupal 8 (qui se concentre sur la gestion du contenu, du backoffice), et cette architecture est un atout pour découpler les fonctionnalités, réparties entre différentes librairies. C'est également un atout pour exposer proprement une multitude de webservices REST.

En effet, dans l'optique d'être mis en relation avec différentes applications mobiles en tant que centre d'administration et de distribution des données, Drupal a changé de paradigme : au lieu de renvoyer une page HTML lors d'une requête, il peut renvoyer des données via l'API REST intégrée. Cela permet d'utiliser Drupal pour  la gestion du backoffice et de permettre aux applications mobiles de récupérer les données entrées dans l'application. L'affichage des données et leur gestion sont donc découplés, répartis entre les différentes applications et Drupal, qui centralise et gère les données.

Conséquence logique des multiples sollicitations dont il risque de faire l'objet, D8 semble voué à fonctionner également en NoSQL (notamment avec MongoDB, qu'il gère nativement). Cela permettra également d'augmenter les performances des sites à fort trafic (notamment lorsque les utilisateurs sont authentifiés et ont donc du contenu personnalisé).

Conclusion

En définitive, la réécriture quasi-complète du cœur de Drupal, l'intégration de librairies externes et l'utilisation de bonnes pratiques est un changement majeur pour les développeurs habitués à Drupal 7 et n'ayant pas l'habitude de la structuration de code proposée par les frameworks PHP. Au point qu’un fork de Drupal 7, nommé Backdrop CMS, a été créé afin de conserver l'esprit de la version antérieure de Drupal.

En clair, les développeurs D8 devront hausser leur niveau technique (dans des domaines tels que la POO, l'architecture, les tests unitaires...) : c’est la fin de l’amateurisme pour ce CMF, et cette montée en compétence nécessaire devrait augmenter la qualité de code des sites Drupal, garante d'un faible nombre de bugs lors des recettes client et d'une maintenabilité à moindre coût.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.