Compte rendu : Drink & Drupal Toulouse décembre 2013

Hier soir, j’ai fait une présentation de Drupal Commons 3.5 lors du Drink & Drupal à la cantine à Toulouse.

Je mettrais les slides en ligne bientôt.

DrinknDrupal1

Ambiance très sympa.

Nous en avons profité pour faire un petit test rapide de « talky.io« , une plateforme dont le code est en partie Open Source de webconférence basée sur WebRTC.

C’était assez fun de passer en webcam alors qu’on était tous dans la même pièce. Ceci dit, tout le monde a été d’accord sur l’intérêt d’intégrer cette technologie (ou une autre telle que Google Hangout – avec l’avantage que la session se retrouve archivée pour le public) lors des prochaines présentations, de sorte que d’autres puissent être de la partie, même s’ils sont loin ou indisponibles.

Nous en avons profité pour faire un point de fin d’année et voir comment organiser l’année qui arrive. Il a été retenu notamment de prévoir les conférences plus en amont, sur un calendrier glissant de 3 mois, et d’être plus présent sur drupalfr (notamment d’y poster nos présentations).

Méthodologie d’audit d’un site Drupal

Éléments à fournir pour l’audit du code :

  • fichiers sources du site

  • base de données du site

  • documentation fonctionnelle et technique

Démarche suivie :

Afin d’obtenir une vue d’ensemble du site, les étapes suivantes ont été observées :

  1. Recherche de la présence d’erreurs critiques remontées par les différents logs.

  2. Étude des modules coeur et contributeurs activés, recherche de hacks dans leurs fichiers.

  3. Examen du code des modules développés spécifiquement

  4. Examen du theme du site

Détails des contrôles effectués lors de ces étapes :

  • contrôle du rapport général de Drupal

  • contrôle du watchdog de Drupal

  • différentiel entre les fichiers du coeur de Drupal et le coeur du site à versions égales (annexe diff-modules-core)

  • différentiel entre les fichiers des modules contributeurs de Drupal et ceux du site à versions égales (annexe diff-modules-contrib)

  • utilisation du module drupal « hacked » pour recouper les informations avec les résultats des différentiels (voir annexe rapport-hacked)

  • examen des hacks détectés par les différentiels et de leur impact sur le site

  • vérification des modules activés et non-activés (voir stats)

  • vérification manuelle du code custom, combiné avec une vérification avec le module « coder »

  • examen du theme du site (voir annexe templates-pages)

En cas de mauvaises pratiques http://drupal.org/best-practices/do-not-hack-core il faut en évaluer les implications.

Notez qu’en cas de modification du cœur de Drupal ou d’un module cela va entraîner des difficultés lors de mises à jour de sécurités (qui vont écraser ces moficiations). Il est donc important de les repérer en amont.

Il faut éventuellement prévoir une campagne de revue du code et de conversion en hook_xxx_alter qui sont prévus pour éviter ce genre de situation. De manière pro-active il est conseillé de faire suivre à ses développeurs une formation, ou une micro-formation à distance, pour s’assurer qu’ils connaissent les bonnes pratiques, ou bien de faire valider les compétences du prestataire en charge du développement par un expert pour éviter ce genre de déboires à l’avenir.

Les problèmes détectés pendant l’audit sera classifiés de la manière suivante :

  • Problème : Description du problème.
  • Importance : critique, haute, moyenne
  • Type : sécurité, maintenabilité, évolutivité
  • Conséquences : description des conséquences selon le problème rencontré, les impacts pour les développeurs, les utilisateurs, les chefs de projets, et les clients
  • Solution : quelles actions mettre en œuvre pour corriger, les plus simplement possible le problème
  • Source : référence vers la documentation correspondante, le cas échéant

Evolution de la complexité cyclomatique de Drupal 4 à 8

Voici les données brutes, l’analyse viendra plus tard.

