Comme certains le savent déjà, ça 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 ne 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é logiciel. A donc été introduit 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éries 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", c'est montée. Elle s'est rapidement équipée d'outils modernes notamment UTS (Usability Testing Suite), une suite d'outil permettant 'audit et d'analyse 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 ainsi créer 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 pour aucune version de Drupal n'a subit une telle déferlante de patch ergonomiques. Et pour se donner une idée des premier 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 liftig avec un liste déroulante qui modifie dynamiquement l'aide associée. Il parait 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.

Cette évolution va aussi donner le jour à un autre gros morceau, l'intégration de WYSIWYF dans le coeur de drupal. Un éditeur visuel en standard dans Drupal, c'est plutôt une bonne nouvelle même si pour l'instant, rien n'est visible dans les version UNSTABLE que j'ai testée.

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

Du côté de l'utilisabilité de l'administration, de petite 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 c'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 devrait ê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 changeais 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'onglet 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, on 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 disparaît 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é 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 soient prise en compte. Avec une transaction, si ça casse en court de route, tout ce qui c'est passé depuis le début de la transaction est automatiquement annulé. La transaction est en quelque sorte vue comme une meta-requêtes, qui permet en outre une bien meilleur gestion de la redondance pour les drupals à haut 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 manu. Et il faut dire à ma décharge que cette première expérience c'est fait avec Drupal 5 et que pour cette mouture, 12 champs custom impliquent 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 coeur 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. En et effet cela se confirme à l'usage avec une activation des modules de gestion des champs dans le coeur 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, y'a deux trois trucs qui choquent, comme 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 noeuds, mais s'étends maintenant au profile de l'utilisateur. On commence ici à apercevoir le mirage du fameux DataAPI dont on cause réguliérement, offrant enfin l'unification entre noeuds, 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 en 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écessaire 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).

En vrac

Pour terminer, les nouvelles choses en vrac que je n'ai pas encore pu voir de mes yeux mais qui doivent être incluse, ou qui le sont déjà mais que je n'ai pas réussi à trouver :

• Intégration d'ImageCache dans le coeur 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.) que le calamiteux machin fournit en standard. Ceci passera par la séparation en trois ensemble 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 ainsi de permettre ce fait le module deploy.
• Amélioration du système de mise à jour avec peut-être l'intégration du module Plugin Manager.
• Amélioration de l'architecture et des performances du systéme "Node Access".
• La possibilité d'utiliser d'autres framework JavaScript que jQuery.

Conclusion

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