Drupal 7 : le tour des nouveautés

Alors qu’une version alpha 7 de Drupal 7 vient de sortir, il est temps de se pencher sur les nouveautés qu’apporte cette version.

Changements pour les utilisateurs finaux

Des petits détails d’ergonomie générale ont été améliorés sur Drupal 7 : la vérification du niveau de sécurité du mot de passe lors de l’inscription, le choix du format d’entrée d’un texte, la suppression des longs fieldsets repliables au profit d’onglets verticaux, le fait de cocher automatiquement certains droits (par héritage) dans la liste des droits d’accès, la page d’accueil par défaut, un profil minimal d’installation (mais avouons le, ce n’est pas encore au niveau du site de démo d’eZ Publish).

Mais le plus gros point pour l’interface est le projet D7UX qui refond entièrement le back-office. Tout est regroupé en contexte d’utilisation :

• Je veux gérer du contenu (orange)
• Je suis en train de construire le site (bleu)
• Je change l’apparence de mon site (rose)
• Je gère les personnes venant sur mon site (vert)
• Je configure des modules et des paramètres (gris)

Illustration dans Drupal 5 et 6

Dans Drupal 7

Et pour faciliter le tout, une barre d’outil regroupant les liens les plus utiles en fonction du rôle utilisateur, vient s’ajouter en haut du site.

Enfin, un nouveau thème d’administration « seven », des overlays (style lightbox), et l’édition « in-place », seront présent.

Ce nouveau thème, ainsi qu’un simili éditeur in-place, et la nouvelle barre d’outils sont disponibles pour Drupal 6 en ajoutant le module « admin ».

Changements pour les administrateurs

• Nouveau minimum requis : PHP 5.2, MySQL 5.0 ou PostgreSQL 8.3.
• Meilleur support des zones horaires, meilleure gestion de la suppression des utilisateurs.
• Nouvelle interface d’internationalisation, gestion des langues pour la recherche, et les traductions peuvent varier en fonction du contexte de visualisation.
• Support natif des images. Les modules imageAPI, imagecache, et filefield on était intégré au cœur. Donc il y aura donc une vraie « médiathèque », avec création de miniatures à la volée.
• Au niveau de la sécurité :
• * le module PHP filter a été revu
• * le fichier cron.php lançant la tache cron requiert une clef dans l’URL
• * il y a, enfin, une permission pour lancer les mises à jour de base (ce qui veut dire qu’il va être possible d’avoir plusieurs super-admin).
• * Meilleure gestion du flood au login
• * Meilleur algorithme de hachage des mots de passe.

Au niveau du cœur, les modules Blog API, Ping, Throttle, et Uplaod sont supprimés. Les blocs peuvent être désactivés, et les règles d’accès sont supprimées (la partie qui permettait de dire qu’une certaine adresse IP ou un certain mail ne peut pas s’inscrire au site). Le paramétrage du nombre minimum de mots pour le body est supprimé, la sélection du thème spécifiquement par les utilisateurs est également supprimée du cœur.

La philosophie est de nettoyer le cœur, en enlevant les éléments qui auront une meilleure « dynamique » en tant que module.

Dans le sens inverse, les modules suivants ont été intégrés au cœur :

• admin role
• feed api
• fileField
• Image
• ImageAPI
• ImageCache
• ImageField
• Install profile API
• Plugin manager
• Poormanscron
• Token

Nous repalerons de certains de ces modules dans la section « pour les développeurs ».

Mais surtout la plus grosse nouveauté ajoutée au cœur est CCK ! En réalité, ce n’est pas uniquement CCK qui a été ajouté. Une nouvelle notion est introduite : les entités. Une entité est un objet générique, tout comme l’étaient les $node et les $user dans Drupal 6. Une entité possédera un contrôleur, ce sera du vrai PHP objet, et cela permettra d’ajouter des champs sur des entités.

Cette notion d’entité va totalement changer la façon dont nous allons concevoir un site Drupal (nous y reviendrons dans un futur billet).

Les types de champs disponibles sont :

• boolean
• décimal / float / integer
• fichier
• liste
• texte / textearea
• terme de taxonomie
• body

Body sera bien un champ, ce qui veut dire qu’un node ne sera maintenant plus qu’une agrégation de plusieurs champs. Un champ pourra non seulement s’appliquer à un node, mais aussi à un utilisateur (au revoir module Content Profile), à un commentaire, ou à des termes de taxonomie. En réalité, à toutes les entités (à noter que les blocs ne seront pas une entité).

Et tout ça est dans le cœur, mais d’autres types de champ pourront venir s’ajouter via des modules. Le module CCK existera toujours dans ce but là. Notamment pour rajouter node reference qui sera absent du cœur.

Changements pour les designers et les intégrateurs