Je les aies obtenues avec la commande suivante (en paramètre je passe le n° de version de Drupal :

phploc "drupal$1" --log-csv="~/drupal-analisys/d$1loc3.csv" --names="*.php,*.inc,*.module,*.yml"
Drupal 4 Drupal 5 Drupal 6 Drupal 7 Drupal 8
Directories 7 37 40 88 1 474
Files 73 83 179 382 6 025
Lines of Code (LOC) 39 397 46 223 71 710 207 763 812 817
Cyclomatic Complexity / Lines of Code 0,45 0,45 0,46 0,42 0,22
Comment Lines of Code (CLOC) 9 261 11 631 22 255 70 845 278 700
Non-Comment Lines of Code (NCLOC) 30 136 34 592 49 455 136 918 534 117
Logical Lines of Code (LLOC) 10 808 12 112 17 086 33 566 174 481
Namespaces 0 0 0 3 1 110
Interfaces 0 0 0 16 498
Traits 0 0 0 0 10
Classes 0 0 1 110 5 223
Abstract Classes 0 0 0 10 340
Concrete Classes 0 0 1 100 4 883
Average Class Length (LLOC) 0,00 0,00 57,00 40,04 26,33
Methods 0 0 4 1 042 28 246
Non-Static Methods 0 0 4 993 25 711
Static Methods 0 0 0 49 2 535
Public Methods 0 0 4 797 22 438
Non-Public Methods 0 0 0 245 5 808
Average Method Length (LLOC) 0,00 0,00 14,25 4,23 4,87
Cyclomatic Complexity / Number of Methods 0,00 0,00 5,25 2,64 2,06
Functions 1 337 1 468 2 024 4 211 3 957
Named Functions 1 337 1 468 2 024 4 211 3 568
Anonymous Functions 0 0 0 0 389
Constants 91 110 165 267 837
Global Constants 91 110 165 258 71
Class Constants 0 0 0 9 766
Attribute Accesses 2 617 2 905 3 849 7 361 50 386
Non-Static Attribute Accesses 2 617 2 905 3 849 7 294 49 357
Static Attribute Accesses 0 0 0 67 1 029
Method Calls 1 0 1 6 795 103 543
Non-Static Method Calls 1 0 1 6 636 95 186
Static Method Calls 0 0 0 159 8 357
Global Accesses 1 067 1 183 1 483 2 846 1 481
Global Variable Accesses 263 222 252 355 447
Super-Global Variable Accesses 230 229 277 426 294
Global Constant Accesses 574 732 954 2 065 740
Test Classes 0 0 0 0 0
Test Methods 0 0 0 0 0

Quelle version de Drupal est supportée + gestion de la compatibilité ascendante ?

Pour un DSI, un site se gère sur la longueur. Il doit minimiser le fardeau de la maintenance et des évolutions tout en assurant sa pérennité maximale.

Deux problématiques principaux se posent à lui par rapport au cycle de vie du produit qu’il à choisi : les corrections de bug et les mises à jour de sécurité d’une part et la gestion de la compatibilité ascendante d’autre part.

Pour Drupal la politique est la suivante. Les  nouvelles releases sont numérotés par 2 chiffres : une version majeure, et une version mineure. Par exemple actuellement nous sommes en Drupal 7.24

  • les changements de version majeure brisent la compatibilité ascendante mais permettent des évolutions fonctionnelles et d’API majeures. Si on veut monter en version il faut donc le prévoir en amont.
  • les changements de version mineures apportent surtout des corrections de bugs, des patch de sécurités, et des évolutions mineurs, mais surtout, ne brisent pas la compatibilité ascendante. On peut donc (et c’est même recommandé pour des questions de sécurité) faire ces mise à jour « les yeux fermés » (idéalement, car dans la pratique il faut quand même prendre des précautions élémentaires).
  • La communauté supporte la version n-1. C’est à dire que Drupal 6 ne sera supporté que jusqu’à la sortie de Drupal 8.

Mais les difficultés de développement de Drupal 8, ainsi que l’évolution rapide de web imposent de revoir cette politique. Même si ce n’est pas encore définitif, il semble que la communauté Drupal s’achemine vers une nouvelle manière de gérer le cycle de vie de Drupal, dite, « release sémantique« .

De quoi s’agit-il ?

  • Les évolutions « mineures » (celles qui ne brisent pas ou très peu la compatibilité ascendante) de Drupal se feront selon un cycle de 6 mois, afin de pouvoir intégrer plus rapidement les nouveautés dans le cœur.
  • Les évolutions « majeures » (celles qui brisent la compatibilité ascendante) disposeront d’un support LTS assuré en version n-1 pour les correction de bugs et en version n-2 pour les patchs de sécurité, mais uniquement à partir de la dernière évolution mineure.

Dans la pratique cela devrait permettre un cycle de vie d’un site d’environ 5 ans avec une fenêtre d’un peu plus d’un an pour faire évoluer son site en version n+2. Ce qui semble assez raisonnable comme compromis.

Les montées en version de Drupal ne sont pas sans poser de problèmes. Il y a 4 aspects à considérer :

  • le coeur de Drupal en principe dispose d’un « chemin d’upgrade » qui fait évoluer la base de donnée afin que le site soit toujours fonctionnel
  • les thèmes (l’habillage) est à revoir en grande partie. D’une part parce que les API changent, d’autre part pour s’adapter aux nouveaux standards du web en la matière.
  • pour les modules communautaires, c’est au cas par cas. Les plus populaires disposent en général d’un chemin d’upgrade comme le coeur de Drupal, mais c’est loin d’être une règle générale. Il faut donc s’attendre devoir faire évoluer les données en base soi même, avec des requêtes SQL.
  • reste ensuite le code custum. Plus il sera important en proportion, plus l’opération sera lourde et risquée.

Le cas de Drupal 8 est la encore différent. Il n’y aura pas de « chemin d’upgrade » depuis Drupal 7 car les architectures sont trop différentes. Pour l’instant, il semble que le choix se porte sur le module « Migrate » qui aura en charge d’aspirer les données des anciens sites. Mais ce module n’est pas magique et demande un certain travail de configuration / développement. C’est un choix stratégique qui, même s’il pénalise un peu les usager de Drupal, pourrait permettre de convertir plus facilement des sites non Drupal (WordPress, Typo3, phpBB) et d’attirer encore plus de monde vers Drupal.

Drupal, histoire et part de marchés

Quelques dates clés :

  • 1999 : Dries Buytaert commence à travailler sur ce qui deviendra Drupal.
  • 2001 : C’est en janvier 2001 que le site Drupal.org est mis en ligne et que le code de Drupal est mis à disposition.
  • 2005 : avec la version 4.5, Drupal commence à faire effet boule de neige et à attirer de plus en plus de monde dans sa communauté (multiplication des conférences et sprints de code).
  • 2008 : Drupal commence à s’imposer en entreprise avec sa version 6 grâce la réputation de son code « developer friendly » et grâce à ses awards en tant que meilleur CMS.
  • 2011 : Drupal 7, sorti en 2011 signe la consécration en tant que leader des CMS d’entreprise Open Source.

Actuellement Drupal, WordPress et Joomla sont les 3 leaders pour la conception des sites web mais ne s’adressent pas au même  segments de marchés :

  • WordPress détient la plus grosse part de marché des CMS avec presque 60% (soit 20% des sites web en général). Mais il s’adresse principalement aux blogueurs.
  • Joomla, qui est orienté petites communautés / associations détient 9% des parts de marchés des CMS et pèse 3.2% des sites web.
  • Drupal, leader en entreprise représente 5.6% des part de marchés des CMS pour 1.9% des sites web.

Mais alors que Joomla est en perte de vitesse, la croissance annuelle de Drupal est 2X plus rapide que celle de WordPress, grâce au charisme de son leader et au dynamisme de sa communauté, entre autre.

Drupal est utilisé par des sites prestigieux : Twitter, Maison Blanche, NASA, MTV, portail du gouvernement, France culture, Rue89, le Figaro, etc…

Au sein de Drupal lui même plus de 50 % des sites sont en version 7, le reste étant du Drupal 6 (43.5%), Drupal 5 étant marginal (3.5%).

Comparatif Drupal 7 et 8 : page hello world

Voici les différences entre un module « hello world » le plus simple possible, entre Drupal 7 (code source) et Drupal 8 (code source).

Drupal 7 Drupal 8
hello.info hello.info.yml 
name = Hello world
description = Minimanlist Hello World in Drupal 7
package = helloworld
core = 7.x
files[] = hello.module
 
name: Hello World module
type: module
description: An Hello World module showing D8 capabilites
package: Example modules
core: 8.x
hello.module hello.module 
<?php

function hello_menu() {

  $items = array(
      'hello_world' => array(
        'title' => 'Hello world',
        'page callback' => '_page_hello_world',
        'access callback' => TRUE,
      ),
    );

  return $items;
}

function _page_hello_world() {
  return array(    '#markup' => '<p>Hello world page text (from module) !</p>' );
}
 
<?php
function hello_menu() {
  $items['hello'] = array(
    'title' => 'Hello Page',
    'route_name' => 'hello.world',
  );
  return $items;
}
 hello.routing.yml 
# hello.routing.yml
hello.world:
  path: 'helloworld'
  defaults:
    _content: '\Drupal\hello\HelloRouteController::index'
  requirements:
    _permission: 'access content'
 /lib/Drupal/hello/HelloRouteController.php 
<?php

namespace Drupal\hello;

class HelloRouteController {

  public function index() {
    return array('#markup' => 'Hello workd page text (from controller) !');
  }

}

Comme on peut le voir, le .info est convertit en fichier YAML .info.yml. Pas de grosses différences à ce stade.

Par contre le .module est éclaté en 3 parties. Le hook_menu persiste mais est scindé en 2. Le routing se fait maintenant dans un fichier .routing.yml. Il ne reste plus que la définition du titre du menu dans le module. La callback est quand à elle transformée en controller. En effet, le système de menu de Drupal 7 est remplacé par le routing Symfony2. C’est plus compliqué à écrire, mais c’est aussi plus puissant.