Les contributeurs de Gutenberg discutent des inconvénients de l'utilisation des iframes pour les méta-boîtes

Une discussion animée et productive concernant l'utilisation par Gutenberg des iframes pour les méta-boîtes se déroule sur GitHub. Hier, le développeur WordPress Kevin Hoffman a créé un problème intitulé « Les iframes sont-ils une solution viable à long terme pour les méta-boîtes ? »

Gutenberg 1.5 a introduit la prise en charge initiale des méta-boîtes. Hoffman a identifié plusieurs problèmes avec les iframes qui sont apparus alors que les développeurs ont commencé à tester l'implémentation actuelle de la méta-boîte. Il a effectué des tests de performances qui ont révélé que l'utilisation par Gutenberg des iframes triple le nombre de demandes d'actifs, car il met en file d'attente tous les actifs CSS et JS dans la fenêtre parent ainsi que dans tous les iframes.

"De manière générale, les iframes sont découragés dans le développement Web depuis de nombreuses années pour des raisons bien documentées", a déclaré Hoffman, avant de citer une litanie de problèmes que les développeurs de plugins ont déjà découverts en testant la prise en charge de la méta-boîte de Gutenberg. « Ces problèmes peuvent-ils être résolus sans nécessiter de modification du thème ou du plugin qui génère la méta-boîte ? Nous devons considérer que le code tiers qui a alimenté les méta-boîtes pendant des années peut ne pas avoir le luxe d'être mis à jour afin d'être compatible dans un iframe.

Tammie Lister, responsable de la conception de Gutenberg, a répondu aux préoccupations de Hoffman, indiquant que l'implémentation actuelle des méta-boîtes n'est qu'une expérience et pas nécessairement ce qui atterrirait dans WordPress 5.0 :

Il est bon de penser un peu que ce que nous avons aujourd'hui pour les méta-boîtes de Gutenberg est une expérience, à bien des égards, c'est un schéma d'attente alors que le projet détermine la direction à prendre. En disant que c'est celui qui fonctionne "pour l'instant" mais ce n'est pas ce que nous expédierons avec.

Tout ce qui précède, je pense qu'il est important de regarder à quoi serviront les métaboxes à l'avenir. Quels sont les cas (le cas échéant) qui ne seraient pas convertis en blocs ? Toutes les métaboxes doivent-elles fonctionner sur mobile ? Existe-t-il même une interface alternative que nous n'avons pas explorée ? Je parie qu'il y en a. À l'heure actuelle, il s'agit d'examiner ces possibilités et de s'engager sur une voie qui fonctionne pour l'État actuel et pour l'État futur.

La présentation de cette implémentation comme une expérience qui "fonctionne pour l'instant" (mais ne serait pas livrée) est une surprise après l'arrivée de Gutenberg 1.5 avec l'annonce que "cette version inclut le support tant attendu des méta-boîtes (besoin de test !)"

Hoffman soutient que l'approche iframe ne fonctionne même pas "pour l'instant", car le problème a été ouvert afin de citer plusieurs façons principales de le casser. Si Gutenberg va de l'avant avec l'approche actuelle, il faudrait que de nombreux plugins soient modifiés pour être compatibles avec WordPress 5.0, ce qui, selon Hoffman, irait à l'encontre de l'objectif de prendre en charge les méta-boîtes héritées.

"Je n'ai vu aucune preuve à ce jour suggérant que les méta-boîtes continueront de travailler avec Gutenberg", a déclaré Hoffman. "Si la réponse est non, alors nous devrions arrêter de prétendre que la 5.0 ne sera qu'une autre version de WordPress et commencer à être honnête sur la rupture de la rétrocompatibilité."

Edwin Cromley, un collaborateur du projet, a déclaré que l'équipe prévoit que certains thèmes et plugins seront cassés et qu'il n'est pas possible de s'adapter à tous les cas d'utilisation possibles. Il a admis que la solution iframe pourrait ne pas répondre aux objectifs du projet. Au lieu de cela, il préconise de créer la meilleure expérience pour la grande majorité des utilisateurs.

Cependant, l'approche actuelle affecterait négativement de nombreux sites qui utilisent WordPress principalement comme CMS avec des méta-boîtes. Le responsable principal de WordPress, Scott Taylor, a exprimé des inquiétudes concernant les types de publication personnalisés, dont beaucoup n'utilisent pas la section "contenu" traditionnelle en faveur des boîtes méta uniquement.

"Dans cette itération actuelle, la prise en charge des méta-boîtes est un complément, alors que dans la réalité de nombreuses personnes, les méta-boîtes SONT l'interface utilisateur, l'API, le mécanisme qu'elles utilisent pour composer leur CMS", a déclaré Taylor. « Les iframes, c'est le goulag.

« Et nous oublions les valeurs sur lesquelles WP a toujours été construit : je devrais pouvoir mettre à jour vers la dernière version de WP, et n'avoir rien à réécrire. J'ai tellement de projets à l'état sauvage sur WP que je ne toucherai plus jamais. Puis-je être sûr que certains d'entre eux ne rompront pas sauvagement avec ce changement ? »

