[Résolu] Drupal 8 à Drupagora 2014

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,

Quelques heures après la clôture de Dupagora 2014, je tenais à partager ici (plutôt que sur Twitter) mes réactions et interrogations quant à la dernière conférence de 17h15 relative à Drupal 8 et à l'avenir de notre CMS préféré.

En espérant partager ce retour avec d'éventuels autres participants Drupagora présents sur ce forum.

Ma première remarque sera de dire que l'impression laissée par la dernière intervention et le descriptif de ce que l'avenir nous réserve est pour le moins déstabilisante.

En substance, les deux conférenciers, dont je n'ai malheureusement pas noté le nom, visiblement très impliqués dans la communauté et, sans nul doute, de très bonne foi, nous on dressé un tableau de l'avenir Drupal assez prospectif mais aussi et surtout, très inquiétant.

Si je résume :

  • le bébé D8 arrive avec du retard et par le siège (certes, ce n'est pas un secret)
  • visiblement en surpoids. On lui prédit un régime d'entrée de jeu
  • s'il survit, il faudra de toute façon le couper la tête (je veux dire le "FRONT")
  • disposant de moins de 5% d'ADN commun avec la mère. On peut douter de la filiation... (et donc du retour sur l'investissement D7)
  • Il va falloir que la toute la famille apprenne le langage des sourds (le javascript) pour parler à la tête, du coup manquante.
  • il est en outre possible que le malotru nous balance en retour, plein de cailloux - "des galets" - en guise d'accusés de réception (là, j'ai pas bien compris...)
  • et le père a quitté le domicile conjugal - sans reconnaître l'enfant - avant l'accouchement au vue des premières radiographies. (On appelle ça un "fork")
  • hum...

Cela fait beaucoup.

Surtout pour la DSI qui s’apprêtait à miser sur le cheval Drupal (et donc D8).

Il y a de quoi rebrousser chemin, retrouver le 06 de Lucifer, et le supplier de bien vouloir re-pactiser avec nous en présence de tous les démons du Marketing du Logiciel Propriétaire et sur l'autel de la Roadmap Infernale - mais cohérente - du Business Model vénal...

Je ne fais aucun reproche aux deux intervenants, sauf celui d'avoir été trop honnêtes ou celui d'avoir mélangé les genres dans une approche trop "développeurs" (quand "DevOps" devient "DevOoops") pour un salon sensé être destiné aux décisionnaires (DSI, Chef de Projets et Partenaires).

