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 :
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
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.
Les avantages de prévus de FieldAPI sont :
FieldAPI
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.
Amélioration sensible des performances par rapport à CCK.
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. - Amélioration de l'architecture et des performances du systéme "Node Access".
- La possibilité d'utiliser d'autres framework JavaScript que jQuery.
- Intégration de WYSIWYG dans le cœur de drupal.
Conclusion
Voilà, fin du petit tour d'horizon de l'ami Drupal le 7ième. Bien sûr, tout ceci est encore amené à évoluer et je changerais ces lignes à chaque fois que ce sera nécessaire.
Eh beh ça promet :)
Merci pour cette description qui laisse présager que de bonnes choses :)
Enfin un état des lieux concret et pertinent de ce qui nous attend avec Drupal 7.
Merci ! :-)
Merci pour ce partage de l'information ;)
Bon article de synthèse.
Mais concernant WYSIWYG API il n'y aura pas d'éditeur directement intégré. Ça reprend la philosophie de Drupal : donner la possibilité, mais laisser le choix. Tout sera standardisé pour l'intégration d'un éditeur riche (il suffira de décompresser l'éditeur dans un dossier pour qu'il soit disponible), mais il n'y aura pas par défaut d'éditeur riche.
Yep je suis d'accord, comme le module WYSIWYG d'ailleurs. Ceci dit, j'ai lu des discussions sur l'introduction d'un éditeur par défaut qui serait une création maison, histoire de pas laisser l'API totalement "à poil".
Quelques précisions:
- En effet, il ne faut pas s'attendre à du WYSIWYG dans le core D7.
Au grand mieux, de l'aide à la saisie à la BUEditor, mais ça reste très hypothétique.
- Pas d'advanced help pour l'instant non plus. Un gros boulot a été fait, mais le patch est pour le moment bloqué sur des considérations techniques, et rien n'indique que ça va se débloquer.
- Le gros point en plus de la Field API n'est pas vraiment en termes de performances, mais plutôt de flexibilité: champs sur users, termes de taxonomie, sur autres 'entités' contrib..., champs non locaux (Flickr, repositories distants...) et d'unification: traiter le champ 'body' comme un 'field', à terme la taxonomie, les fichiers attachés, etc etc (sans doute pas tout pour D7)
- Pas à ma connaissance de travail en cours sur "module deploy dans le core"
en revanche, gros boulot en cours sur de l'update de module directement dans l'interface.
Hum, à voir ton profile sur drupal.org, tu sembles savoir de quoi tu parles pour FieldAPI :-)
Pour ce qui est des performances, j'avoue être quelque peu sensible sur le sujet, surtout par rapport à CCK, une intégration plus proche du core devrais j'imagine aide. Mais sur le fond tu as raison, la souplesse reste le premier point.
Pour ce qui est de deploy, je me basais sur cette présentation : http://drupalcampmontreal.com/node/13.
Ban, je vais faire un chapitre "hypothétique" aux lumières de vos commentaires, merci :)
Bonjour Yoran,
À quand ce fameux livre Drupal 6 / 7 ? ;)
Merci de la précision.
Bonjour :)
J'ai filé le manuscrit à Eyrolles la semaine dernière et j'attends leurs premiers retours. Si tout va bien, il devrait être ok pour une sortie en mi-Août/début septembre.
En fait, j'ai pas très envie qu'il soit estampillé "Drupal 6", j'aimerais bien juste "Drupal" car au fond, des choses changent d'une version à l'autre mais j'ai tendance à trouver le défilé des versions sur ce genre de livre pas très rentable pour le lecteur (genre j'ai acheté Drupal 6, Zut, voilà qu'il faut que je prenne celui pour Drupal 7..).
Après, cela n'empêchera pas d'avoir, si le livre fonctionne des mises à jour/nouvelles versions. Enfin bon, faut déjà qu'il sorte, y'a encore du chemin ;-)
Bonjour et merci pour cette analyse.
J'adore Drupal mais je suis un end-user ou presque et cela me désespère que les fonctionnalités pour faciliter la vie ne sont pas présentes, comme une mise à jour automatique des modules (seuls les tech savent faire du tar.gz upload etc), le WISIWIG
Longue vie à Drupal néanmoins
Merci bien pour cette analyse :)
Ca va venir :) Pour l'instant, je te conseille de teste ce module : http://drupal.org/project/plugin_manager
Il va te permettre d'installer/désinstaller/mettre à jour tes modules directement par l'interface sans avoir à utiliser de commandes supplémentaires.
bonjour et merci pour vos articles, vraiment sympa !
est-ce qu'une publication du sommaire de votre livre est prévue dans les parages svp ?
Heu.... JoOmla est effectivement plus accessible que drupal ca c'est une évidence ! et bien des développeurs vous le diront. Bien sur si on veut tout simplement se faire un ti blog ou site qui paye pas de mine on prend drupal et on l'install direct avec quelques modules et on écrit. Mais voilà la geule du site et son ergonomie semblable à beaucoup d'autres.
Et ca n'est pas ce que n'importe quel utilisateur veux. Joomla est sans conteste plus accessible que drupal ainsi que la manipulation et la création de module y a pas photo. Donc arretez un peu de faire les avocats du diable. Ca n'est pas parcequ'on dit qu'un cms concurrent va être mieux sur certains points que tout de suite il faut se braquer et essayer de convaincre en porte à faux des utilisateurs.
Ce qui ne veux pas dire que drupal n'est pas puissant donc ne confondez pas messieurs sur quel terrain vous vous aventurez.
Rien que l'aspect création de mobule est bien plus simple sous joomla. Je travail avec plusieurs cms tel que spip, joomla, drupal, cmsms, typolight, wordpress ainsi que les cms e-commerce pour certaines demande et pour des projets plus particulier je travail sous framework symfony ou des fois zend. Tout ca pour vous dire que c'est avec drupal que l'on a plus de problème afin d'élaborer un projet avec ce dernier.
Bien sûr, on pourrait se concentrer que sur drupal... mais il faut s'adapter à la demande et non l'inverse, surtout lorsque drupal n'a pas forcément une valeur ajouté à l'inverse de zend & co.
Question de point de vue et surtout question de taille de projet. Je vois mal un mediapart, ou un rue89 sous Joomla. De même que je vois mal les projets faits sous Joomla utiliant un wordpress (je m'arrête là, c'est les trois seuls que je connais ;-). Maintenant il ne faut pas tout confondre, entre chercher à "rendre aussi accessible" que, et "comparer à".
Maintenant cela doit être une histoire de structuration mentale car je n'ai personellement pas trouvé que Joomla était plus accessible de Drupal. Maintenant je ne trouve pas non plus Windows plus accessible que Linux, comme quoi cela doit être une question qui donne des réponses bien personnelles.
PS: Je n'aime pas bien que l'on reste anonyme dans ce type de discussion, a bon entendeur pour une éventuelle suite.
Oui, le sommaire est disponible ici
j'ai fait plusieurs sites commerciaux sous joomla et drupal, et trouve que chacun a ses avantages et ses inconvénients...
pour un site "vite fait" dont on est sûr que le design n'évoluera pas (sauf développement ultérieur) et dont les diverses fonctionnalités n'ont pas beaucoup besoin de communiquer entre elles (sauf avec un ensemble de modules spécifiques, et donc là encore développer si on veut davantage car aucun module en-dehors de cet ensemble ne saura communiquer avec ceux-là)...
je suis venu à drupal vers début juiller, commencé à regarder des vidéos et vu en drupal plutôt un générateur de cms qu'un cms "pur" avec cck, views et panels...
récemment j'ai fait ma première distribution drupal : première page blog, des pages d'articles, page de vidéo avec commentaire, galeries de photos, page de contact.
du coup le client n'a qu'un blog de 5 liens (création billet blog, création article, création page vidéo, création galerie, modification menu) une fois authentifié...
il peut modifier les articles/billets une fois authentifiés, simplement, sans avoir à aller dans l'admin avec divers menus (même "zappés" comme dans l'admin joomla) et je lui laisse l'accès à la répartition du menu principal s'il supprime un article ou s'il veut les réorganiser à sa volonté.
formation du client montre en main : 45 minutes, alors qu'il ne "touche pas une bille" en informatique...
quelques bémols tout de même sous drupal (appréciation personnelle totalement subjective) :
les forums, gestion des accès par groupes pour certains aspects, et ubercart non traduit.
mais autant un site de réservation d'hôtel est plus rapide à faire sous joomla (attention à l'aspect formation de l'utilisateur pour son interface d'admin, toujours pareil...)
autant cet aspect méta-générateur de cms "maison" avec les features est d'une puissance et d'une précision que ça vaut largement la peine de se plonger dedans et d'en prendre le temps...
avec joomla, xoops et d'autres j'étais obligé de prendre du temps pour les clients pour leur dire "attention il ne faut pas cliquer ici, et là vous avez cet aspect d'administration parce que le cms est comme ça"...
avec drupal il est dans la même interface et n'a plus que quelques liens, tout simplement.
déjà deux sites "réels" avec ceci (celui cité plus haut, et un site de vidéos multilingues avec différentes vues sur les contenus vidéos) et déjà j'ai vu ceci comme avantage concret :
à partir du moment où le projet s'adapte, je peux mettre l'accent sur le suivi client en lui laissant une véritable interface restreinte -totalement- adaptée à ses besoins, dans l'interface du site lui-meme...
et de façon on ne peut plus simple !
si j'avais du faire ce "simple" site de vidéos multilingues avec joomla, j'aurais du développer à partir d'un module de gestion vidéo alors que là non : cck-views !
de la même sorte j'ai un autre à réaliser sous forme de boutique avec une certaine forme de gestion inter-nodale et joomla, malgré la richesse de ses modules ne me l'autoriserait pas (dommage, virtuemart est une excellente boutique).
encore une fois : ubercart avec possibilité de modifier les fiches avec cck, et un template bête et méchant de l'autre côté. une fois le "cap" d'assimilation passé, allez voir plus simple...
si ça continue je sens que je vais contribuer à la traduction française, parce que bon... c'est un réel manque !
joomla c'est super à partir du moment où les modules correspondent au besoin.
au-delà c'est du développement pur en supplément...
avec drupal le développement supplémentaire devient "20/80" dans l'autre sens grâce à cck-views et à sa notion de relation inter-nodale...
j'ai hâte de voir ce que tout ça donnera dans drupal 7 !
Super article, je réagit à ce dernier commentaire, pour informer celui-ci, que ubercart est bien traduits en français (au cas ou ça intéresse).
Bonne route :p
leonidas
Bine sur que chacun ont leurs particularitées mais venir dire que drupal est simple d'utilisation alors là je pense que l'on parle pas de la même conception. Si on parle de projet pro developpement drupal est très loin d'être simple si l'on parle d'un projet amateur systeme simple là oui effectivement c'est très simple.
Pour vous dire nous avons souvant atteind les limites dans drupal pour certain projet que l'on nous demandait, et nous faisons régulièrement une expertise très poussé afin de savoir quelle technologie allons nous employer et lorsque ce sont de gros projets alors on développe sous symfony mais le cout n'est tout de suite pas le même.
Drupal n'est pas particulièrement facile à modifier et le manque de doc hélas aussi même en anglais et j'ai été à une formation sur drupal payé par l'entreprise pour développeur à la base et très franchement je n'ai rien appris de pertinant.. Alors que dois je en tirer, je remet donc sèrieusement le tout relatif de certaines formations dit pour les "developpeur" sous drupal.
Mais attention je ne veux dire aucunement par là que drupal est un mauvais cms bien au contraire il est très puissant mais lire que "drupal est très simple de prise en main" je pense qu'il serait très bon de dire "oui c'est simpe pour des petits projet de site web sans grande envergure" n'importe qui peut faire un petit site éditorial ou type blog avec drupal ca c'est sur mais ca n'est pas ce que demande principalement les clients (et nous sommes loin d'être une grosse entreprise).
Je crois qu'il y a méprise sur le concept même de "prise en main". La prise en main c'est l'utilisation de l'outil au sens... utilisateur :) Ma femme utilise en ce moment même Drupal pour monter son site que j'ai développé. Pour elle, la prise en main est simple.Elle utilise CCK, les fondamentaux de Drupal, la taxonomie, les modules que j'ai intégré, etc. C'est de cette prise en main là dont on parle, et qui est carrement améliorée avec Drupal 7 (là je viens de récupérer la dernière version et c'est assez galactique).
Après, pour les gros projets dont tu parles, quelles que soit le framework utilisé, il y a un ticket d'entrée. Je pense que si tu me catapultais sur un développement pour Joomla ou pire, symfony, je serais gravement largé, en tout cas jusqu'à ce que j'acquière les compétences suffisantes pour en comprendre les fondamentaux INTERNES.
Donc d'une certaine manière je suis absolument d'accord avec toi. Développer pour Drupal n'est pas plus simple que pour n'importe quel autre framework. Et il l'est, étrangement, encore moins pour ceux qui n'ont pas l'habitudes de développer avec un framework (remarque générale non lié à ce qu tu viens de dire), car un développeur habitué à tout faire en PHP de base, va être paumé et dans la majorité des cas faire un rejet.
Maintenant je ne sais pas quelle est la nature des projets dont tu parles, mais, et là je parle plus avec mes "quelques" années d'expèrience en applications WEB Java/J2EE, pour pousser Drupal à ses limites... faut y aller très fort. Je pense qu'il serait à ses limites par exemple avec un système d'information externe à intégrer de A à Z avec couche métier, persistance & co. Mais entre nous, pour de tels projet, je ne serais pas très à l'aise pour m'embarquer sur des solutions PHP ;-)
en effet j'entendais bien "pour le client" comme écrit dans mon post, pour l'ergonomie et la prise en main...
mais plutôt pour l'utilisateur "client" et les choix à lui laisser, qui peuvent être réduits au strict minimum dans une interface minimale mais tout de même guidée...
Yoran : pour le développement sous joomla ça va, c'est pas la mer à boire mais très logique. (parfois trop, au détriment de la lisibilité pour le codeur si on suit les "bonnes pratiques joomla" avec les fonctionnalités disséminées de façon logique dans beaucoup de petits fichiers, voir "learning joomla 1.5 extension development" de joseph leblanc, chez packtpub)
ce que j'ai apprécié chez drupal en tant qu'intégrateur/développeur c'est justement ça :
pour une fonctionnalité du site à modifier, dans la majorité des cas pas besoin d'aller chercher dans le code dans les fichiers x ou y, sous-dossier z : la plupart du temps la modification d'une vue, de cck ou d'un template suffit.
je n'étais peut-être pas assez clair dans le précédent post, désolé...
Si tu veux mon très humble avis, il y a un moment où il faut arrêter le PHP et passer Java ou autre, car faire de l'objet avec PHP au niveau de ce que j'ai pu voir pour Joomla 1.5 (modéle MVC), cela doit devenir un véritable enfer avec un langage non déclaratif. Si Drupal suit un jour cette voie là, je crois que j'irais planter mes choux ailleur :)
Publier un nouveau commentaire