• Les thèmes à base de design en tableau datant de Drupal 4 sont supprimés du cœur.
• Beaucoup d’éléments composant une page se retrouvent maintenant comme bloc ou région (le message d’aide, le contenu d’une page : $content de page.tpl.php, le footer message, sont des blocs par exemple)
• Une remise à niveau de tous les fichiers .tpl.php par défaut a été faite avec des noms de classes CSS et des identifiants plus sémantiques, une meilleure cohérence, etc.
• Un nouveau thème a été ajouté : Stark qui est un thème ultra minimaliste, avec rien, juste le minimum vital pour débuter un nouveau thème.

$content n’est plus une grande chaine de caractère contenant du xHTML. $content est maintenant un tableau des composants de la page, qui garde en mémoire ce qui a déjà été affiché. On peut ainsi via des fonctions hide(), et render() choisir ce que l’on veut afficher et où on veut l’afficher.

En plus de ça, les preprocess sont maintenant étendus aux fonctions theme() (et non plus qu’au fichier tpl.php). Et, maintenant qu’il y a des champs partout, le support du RDFa est disponible.

Au niveau du Javascript, passage de jQuery 1.2.6 à jQuery 1.4, et intégration de jQuery Forms 2.2, et jQuery UI 1.7. La nouvelle fonction drupal_add_library() permet d’ajouter des fichier javascript et css en rapport les uns avec les autres, et un nouveau framework AJAX a été intégré dans le cœur. La fonction drupal_add_js() a été améliorée, et l’API Javascript, souvent sous-exploitée, reste intacte.

Changement pour les développeurs

La plus grosse nouveauté vient de l’intégration de SimpleTest, ce qui va permettre de faire des tests unitaires et fonctionnels.

Ensuite, utilisation de PDO pour faire une abstraction de la base (support théorique de nombreux SGBD), et support des réplications maitres/esclave, des transactions, des insertions multiples, etc.

Au niveau du requêtage, il est possible de procéder de la même façon (ou presque) :
$node = db_query('SELECT nid, title FROM <em>node</em> WHERE type = :type AND nid = :nid', array(':type' => $type, ':nid' => $nid))->fetchObject() ;

mais il est aussi possible de faire des requêtes un peu plus dynamiques :
$select = db_select('node', 'n')
->fields('n', array('nid'))
->condition('promote', 1)
->condition('status', 1)
->orderBy('sticky', 'DESC')
->orderBy('created', 'DESC')
->extend('PagerDefault')
->limit(variable_get('default_nodes_main', 10))
->addTag('node_access') ;
(ce qui facilite grandement les hook_query_alter()).

Au niveau du Field API :

• Possibilité de déclarer n’importe des entités.
• Les données sont stockées par requête SQL, mais, potentiellement , ça pourrait être en appelant des webservices.

L’API de gestion des fichiers a été améliorée. Les fichiers sont des objets, nouveau hook : hook_file_load(), hook_file_save(), <code>hook_file_move(), etc. Plus besoin de gérer la table files, les fichiers sont gérés automatiquement.

Un nouveau hook permet le support du CDN avec hook_file_url_alter().
Au lieu de référencer les fichiers par chemin, référencement par URI :
schema://file/path/file.ext. ce qui permet de changer l’endroit où se situe un fichier sans avoir à faire de mise à jour de base. public://, private://, temp:// sont supportés nativement, mais des modules peuvent venir rajouter des s3://, filckr://, etc.

Pour la nouvelle Image API, les toolkits ne sont plus des fichiers à copier, mais des modules à part entière. Support natif des manipulations d’image (précédemment le module ImageCache).

Performance

• Ajout des multi-load(), exemple : node_load_multiple(), user_load_multiple(), etc.
• Support des proxy, et reverse-proxy
• Une multitude d’optimisations au travers de profiling avec XDebug a été faite.
• InnoDB devient la méthode de sauvegarde en base par défaut.
• Support du CDN pour les fichiers.

Hooks et APIs

Au revoir les variables $op, donc plus de hook_nodeapi(), hook_user(), hook_block(), au profit de hook plus spécifiques, ne faisant qu’une seule chose, avec des hook_node_load(), hook_node_update(), hook_user_register(), hook_user_login(), hook_block_list(), hook_block_view(), hook_form_FORM_ID_alter(), etc.

Un nouvel objet $page, et un nouveau hook hook_page_alter() ont également été introduits.

Nouvelles APIs en vrac : Roles/Permissions API, Filter/Format API, mécanisme de cache statique, Locking framework, Job Queue.

Par ailleurs, les « Node Access » ont été améliorés, alors que c’était une horreur d’y toucher dans Drupal 6.

Alors, concrètement c’est pour quand ?

Quand ce sera prêt ! C’est-à-dire quand la liste des bugs critiques sera à 0. Aujourd’hui elle est aux alentours des 20, et n’importe qui peut proposer une correction.

Il faut en plus de cela rajouter une période d’adaptation pour que tous les modules indispensables soient portés sur cette version. Un grand projet regroupé sous le nom de code de #D7CX a été lancé afin que cette adaptation soit commencée au plus vite. Des modules comme Views, Webform, seront, si tout va bien, disponibles dès la sortie de Drupal 7. Mais il faudra que les développeurs et intégrateurs apprennent ce nouvel outil, car les changements sont tout de même importants.