Cette honnêteté est tout à leur honneur mais elle risque de ne pas faire leur fortune (ni celle des "partenaires" Drupal" présents dans la salle)

Par ailleurs, l'iconographie utilisée lors des projections m'a laissé pantois.

Le Drupal 7 que 2 heures avant encore, on me présentait comme agile, modulaire et léger est soudain devenu monolithe... Le module chéri d'hier, petit cailloux incarcéré dans une tonne de roche mégalitique aussi inerte que muette...
L'illustration associée à Drupal 8, faite de petits galets empilés, m'a un instant fait penser aux débris du 11 septembre.
Et, cerise sur le gâteau, le diagramme d'intégration des librairies agglutinées dans D8 débordait de tous les côtés comme un gâteau à la crème écœurant...

A tel point que je me suis demandé si les deux gentlemen ne tenaient pas plus à nous alerter qu'à nous informer...

Bref, je reste dubitatif et ne sais trop quoi penser de tout cela.

Je balance entre un tableau maladroitement brossé trop sombre (ou des problématiques vues de trop prés au point qu'elles paraissent insurmontables... le grain de sable est devenu monolithe...) et une véritable alerte de l'intérieur synonyme de : "Passe ton chemin tant qu'il est temps..."

Dans l'espoir d'un autre éclairage...

Amitiés.

PS : Je positive toutefois en appréciant à sa juste valeur, la liberté de ton et de parole des développeurs Open Source qui dénote fortement avec les litanies habituelles des Keynotes d'autres solutions fermées dont les conférences ressemblent à du lavage de cerveau sectaire ponctués de "Yooo Hooo !" à l'américaine à chaque clic de souris (et je ne parle même pas d'Apple :)).

Version de Drupal : 
Tags : 

Salut Drupy,

Je n'étais pas à Drupagora et je n'ai aucune idée du contenu de la conférence dont tu parles car je n'en sais que ce que tu en dis et cela me laisse un peu sans voix.
Je n'ai pas étudié Drupal 8 en profondeur, manque de temps, mais j'ai eu l'occasion de tester ses capacités d'un point de vue Site Builder et j'ai récemment pu éprouver un peu la qualité de son code en participant à quatre jours de sprints en présence de certains de plus gros contributeurs.
A mon sens, on ne peut pas parler de Drupal 8 en général car les changements que cette nouvelle version introduit sont si profonds que cela n'a pas de sens. On peut les observer par le prisme des initiatives qui ont conduit à cette mouture ou alors en empruntant le regard des différents intervenants dans la conception d'un projet Drupal.

Je commence par les intervenants et en particulier le Site Builder. Si tu ne connais pas ce terme, il désigne une personne qui va construire un site en ne se servant que des options proposées par l'interface du coeur et des modules contribués. Le Site Builder habitué à Drupal 7 ne sera pas dépaysé par Drupal 8 car l'organisation de son administration n'a pas changé. Il trouvera dans le coeur quelques uns des modules qu'il était habitué à ajouter auparavant comme Views, un peu de Display Suite (encore), quelque chose qui ressemble à Features issue de l'initiative CMI (on y revient), quelque chose qui ressemble à BEAN, CKEditor et un système d'édition en place (directement dans la page), tout un tas de types de champs dont les Entity References, et, enfin, un vrai système d'internationalisation... En bref, avec uniquement ce qui est présent dans le coeur, il pourra déjà faire un site fonctionnel et il ne lui manquera que quelques modules pour gérer des aspects un peu plus subtils. Tous ces modules, désormais gérés dans le coeur, seront donc maintenus avec la même rigueur et seront donc, de fait, stabilisés.

Prenons ensuite les Thémeurs. Avec Drupal 7 certains se sont arraché les cheveux à tenter de comprendre le système de rendu, quand il fallait modifier un template, son format, quand il fallait créer une fonction, à quel endroit... Parfois, cela a même mené à d'importants problèmes de performances ou de sécurité car il était tout à fait possible de coder dans les templates. Maintenant, toutes les fonctions de thème font appel à des templates, écrits avec le moteur Twig qui interdit formellement tout usage de PHP. L'appel à la fonction thème est déprécié en faveur des render arrays qui permettent de pouvoir altérer les données jusqu'au dernier moment. Toutes ces choses ont été réalisées à la demande des thémeurs et pour leur plus grand plaisir. Certes il leur faudra apprendre (pour certains) à utiliser Twig, mais cela n'incluant pas toute la complexité de PHP cela semble plus simple. Ils se poseront moins de questions également sur ce qu'ils ont à faire car tout à été uniformisé. En bonus, les templates Twig sont précompilés en PHP et ils bénéficient donc des mêmes performances que le moteur précédent.
Outre toutes ces problématiques de templates, Drupal 8 est livré avec un système permettant de faciliter la gestion du Responsive Web Design en proposant de gérer les Brekpoints et en leur associant même des Styles d'Image spécifiques pour éviter aux utilisateurs mobiles de charger des pages énormes ou pour avoir des versions Retina des illustrations du site Internet. Ils pourront plus facilement maîtriser le markup HTML généré par Drupal, pourront toujours surcharger mais aussi désactiver les feuilles de style et fichiers javascript du coeur.

Pour finir, les Développeurs ne seront pas en reste même s'ils seront probablement les plus touchés par cette évolution. En effet, le passage au tout objet (ou presque), l'appui sur des libraires développées et maintenues par des équipes externes et les changements et enrichissements de l'API nécessiteront un temps d'apprentissage. Cependant, l'ouverture de notre communauté à d'autres, comme celle de Symfony, permettra aussi certainement d'apporte du sang neuf dans les rangs des mainteneurs. De plus, en s'appuyant plus sur l'écosystème, on s'oblige à suivre des règles (PSR-0 et PSR-4 par exemple) et on renforce toutes les équipes par l'expérience commune. A ce stade de l'évolution du Web et de PHP, toutes les équipes de tous les concurrents de Drupal se tournent vers l'extérieur car les solutions que l'on trouve dans un petit groupe n'arrivent souvent pas à la chevilles de celles trouvées par une population plus spécialisée ou plus vaste. L'arrivée de l'Objet dans Drupal est aussi une excellente nouvelle d'un point de vue qualité car c'est une condition importante à l'écriture de tests robustes qui valident le modèle et empêchent les régressions.
En tant que développeur, j'ai commencé à m'intéresser à la transition du coeur et, même si je souffre beaucoup en ouvrant le code, l'ingénieur qui est en moi reconnaît des patterns et valide des choix. Il faudra des formations pour certains, juste du temps pour d'autres, mais de la motivation pour tous pour surmonter ce changement. La communauté est déjà en marche pour aider à la transition par l'écriture de très nombreux articles assez approfondis et qui relatent de l'avancée des travaux, mais aussi par la création d'outils pour aider les autres développeurs à progresser plus vite. Ainsi, il existe déjà aujourd'hui deux outils pour faciliter la transition : Console, un outil en ligne de commande permettant de générer à peu près tout ce qui est utile dans Drupal (module, entité, configuration, services...) et Module Upgrader qui, comme son nom l'indique, aide à mettre à jour un module de la version 7 à la version 8. Ceux-ci ne sont pas aujourd'hui finalisés mais permettent et promettent déjà de belles choses.

Toutes ces choses que je cite je ne les ai pas vus dans une conférence ou une démo, je les ai expérimentés moi même et j'ai pu constater que malgré des bugs plus ou moins pénibles, toutes ces choses fonctionnent déjà !

Je vais maintenant revenir sur ta liste pour essayer de comprendre ce qui a voulu être dit et y apporter mon point de vue :

  • le bébé D8 arrive avec du retard et par le siège (certes, ce n'est pas un secret)

Ce n'est pas faute d'avoir un certain nombre de personnes qui y travaillent de manière très intensive, la plupart de manière totalement bénévole. C'est bien joli de profiter de l'Open Source mais si on choisit de ne rien en financer c'est normal que les choses n'avancent pas.

  • visiblement en surpoids. On lui prédit un régime d'entrée de jeu

Le coeur intègre pas mal d'anciens modules et pas forcément les plus légers. Comme tout système en phase de développement, on s'intéresse d'abord et avant tout aux fonctionnalités et on cherche ensuite à l'optimiser. C'est donc normal, maintenant que la phase de bêta a débuté, qu'on s'intéresse à lui faire perdre un peu de poids. Je serais curieux de voir quelqu'un faire un test, à fonctionnalités égales, des performances de D7 contre D8. L'architecture orientée objet assortie du système d'autoloading permet d'avoir beaucoup moins de choses chargées en mémoire et ne n'invoquer que le strict nécessaire. Je ne serais pas étonné de voir que la lourdeur présumée de l'objet (optimisée avec PHP 5.4, 5.5 et 5.6 et les systèmes de cache d'opcode) soit un peu exagérée.

  • s'il survit, il faudra de toute façon le couper la tête (je veux dire le "FRONT")

Pourquoi ? Il y a des personnes qui étudient la possibilité de le faire, il y a même une initiative qui essaie de faire en sorte que ce soit possible (Webservices) mais je pense plutôt que l'on verra naître des sites qui utiliseront à la fois la couche front et les webservices au lieu de sites dont Drupal servirait de pur backoffice.

  • disposant de moins de 5% d'ADN commun avec la mère. On peut douter de la filiation... (et donc du retour sur l'investissement D7)

Le code n'est pas l'ADN d'un projet Open Source. On retrouve dans D8 absolument tous les concepts qui sont nés et qui ont survécu tout au long des versions précédentes. On parle toujours d'entités, de noeuds, de taxonomie, de blocs... En prenant la chose dans ce sens je dirais à l'inverse que 100% de l'ADN de Drupal a été conservé.

  • Il va falloir que la toute la famille apprenne le langage des sourds (le javascript) pour parler à la tête, du coup manquante.

Certains parlent d'une future version de Drupal (9, 10...) qui serait écrite en Javascript. Cependant, on en est très loin et ce genre de choix, lointain, se fera en fonction de l'évolution du web. Aujourd'hui, Javascript n'est pas un outil essentiel pour le développement Drupal avec D8. C'est un outil essentiel pour le développement web.

  • il est en outre possible que le malotru nous balance en retour, plein de cailloux - "des galets" - en guise d'accusés de réception (là, j'ai pas bien compris...)

Je ne vois pas non plus de quoi il est question.

  • et le père a quitté le domicile conjugal - sans reconnaître l'enfant - avant l'accouchement au vue des premières radiographies. (On appelle ça un "fork")

La création de Backdrop devrait être, au contraire, considérée comme une bénédiction pour les DSI car cela signifie que leurs projets D7 seront maintenus par une équipe dédiée. En effet, ce fork a pour objectif de conserver une compatibilité descendants et des usages qui ne dépayseront pas les équipes.

Voilà, si je devais faire un gros résumé de tout ça, je dirais que globalement, comme avec toutes version majeure d'un logiciel, on va certainement avoir du mal à faire la transition mais je ne pense sincèrement pas que cette nouvelle version soit de mauvaise qualité ou aille globalement dans le mauvais sens. Le métier se professionnalise ce qui ne peut pas être un mal quand on considère la cible principale de Drupal.

My 2 cents.

Bonjour DuaelFr,

Merci d'avoir pris le temps de me faire cette réponse extrêmement complète et détaillée.
Réponse d'autant plus complète et structurée que la mienne était - un peu volontairement afin de susciter quelques réponses - émotionnelle et épidermique.
J'apprécie le geste à sa juste mesure.

Je comprends que Drupal 8 évolue pour le meilleur, ou, tout au moins le meilleur tel qu'appréhendé en cet instant T.

Je comprends que les fonctionnalités de D7 seront conservées, améliorées ou portées vers les dernières techno du moment.

Que ce portage nécessitera donc une montée de compétence globale des développeurs.

Qu'il ne faut pas jouer les Cassandre, et que bien malin est, celui qui peut dire quelle seront les standards - ne serait-ce qu'en terme d'usage - du web dans 2/3 ans.

Ce qui me pose plus questions, et je suppose qu'il n'y a pas de réponse unique mais plutôt une par site web en fonction des modules exploités, c'est le portage de D7 à D8...

Je m'interroge aussi sur la durée de maintenance de D7, une fois D8 sorti.

Tu indiques, que dans ce cadre, le fork "BackDrop" est une bénédiction...

Je me demande aussi quel apport (support) une société comme Acquia peut fournir aux sites qui nécessiterait une refonte trop profonde pour passer à D8 rapidement.

Je suppose que tout cela va s'éclairer dans les mois qui viennent lorsqu'une version stable de D8 sera disponible et que les quelques millions de sites D7 (dont certains de grande notoriété) se trouveront au pied du mur au moment d'acter leur Roadmap des années à venir.

A nouveau merci pour cette réponse très complète.

Cordialement

J'ai vu les slides aujourd'hui, car malheureusement j'ai dû quitter Drupagora juste avant cette conférence.

Je pense que la réflexion sur le fait qu'il n'y aura plus de projet "100% Drupal" n'est pas dû au produit lui-même mais à l'approche / environnement actuel, avec de plus en plus d'applications mobiles, qui vont consommer du contenu via des services.

Déjà actuellement, on a dans quelques cas développé une appli mobile avec un drupal en back-office, qui sert du contenu via des services REST.
Pas de "vrai" front, puisque le Drupal sert juste à la saisie du contenu.

Avec D8 ce sera plus simple, puisque tout est dans la boîte.

Mais il n'est pas question à mon sens de devoir systématiquement passer par du JS (Angular & autres) pour afficher le contenu de D8. Les thèmes sont basés sur Twig, et pourront continuer à être utilisés.

Bonjour Drupy,

Merci pour ce retour sur notre présentation, c’est toujours agréable d’avoir un avis sur les choses. Je vais tacher de ne pas faire doublons avec la pertinente réponse de DuaelFr dans mes commentaires. Frédéric ou moi sommes comme tu l’écris, impliqués dans le monde Drupal depuis quelques années maintenant que ce soit sur la partie Drupal logicielle ou dans sa communauté. Le but de cette présentation était clairement d’éveiller des idées et susciter la curiosité de l’auditoire sur le potentiel de cette nouvelle monture et en aucun cas d’effrayer les participants.

TLTR;
Drupal 8 comme CMS sera super, D8 comme application complexe demandera une réflexion différentes en amont de façon à en tirer les bénéfices au mieux. Quelle que soit l’utilisation qui en sera faite, il faudra payer à l’entrée le coût des différentes nouveautés. Ce coût sera minime quant aux nouveautés et bénéfices apporter. Drupal 8 pourra être utilisé pour autre chose qu’un simple CMS et cela facilement.

Lors de la préparation de cette session j’ai fait le choix de ne pas présenter Drupal 8 sous son aspect CMS et nouvelles fonctionnalités car cela fait maintenant des mois que l’on en parle et je ne voulais pas de rabâchage continuel dans ce sens. Au lieu de cela nous avons essayé de présenter ce que l’on pourra en faire, comment D8 pourra être intégré dans un système d’information ou encore son usage dans une architecture d’application complexe.

Je balance entre un tableau maladroitement brossé trop sombre (ou des problématiques vues de trop prés au point qu'elles paraissent insurmontables... le grain de sable est devenu monolithe...) et une véritable alerte de l'intérieur synonyme de : "Passe ton chemin tant qu'il est temps…

A la lecture de ton message et lorsque l’on remet la session dans le contexte de la conférence, c’est à dire à la fin de la journée, je comprends qu’après d’autres sessions D8 où il était présenté comme LA solution, c’était un peu la douche froide. Ainsi j’aurais dû en préambule dire que ce qui allait suivre n’allait (presque) pas s’appliquer à tout le monde et/où à tous les projets. Clairement, pour quelqu’un qui compte utiliser Drupal comme CMS en le personnalisant avec des modules cela ne changera pas grand chose, c’est ce qu’évoque DuaelFr lorsqu’il parle des sites builders. En revanche cela change coté développeur, car cette évolution majeure de Drupal va imposer aux développeurs ayant appris le PHP sur Drupal d’évoluer vers la programmation orientée objet.

Et, cerise sur le gâteau, le diagramme d'intégration des librairies agglutinées dans D8 débordait de tous les côtés comme un gâteau à la crème écœurant…

C’est effectivement ce que j’ai voulu passer comme message, les nouvelles fonctionnalités, extensions et autre librairies vont être légions dans cette nouvelle version et cela va nécessiter du temps pour les comprendre et exploiter au mieux. Certes la base de code va augmenter comparé à un D7, néanmoins cela va grandement faciliter la maintenance et les évolutions du core de Drupal.

Je ne fais aucun reproche […] sauf celui d'avoir été trop honnêtes ou celui d'avoir mélangé les genres dans une approche trop "développeurs" (quand "DevOps" devient "DevOoops") pour un salon sensé être destiné aux décisionnaires (DSI, Chef de Projets et Partenaires).

Lorsque le comité de pilotage de Drupagora m’a proposé de présenter ce sujet j’ai vu l’occasion d’aller plus loin et de parler à destination des développeurs mais aussi des DSI de ce qu’il se faisait hors Drupal en terme d’architecture d’applications web.
Car même si cet évènement est à destination des DSI on retrouve un grand nombre de développeurs intéressés par le sujet. J’ai malheureusement bien trop souvent vu ou participé à de vrais projets monolithiques ou tout ajout de fonctionnalité engendrait son lot de régressions. Du Drupal comme serveur de mailing pour les campagnes newsletter du marketing à l’ajout de centaines de lignes de codes pour faire de l’analyse statistique sur les ventes en temps réel sur le site de la boutique…
Heureusement ce genre de cas n’arrive pas tous les jours. A mon sens c’est en partie dû à un manque de sensibilisation, un outil n’est pas fait pour tout faire, on ne plante pas un clou avec une clé à molette, enfin techniquement si on peut, mais bon c’est pas pour cela qu’il faut le faire, avec Drupal c’est pareil. Ainsi le passage aux applications monolithiques vers des architectures orientées composants ou micro-services est obligatoire si l’on veut être le plus performant possible. Je ne me considère pas comme un génie ou un prophète du logiciel libre mais comme un développeur passionné. L’honnêteté à ce stade était recherchée afin de susciter l’intérêt et éveiller les mentalités. Personnellement je n’aime pas sortir d’une session ou d’une conférence en ayant uniquement vu le coté magique de la chose, j’aime voir les problématiques et les limites du système car en comprenant les faiblesses je sais jusqu’où je peux aller. D'ailleurs, je reproche que bien trop souvent on montre Drupal 8 comme la solution magique qui va tout régler. Il est clairement faux de croire que Drupal est la solution miracle à toute application web. C’est un outil qui doit être choisi en fonction des besoins du projet. Oui cela va régler énormément de nos problématiques actuelles et je crois que l’on est tous impatients de ne plus avoir de configuration en base de données (entre autre) néanmoins cela va apporter des changements qu’il va falloir opérer à tout niveau.

Mes collègues et amis développeurs Drupal l’ont bien compris néanmoins je ne suis pas certain que ce soit le cas pour le DSI qui pilote les projets d’une vision trop macro. Comme nous l’avons évoqué avec Frédéric et comme le redit Vincent59, les problématiques évoquées ne concernent pas Drupal intrinsèquement mais notre utilisation de celui-ci. Il était donc important pour moi d’évoquer la fin des applications complexe 100% Drupal et proposer des alternatives. D8 s’annonce comme une solution sérieuse ORM pour SF2 ou comme backoffice pour réaliser des Single Pages Application (SPA) ou pour fournir des flux à des applications mobiles, on parle alors de M.B.a.a.S.

Ainsi dans un monde ou bien souvent on fait tout en Drupal, j’ai hâte de voir et de travailler sur des applications où Drupal sera un composant de celles-ci et où l’on pourra résoudre des problématiques complexes dans d’autres langages.

Encore une fois merci pour ton retour et c’est avec plaisir que je l’ai lu. J’espère, en plus de DuaelFr t’avoir apporté plus d’informations et amélioré la vision inquiétante et déstabilisante de notre présentation. Je suis en train de terminer la synthèse de cette présentation qui inclura mes notes de recherches du mois passé sur ce sujet que je publierai sur mon blog si cela t’intéresse.

Amicalement

Julien