Comme certains le savent déjà, cela fait quelques mois que je travaille (peiner serait sans doute plus juste) à la rédaction d'un livre sur Drupal. Or dernièrement Eyrolles m'a demandé d'y rajouter une ouverture sur Drupal 7. Comme il s'agit plus là d'actualité, je me suis dit qu'il serait pas mal d'en faire profiter tout le monde, histoire d'avoir une idée plus claire de ce à quoi va ressembler Drupal "Seven" (c'est le mot à la mode en ce moment).

Attention, versions INSTABLES

Si si, c'est une nouveauté car avant tout Drupal commence à rentrer dans le rang avec les bonnes pratiques classiques en matière de qualité logicielle. A donc été introduite une véritable suite de tests fonctionnels et unitaires. L'objectif est de pouvoir prouver la qualité du code à tout moment et ainsi réduire le temps de déverminage. Résultat, on arrête de balancer un nouveau Drupal après un long effet tunnel et on opte pour des sorties régulières de version instables et testables. Chaque sortie est documentée en expliquant le plus clairement possible ce qu'elle apporte pour l'utilisateur, l'administrateur, le développeur, le traducteur ou le thèmeur (les 5 grandes groupes dans la confrérie Drupalienne).

L'utilisabilité

L'utilisabilité va être un peu le maître mot de cette nouvelle version avec un objectif inavoué : dégommer l'idée reçue comme quoi Joomla, le concurrent directe et honni, serait plus facile d'accès que Drupal.

Pour s'atteler à cette tâche, une véritable petite équipe, la "Usability Team", a été montée. Elle s'est rapidement équipée d'outils modernes notamment UTS (Usability Testing Suite), une suite d'outil permettant d'auditer et d'analyser des comportements et des usages, assez proche de ce que l'on peut trouver chez MS avec l'équipe qui travaille sur Office. Le but est de collecter un maximum d'informations sur les usages de Drupal et de créer ainsi une dynamique d'amélioration continue de l'ergonomie. S'ils pouvaient faire aussi une petite session sur le panneau de configuration des blocs, ce ne serait pas un luxe...

Premiers résultats concrets : jamais aucune version de Drupal n'a subi une telle déferlante de patchs ergonomiques. Et pour se donner une idée des premiers résultats visibles, en voici quelques exemples :

Voici à quoi ressemblera le remplaçant de l'abominable système de zones dépliables utilisé avec Drupal 6 pour éditer/modifier un contenu, plutôt sympa non ? Même sur un écran d'une résolution modeste, l'ensemble peut ainsi tenir sur deux "pages".

Les formats d'entrées (renommés "Text format" ou format de textes, ce qui est beaucoup plus logique) ont aussi pris un coup de lifting avec une liste déroulante qui modifie dynamiquement l'aide associée. Il paraît que la dite aide s'escamote lorsque l'on est sur d'autre zones que l'édition du corps, mais je n'ai pas pu le vérifier.

Pour conclure sur les améliorations ergonomiques, notons l'inclusion en standard d'Advanced Help disponible par le point d'interrogation sur fond bleu présent un peu partout dans le produit.

Du côté de l'utilisabilité de l'administration, de petites choses sont apparues mais c'est encore timide :

• Date and Time est devenu Regional Settings avec au passage la disparition des onglets.
• Le tentaculaire menu Administrer s'est paré d'une nouvelle entrée Internaltional regroupant gestion des langues et des traductions (mais pas Regional settings, bizarre...).
• La gestion du thème d'administration a enfin rejoint le giron du panneau d'administration des thèmes.
• La gestion des pages 403/404 déplacées dans le panneau Site Information.
• Un nouveau panneau Configuration du site/Updates pour être prévenu par courriel lorsque le site a besoin d'un coup de fraîcheur.
• Une aide supplémentaire sous chaque permission, bien pratique. De même les permissions devraient être enfin correctement traductibles.
• La possibilité de définir quel utilisateur est l'administrateur du site. Je n'ai pas regardé de près si cela changeait l'UID du dit utilisateur, ce dont je doute. Mais si ce n'est pas le cas, y'a beaucoup de code qui va casser là dessus...
• Le système d'onglets verticaux pour les modèles de courriels pour les créations de compte, très sympa.

Database API

Il y a longtemps qu'on en rêvait, surtout pour ceux qui, comme moi, ont vécu une partie de leur vie dans le bain Java. Drupal 7 utilise maintenant la couche d'abstraction d'accès à la base de données PDO (PHP DataBase Object). A l'instar de JDBC ou dans une moindre mesure ODBC, cette couche permet de s'affranchir des spécificités de connexion aux bases et ainsi permettre :

• Une ouverture à de nouvelles bases de données comme Oracle ou MSSQL (beurk, oui, je sais), qui sont très largement utilisés en entreprise et dont l'absence bloquait l'adoption de Drupal. Attention, PDO n'abstrait pas la base de données mais juste les connexions et une partie des fonctionnalités, les requêtes en elles-mêmes restent spécifique et à ce titre SchemaAPI ne disparaissent donc pas. Mais peut-être cela va t-il enfin casser l'hégémonie de MySQL sur Drupal.
• Le support des transactions pour les modules qui souhaitent l'utiliser. Rien que cela, ça va être une sacrée révolution pour l'utilisation de Drupal dans un environnement professionnel où l'intégrité des données est importante. Pour ceux qui ne connaissent pas les transactions, il s'agit de gérer le cas où 20 INSERT/UPDATE/DELETE sont envoyées à la base, que la connexion tombe à la 10iéme et que la moité des modifications seulement soit prise en compte. Avec une transaction, si ça casse en cours de route, tout ce qui s'est passé depuis le début de la transaction est automatiquement annulé. La transaction est en quelque sorte vue comme une méta-requête, qui permet en outre une bien meilleure gestion de la redondance pour les Drupals à haute disponibilité.
• Justement, l'utilisation de PDO va enfin permettre l'exploitation d'architecture SGBD en cluster type maître-esclave sans avoir à triturer le code de Drupal. Ce problème est moins critique en D6 qu'en D5 de par l'introduction des séquences mais reste malgré tout un problème.
• Enfin, mais cela reste à tester, PDO est censé être plus performant.

FieldAPI

Lorsque j'ai utilisé CCK la première fois, ma réaction fut "mon dieu, mais quelle horreur !!!". Pour un dev de base, ce module là fait un peu flipper, habitué que l'on est à gérer ses petites ta-tables à la mano. Et il faut dire à ma décharge que cette première expérience s'est faite avec Drupal 5 et que pour cette mouture, 12 champs custom impliquaient 12 requêtes d'insertion dans la MÊME table. Avec D6, force est d'avouer que c'est beaucoup, mais alors beaucoup mieux, et je suis devenu un peu plus en paix avec ce module.

Mais pour Drupal 7, CCK disparaît, ou plutôt va être coupé en deux. D'un côté nous aurons le nouveau FieldAPI, intégré au cœur de Drupal et incluant toute la logique interne des champs CCK dans une version ré-écrite pour booster les performances et les usages. De l'autre le module CCK qui ne sera plus que l'interface graphique de FieldAPI. Et en effet cela se confirme à l'usage avec une activation des modules de gestion des champs dans le cœur de Drupal, et le besoin d'ajouter la dev de CCK pour D7 lorsqu'il s'agit de gérer les champs et l'affichage.

Une fois les uns activés et les autres installés, la différence n'est pas flagrante avec un D6+CCK, mais en regardant de plus près, il y a deux trois trucs qui choquent, par exemple les champs natifs des nodes (titre, taxo) qui apparaissent non-grisés comme des champs CCK standards. Mais le plus fort vous tombe dessus en arrivant dans la page d'édition des propriétés utilisateurs. Comme vous le voyez sur la copie d'écran, CCKFieldAPI ne se limite plus aux seuls contenus, ou plutôt aux seuls nœuds, mais s'étend maintenant au profil de l'utilisateur. On commence ici à apercevoir le mirage du fameux DataAPI dont on cause régulièrement, offrant enfin l'unification entre nœuds, utilisateurs, taxonomie et commentaires.

Les avantages de prévus de FieldAPI sont :

• Amélioration sensible des performances par rapport à CCK.
• Extension de FieldAPI à l'ensemble des champs de contenus.
• Unification de tous les contenus (commentaires, noeuds, etc) sous une même bannière.
• Permettre une meilleur intégration avec le module Views qui lui aussi, risque de finir en petits bouts dans le core de Drupal. Pour le coup, je serais heureux que l'interface graphique reste dehors...

Amélioration des performances

Comparé à la transition D5/D6, les performances ne sont pas l'objectif premier de Drupal 7. Cependant il y a un gros morceau en train d'émerger sous le doux nom de "Function Registry". Le principe est simple : chaque module déclare les fichiers qu'il utilise et Drupal les analyse pour en extrait une base de données de fonctions et de dépendances. Ceci fait, ne sont chargés lors de la construction des pages que les fichiers PHP nécessaires et utiles. C'est le principe même de la modification de MenuAPI et ThemeAPI (association d'un menu avec un fichier PHP contenant son handler) mais étendu dynamiquement à tout le code. Le résultat est la réduction au maximum du temps de démarrage de Drupal (bootstrap).

Les hypothétiques

Pour terminer, les nouvelles choses en vrac que je n'ai pas encore pu voir de mes yeux mais qui ont été évoquées ici et là, ou qui le sont déjà mais que je n'ai pas réussi à trouver :

• Intégration d'ImageCache dans le cœur de Drupal. Ca c'est une bonne nouvelle tant ce module est utile.
• Amélioration de la recherche. Le principe est d'ouvrir la recherche à d'autres moteurs (Apache Solr, Xapian, etc.) plutôt que de se contenter du calamiteux machin fourni en standard. Ceci passera par la séparation en trois ensembles du système existant : le crawler, l'indexer et l'interface de recherche.
• Amélioration des fonctionnalités d'import/export pour répondre à un des plus graves problèmes de Drupal : la difficulté de suivre un cycle Développement/Intégration/Production. En effet, déployer de nouvelles fonctionnalités d'un serveur à l'autre est aujourd'hui un véritable enfer à moitié insoluble. L'objectif est donc de fournir un service équivalent à ce que permet le fameux module deploy (ou alors inclure celui-ci dans le core lorsqu'il sera sec ?).
• Amélioration du système de mise à jour avec peut-être l'intégration du module Plugin Manager

Conclusion

Voilà, fin du petit tour d'horizon de l'ami Drupal le 7^ième. Bien sûr, tout ceci est encore amené à évoluer et je changerais ces lignes à chaque fois que ce sera nécessaire.