Hoffman a préconisé de réduire la portée du projet pour se concentrer sur le composant éditeur, une opinion populaire partagée par de nombreux développeurs de plugins et illustrée en détail dans le post de Yoast proposant une approche alternative à Gutenberg. Cette approche échelonne les modifications apportées à l'écran d'édition, donnant aux développeurs plus de temps pour mettre à jour leurs plugins, tout en permettant à l'équipe Gutenberg de trouver une solution adéquate pour les méta-boîtes.

"Je pense que cet objectif serait beaucoup plus réalisable si Gutenberg s'en tenait à la refonte de l'éditeur plutôt que de reprendre toute la page", a déclaré Hoffman. « Ensuite, nous pourrions laisser les crochets existants en place et les méta-boîtes pourraient continuer à communiquer entre elles comme elles le font actuellement. De plus, la mise en file d'attente des actifs ne serait pas un problème puisqu'elle fonctionnerait comme elle le fait aujourd'hui.

"Je suis tout à fait d'accord avec ce concept mis en avant par Yoast, qui me semble qu'il maintiendrait une grande partie du travail déjà effectué tout en réduisant la portée du projet pour se concentrer sur le composant éditeur."

L'ingénieur de Gutenberg, Riad Benguella, a indiqué que l'équipe n'était pas trop enthousiaste à l'idée de travailler sur ce concept.

"Réutiliser des pièces de Gutenberg pour construire ce concept est relativement faisable, mais ce n'est pas l'UX que nous voulons optimiser, nous voulons d'abord construire le meilleur éditeur possible et le rendre disponible pour les personnes sans problèmes de rétrocompatibilité (nouvelles installations, pas de métaboxes... ) », a déclaré Benguella.

"Lorsque nous penserons que la vision idéale de Gutenberg est prête à être expédiée, nous aurons le temps de discuter des stratégies de chemin de mise à niveau, un concept comme celui-ci est une option pour un chemin de mise à niveau, mais certainement pas en tant que produit final. D'autres chemins de mise à niveau sont également possibles.

La communauté des développeurs WordPress n'est cependant pas favorable à retarder une fois de plus cette discussion. Beaucoup sont impatients de répondre enfin à la question de savoir comment les méta-boîtes s'intégreront dans le contexte de l'éditeur Gutenberg afin qu'ils sachent comment se préparer. Compte tenu des nombreux problèmes liés à l'approche iframes, le rendu des méta-boîtes PHP héritées sous le nouvel éditeur nécessitera plus d'expérimentation et éventuellement une solution alternative.

"Pourquoi consacrer des milliers d'heures à développer l'éditeur idéal s'il n'est pas compatible avec les sites existants ?" dit Hoffmann. "Si la première impression est que cela casse l'interface utilisateur dont ils dépendent, les utilisateurs ne connaîtront jamais l'éditeur idéal en premier lieu."

"Je pense que c'est peut-être une erreur de repousser cela trop loin", a déclaré Aaron Jorbin, principal responsable de WordPress. "D'autant plus que de nombreuses organisations vont avoir besoin d'au moins 1 à 2 trimestres pour se préparer."

Mark Kaplun suggère à l'équipe de Gutenberg d'utiliser un plug-in populaire comme indicateur du succès des expériences actuelles et futures de prise en charge de la méta-boîte.

"Ma suggestion productive est de ne pas déclarer les méta-boîtes prêtes, tant que Yoast SEO ne fonctionne pas correctement dedans", a déclaré Kaplun. "C'est à la fois un peu complexe en termes d'interactions et c'est installé sur des tas de sites de merde. Si Gutenberg ne peut pas travailler avec, personne ne l'utilisera probablement.

Greg Schoppe, qui a beaucoup testé et écrit sur le développement en cours de Gutenberg, s'est joint à la conversation pour défendre également l'approche alternative de Yoast pour le projet.

"Je soutiens fortement le point de vue de Yoast sur Gutenberg", a déclaré Schoppe. "Je ne sais pas comment" mettre à niveau l'éditeur visuel "a été réinterprété pour être" remplacer l'ensemble de l'interface de post-édition "par l'équipe de Gutenberg, mais cela semble directement en contradiction avec le soi-disant" navire de Thésée ".

"Dans ce cas, le manque d'orientation claire et de prise en charge des flux de travail standard existants nuit activement aux développeurs. Comment puis-je avancer dans la construction d'un projet, sans un ensemble fiable d'accroches et d'outils sur lesquels je peux compter ? Il est déraisonnable de penser qu'un projet logiciel d'une telle envergure bouleverserait entièrement le flux de travail standard des développeurs en une seule mise à jour. et c'est insensé que ces conversations n'aient lieu que maintenant, en novembre, alors que le plan est de faire approuver une fusion au début de l'année.

La discussion concernant l'approche iframes des méta-boîtes a été ouverte hier est encore relativement nouvelle, mais jusqu'à présent, les réponses de l'équipe Gutenberg n'ont pas répondu de manière adéquate aux préoccupations de la communauté des développeurs dans ce fil. Trouver une approche des méta-boîtes qui préserve les puissantes capacités du CMS de WordPress, sans aliéner les utilisateurs et les développeurs, est l'un des plus grands défis de l'équipe Gutenberg. Ils visent toujours à produire une proposition de fusion au début de l'année prochaine, mais avec des méta-boîtes encore au stade de l'expérimentation, le calendrier prévu de l'équipe continue de mettre le projet en contradiction avec la communauté des développeurs WordPress.