Gutenberg: Les iframes sont-ils une solution viable à long terme pour les méta-boîtes?

1. ... Gutenberg utilise actuellement deux iframes distincts pour la colonne principale et la barre latérale. Si nous prenons en charge les méta-boîtes qui apparaissent après le titre, cela aboutirait théoriquement à une troisième iframe. Cela présentera-t-il des problèmes concernant la manière dont les plugins mettent en file d'attente les actifs qui doivent affecter toutes les méta-boîtes iframed?

J'ai fait quelques tests de performances ce soir, et je suis tombé sur cette découverte dans mon onglet Réseau qui est alarmante. Il semble que tous les actifs CSS et JS qui sont mis en file d'attente dans la fenêtre parente sont également mis en file d'attente dans l'iframe de la colonne principale et l'iframe de la barre latérale - ce qui signifie que chaque actif est demandé un total de trois fois, triplant effectivement le nombre de demandes d'actifs lors de l'utilisation Gutenberg .

Les dommages au poids de la page sont réduits avec la mise en cache du navigateur activée, mais le nombre de demandes d'actifs est toujours triplé. Je suppose que cela est fait pour que chaque iframe dispose des actifs nécessaires pour permettre aux méta-boîtes de fonctionner, mais cela ne peut certainement pas être la solution pour mettre en file d'attente des actifs à l'avenir.

Merci d'avoir créé le problème et vos idées @kevinwhoffman. Il est bon de penser un peu que ce que nous avons aujourd'hui pour les métabox à Gutenberg est une expérience, à bien des égards, c'est un modèle d'attente alors que le projet détermine la direction à prendre. En disant que c'est celui qui fonctionne «pour le moment» mais qui n'est pas ce avec quoi nous expédierions.

Tout ce qui précède dit, je pense qu'il est important de regarder à quoi les métaboxes seront utilisées à 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 que oui. À l'heure actuelle, il s'agit d'examiner ces possibilités et de s'engager sur une route qui fonctionne pour l'État maintenant et pour l'État futur.

À l'heure actuelle, les bogues qui existent avec la version actuelle des métaboxes dans Gutenberg doivent être corrigés et c'est une priorité. La performance doit entrer dans cette correction. En ce qui concerne les mobiles, les métaboxes sont depuis longtemps un problème, nous n'aggraverons pas les choses ici. Cela dit, nous devons travailler pour une meilleure solution à l'avenir. Il est important de revenir en arrière et de se rappeler qu'il ne s'agit que d'une solution «aujourd'hui», car nous répétons et restons libres de penser à une meilleure option.

Il est bon de penser un peu que ce que nous avons aujourd'hui pour les métabox à Gutenberg est une expérience, à bien des égards, c'est un modèle d'attente alors que le projet détermine la direction à prendre. En disant que c'est celui qui fonctionne «pour le moment» mais qui n'est pas ce avec quoi nous expédierions.

L'approche iframe ne fonctionne pas, même pas simplement «pour le moment». Les problèmes connexes énumérés ci-dessus fournissent des exemples de méta-boîtes ne fonctionnant pas de manière majeure. En outre, même si ces problèmes étaient résolus, tripler le poids de la page et le nombre de demandes ne devrait en aucun cas être considéré comme «fonctionnel».

Tout ce qui précède dit, je pense qu'il est important de regarder à quoi les métaboxes seront utilisées à l'avenir.

Respectueusement, cela se produit chaque fois que la question des méta-boîtes est soulevée. S'il vous plaît, plutôt que de déplacer la conversation vers les futurs méta blocs, il serait vraiment utile de cadrer cette discussion autour des problèmes auxquels sont confrontés les méta-boîtes existantes. Encore une fois:

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?

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

Salut Kevin,

Merci pour le rapport détaillé. Je pense que beaucoup de problèmes peuvent être réglés dans une certaine mesure. Il s'agit également d'explorer si l'approche iframe fonctionnera et jusqu'où elle peut être poussée, il est donc bon d'avoir ce type de dialogue et de faire la chronique des lacunes de cette approche.

Est-il possible de lancer une fenêtre de contenu à partir d'une méta-boîte qui s'étend au-delà de l'iframe?

Voulez-vous dire comme une lightbox modale qui devrait occuper toute la page?

Voulez-vous dire comme une lightbox modale qui devrait occuper toute la page?

Ce serait un exemple, mais je fais davantage référence à tout scénario où le contenu doit être révélé qui ne se trouve pas dans les limites de l'iframe.

Par exemple, puis-je cliquer sur un bouton dans la barre latérale qui déclenche une zone de contenu au centre de la page? Si cette zone de contenu est à l'intérieur de l'iframe, elle ne sera pas visible en dehors des dimensions de l'iframe dans la barre latérale.

La prochaine étape logique serait d'appeler à la place la fonction dans le document parent à partir de l'iframe. Mais les plugins ne sont pas actuellement écrits pour fonctionner comme ça, et exiger qu'ils soient modifiés irait à l'encontre de l'objectif de la prise en charge des méta-boîtes _legacy_. Je ne saurais trop insister sur le fait que quelle que soit la solution choisie, elle doit fonctionner sans modification des thèmes ou plugins existants.

Sachant à quel point l'implémentation d'iFrame est négative en ce qui concerne les actifs du plugin / thème, je pense que cela devrait mettre le projet en pause. La vraie réponse ici est que WordPress expédie l'API Fields https://github.com/sc0ttkclark/wordpress-fields-api - sans cela, implémenter efficacement des métaboxes avec Gutenberg est pratiquement impossible si nous nous soucions des performances.

Si nous n'expédions vraiment pas Gutenberg avant qu'il ne soit "prêt", alors je dis que nous devrions accorder la même attention à l'API Fields pour que les metbox fonctionnent correctement et de manière transparente avec React dans Gutenberg.

La prochaine étape logique serait d'appeler à la place la fonction dans le document parent à partir de l'iframe. Mais les plugins ne sont pas actuellement écrits pour fonctionner comme ça, et exiger qu'ils soient modifiés irait à l'encontre de l'objectif même de la prise en charge des méta-boîtes héritées. Je ne saurais trop insister sur le fait que quelle que soit la solution choisie, elle doit fonctionner sans modification des thèmes ou plugins existants.

Oui, certainement une préoccupation que j'avais en faisant cela. La communication croisée entre les iframes ne sonne pas très bien. Il existe également d'autres alternatives à explorer.

Il y aura certainement des cas où certains plugins de thèmes seront cassés, et il n'est pas possible de s'adapter à tous les cas d'utilisation possibles, je pense que peut-être un meilleur objectif est de créer une bonne expérience pour la grande majorité des utilisateurs et des cas d'utilisation. . Il est tout à fait possible que la solution iframe actuelle n'atteigne pas cet objectif.

Il peut être intéressant de noter que dans un récent article sur la note de développement de Core Customizer, l' attention a été attirée sur la suppression de l'utilisation d'une iframe comme _amélioration_. La mise en œuvre d'une iframe comme solution ici semble être un pas en arrière.

Salut mathetos,

Si nous n'expédions vraiment pas Gutenberg avant qu'il ne soit "prêt", alors je dis que nous devrions accorder la même attention à l'API Fields pour que les metbox fonctionnent correctement et de manière transparente avec React dans Gutenberg.

Je suis d'accord qu'une API Fields serait plutôt bien. Cependant, cela impliquerait également que les gens adoptent l'API des champs. Si peu de gens sont prêts à réécrire leur plugin / thème pour Gutenberg, je ne pense pas qu'ils seraient prêts à le faire pour une API Fields. Je pense également que cela a été soulevé quelque part dans un numéro précédent, je vous recommande donc de le rechercher dans l'historique de GitHub et d'ajouter vos réflexions sur la façon dont l'API Fields pourrait bénéficier à Gutenberg.

... il n'est pas possible de s'adapter à tous les cas d'utilisation possibles, je pense qu'un meilleur objectif est peut-être de créer une bonne expérience pour la grande majorité des utilisateurs et des cas d'utilisation.

Je suis d'accord, et 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 la page entière. 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. En outre, la mise en file d'attente d'actifs ne serait pas un problème car elle fonctionnerait comme elle le fait aujourd'hui.

Je suis tout à fait d'accord avec ce concept proposé 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.

Source: https://yoast.com/gutenberg-alternative-approach/

Je suis également tout à fait d'accord avec la proposition avancée par Yoast. Il fournit une bonne étape intermédiaire qui donne aux auteurs de plugins le temps de convertir les métaboxes en nouveaux blocs. Ensuite, dans le cadre du plan de remplacement éventuel de toute l'expérience de l'éditeur, WP en tant que projet peut dire quelque chose comme "Dans les versions x, les métaboxes seront obsolètes", donc nous avons un _plan_ en place pour aller vers un meilleur objectif final.

Il suffit de noter que ce concept casse les métaboxes existantes, car il n'y a pas d'instance TinyMCE centrale avec laquelle communiquer. Au lieu de prendre en charge 80% des métaboxes, cela prendra en charge 90% (j'ai inventé ces chiffres).

Ce concept ne résout pas le problème de compatibilité descendante, mais retarde simplement sa résolution plus tard avec le même problème. Gutenberg est la première étape vers les interfaces JS dans WP et cela ne s'arrêtera pas avec Gutenberg.

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

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

Construisons maintenant le meilleur éditeur possible.

Lorsque nous pensons que la vision idéale de Gutenberg est prête à être expédiée, nous aurons le temps de discuter des stratégies de mise à niveau ...

Je ne pourrais pas être plus en désaccord avec cela. Pourquoi consacrer des milliers d'heures au développement de l'éditeur idéal s'il ne peut pas être rendu compatible avec les sites existants? Si la première impression est que cela brise l'interface utilisateur dont ils dépendent, les utilisateurs ne connaîtront jamais l'éditeur idéal en premier lieu.

Pourquoi consacrer des milliers d'heures au développement de l'éditeur idéal s'il ne peut pas être rendu compatible avec les sites existants?

Juste pour être clair,

• il est impossible d'être 100% compatible avec les sites Web existants, quelle que soit l'option que vous choisissez pour l'éditeur car les plugins ont un accès complet au DOM, toute chose que vous modifiez dans le dom rompt la compatibilité avec les versions antérieures
• Il n'y a qu'une seule façon de garantir une compatibilité descendante à 100% pour toute modification: ne pas effectuer la modification. Le plugin désactivant Gutenberg est déjà disponible.
• L'éditeur est déjà compatible avec un grand nombre de sites Web. Mais comme tout le reste, quand ça casse, c'est toujours plus visible.

il est impossible d'être 100% compatible avec les sites Web existants

Maintenant que cela est clair, construisons l'éditeur que nous pensons être le meilleur pour l'avenir de WordPress s'il vous plaît.

Toutes les métaboxes doivent-elles fonctionner sur mobile?

Oui, pourquoi pas?

Quels sont les cas (le cas échéant) qui ne seraient pas convertis en blocs?

Pour les articles de blog, je comprends pourquoi Blocks For Everything peut avoir du sens, mais cela peut ignorer le cas d'utilisation général des métadonnées: des données qui ne sont pas vues. Par exemple, je peux utiliser une métabox pour exposer l'interface utilisateur afin d'ajouter des données d'analyse à une publication.

Pour des choses comme les types de publication personnalisés, qui pourraient être composés UNIQUEMENT des méta-boîtes, j'ai du mal à comprendre la nouvelle interface utilisateur. Parce que WordPress ne dispose pas d'une API CRUD complète pour les données, de nombreux développeurs utilisent WP_Query et sa suite d'API associées en tant que substitut, et ils utilisent des méta-boîtes sur les écrans d'édition CPT pour isoler l'interface utilisateur pour ajouter des données spécifiques ou les associations. Beaucoup (une majorité) de types de publications personnalisées dans la nature désaccentuent ou ignorent l'utilisation traditionnelle du «contenu» - donc pour les articles de blog, oui, le contenu est au premier plan, mais pour de nombreux cas d'utilisation de CMS, un WYSIWYG ne fait pas beaucoup de sens.

Dans cette itération actuelle, le support de Meta Box est un add-on, alors que dans la réalité de beaucoup de gens, les Meta Box sont l'interface utilisateur, l'API, le mécanisme qu'ils utilisent pour composer leur CMS. <iframe> s sont le goulag.

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

Je terminerai par cet exemple: si l’une de mes «anciennes» méta-boîtes déclenche l’ouverture de l’interface utilisateur pour Media, comment cela fonctionnera-t-il dans ce «nouveau» scénario, à partir d’une iframe, sans personne (un client avec lequel je ne travaille plus ) réécrire le code?

En suivant ces conversations, je ne peux m'empêcher de penser que les pouvoirs en place qui se développent et réalisent les prises de vue concernant Gutenberg n'utilisent pas ou ne traitent pas les métaboxes eux-mêmes. Cela ressemble à une sorte d'argument de la fin-justifier-les-moyens dans lequel il est facile de le dire parce que les moyens ne sont pas significativement valorisés au départ.

Veuillez comprendre que pour beaucoup d'entre nous, nous avons des dizaines de sites qui se cassent instantanément lorsqu'ils sont mis à jour vers WordPress 5.0 - un produit qui a historiquement enseigné aux gens qu'il est sûr de mettre à niveau parce qu'il est maniaque de la rétrocompatibilité. Ce qui est discuté ici n'est pas une rupture mineure (par exemple, le style), mais un éventuel arrêt de spectacle qui rendrait le côté administrateur de milliers (ou plus) de sites instantanément inutilisable. Ce sont des trucs effrayants. En tant qu'industrie, nous avons convaincu les gens de la fiabilité à toute épreuve de WordPress.

Comme @staylor l'a souligné ci-dessus, sur la majorité de nos sites Web (sites d'entreprise de complexité moyenne à élevée), les métaboxes _ sont_ l'interface utilisateur. L'éditeur (s'il est utilisé) n'en est qu'une partie.

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

Je pense que c'est peut-être une erreur de remettre cela trop loin. D'autant plus que de nombreuses organisations auront besoin d'au moins 1 à 2 trimestres pour se préparer.

Il y a un adage que j'ai entendu de la part de plusieurs développeurs principaux de WordPress dont je pense qu'il est important de se souvenir ici: quand quelqu'un adopte WordPress pour son site, il n'adopte pas WordPress 3.7 ou WordPress 4.8, il adopte WordPress. Rendre cette voie aussi transparente que possible est absolument une nécessité. Cela cassera les choses, et ce n'est pas grave (il y a des pauses de compatibilité arrière à peu près toutes les versions de WordPress), mais elles doivent être minimisées, documentées et communiquées.

il est impossible d'être 100% compatible avec les sites Web existants

Si vous n'allez pas être compatible, alors allez certainement casser les choses. Appelez la première version WP ++ ou WPNG. Il est préférable de déclarer à l'avance que les choses vont probablement se briser et de laisser les gens s'y préparer. La "tromperie" actuelle comme si les choses allaient fonctionner comme d'habitude est mauvaise pour tout le monde.

Les iframes sont des impasses en termes de convivialité. A ouvert un widget de sélection de date basé sur jquery dans une méta-boîte et a été surpris lorsque le clic à un autre endroit aléatoire de la fenêtre ne l'a pas fermé. Il m'a fallu une minute pour réaliser que l'événement de clic était sur la fenêtre parente et ne se propageait pas dans l'iframe. J'ai donc été surpris, mais je l'ai finalement compris, mais comment allez-vous expliquer une telle chose aux utilisateurs? Attendez-vous que chaque plugin réponde à la question de chaque utilisateur sur ces attentes UX triviales.
Et comment voulez-vous que les liens externes fonctionnent?

Il y a de bonnes raisons pour lesquelles les gens n'utilisent les iframes qu'en dernier recours.

Ma suggestion productive est de ne pas déclarer la méta-box prête, tant que votre référencement ne fonctionne pas correctement. Il est à la fois légèrement complexe en termes d'interactions et il est installé sur des tas de sites de merde. Si gutenberg ne peut pas fonctionner avec, personne ne l'utilisera probablement.

Ma suggestion productive, est de ne pas déclarer la méta-box prête

Comme l'a souligné @karmatosed ci-dessus: "Il est bon de penser un peu que ce que nous avons aujourd'hui pour les métaboxes à Gutenberg est une expérience, à bien des égards, c'est un schéma d'attente car le projet détermine la direction à prendre. En disant que c'est une cela fonctionne "pour le moment" mais ce n'est pas ce que nous expédierions. "

Pour fournir des données réelles, je souhaite partager cette interface à partir d'un site WordPress sur lequel j'ai travaillé dans le passé. Le champ de contenu est une partie mineure de ce type de publication personnalisé, et bien que certains des champs de métabox personnalisés puissent être convertis en blocs, la majorité contient des données qui sont soit utilisées par l'administrateur, utilisées par un service tiers via l'API REST, ou utilisé pour ajouter des métadonnées à l'entrée. Bien que cela puisse sembler un peu chaotique, cette configuration est conçue spécifiquement pour fonctionner avec le flux de travail du client et utilise un modèle de contenu strict basé sur une séparation claire pour garantir que les futures versions du site puissent gérer chaque type de contenu indépendamment.

Refactoriser ce site pour qu'il fonctionne dans la réalité de Gutenberg prendra beaucoup de temps et nécessitera des ressources substantielles, donc à moins que les métabox ne soient gérées d'une manière qui correspond étroitement à ce qui existe déjà, ce propriétaire de site reviendra probablement à une version antérieure à Gutenberg de WP et restera là pour une durée indéterminée.

Pour référence, bien que cela semble étendu, ce n'est ni la configuration de la métabox la plus complexe que j'ai construite ni la configuration la plus complexe que j'ai vue. Ce que cet exemple montre, c'est la solution de contournement dans le monde réel, via des métaboxes, pour répondre au besoin d'une modélisation et d'une séparation de contenu appropriées au-delà de l'objet blob de contenu, ce que Gutenberg doit gérer avec élégance et fonctionnalité.

Rendre cette voie aussi transparente que possible est absolument une nécessité.

D'accord

Cela cassera les choses, et ce n'est pas grave (il y a des pauses de compatibilité arrière à peu près toutes les versions de WordPress), mais elles doivent être minimisées, documentées et communiquées.

D'accord

il est impossible d'être 100% compatible avec les sites Web existants, quelle que soit l'option que vous choisissez pour l'éditeur car les plugins ont un accès complet au DOM, toute chose que vous modifiez dans le dom rompt la compatibilité avec les versions antérieures

D'accord, je ne pense pas que quiconque soit en désaccord avec vous ici. Cependant, je pense qu'il y a encore de la place pour discuter de ce qui est cassé et quand il est cassé. Ce genre de décisions a également un impact sur le type de travail que les développeurs doivent faire pour réparer tout ce qui est cassé. Il y a une différence significative entre ajuster les choses parce que les sélecteurs dom ont été modifiés, et avoir à réécrire un modèle de contenu personnalisé pour s'adapter au nouveau paradigme de Gutenberg où les métaboxes fonctionnent seulement en quelque sorte :) La controverse autour des métaboxes m'indique que c'est quelque chose qui ne l'est probablement pas une bonne chose pour cibler la rupture dans la version initiale de Gutenberg dans core.

Je _get_ que tout cela est une expérience, je pense que @kevinwhoffman le fait aussi. Je vois cette question comme une _évaluation_ bien pensée de cette expérience et elle devrait être considérée comme telle. Cette expérience suffira-t-elle comme solution finale? Non. Alors, quelle est la prochaine expérience?

Je ne pense pas non plus que nous verrons une énorme augmentation des développeurs convertir leur travail existant vers Gutenberg jusqu'à ce qu'une proposition de fusion soit en place, dans cet esprit, ce qui est cassé dans la version initiale de Gutenberg _does_ importe.

tldr; Attendons-nous une rupture avec Gutenberg? Oui! Mais nous devons toujours être sélectifs sur _ce_ que_ nous cassons, et jusqu'où va cette rupture dans l'itération _initial_ de Gutenberg fusionné avec le noyau.

Oui, nous avons tous suffisamment travaillé sur le développement de WordPress pour nous attendre à ce que certaines choses se cassent d'une version à l'autre. Et d'une manière c'est exactement ce que je veux dire. Tant que nous présentons Gutenberg comme une simple mise à jour WordPress, cela ne devrait rien casser de plus ou de moins que toute autre mise à jour. Si nous rompons cette confiance, peu importe la qualité de l'éditeur à la fin de la journée.

Voici une capture d'écran actuelle d'un plugin que j'ai développé au cours des derniers mois. Dans cette situation, un éditeur visuel n'a aucune valeur, et essayer de trouver le type d'interface nécessaire dans une interface conçue pour l'édition visuelle de contenu n'a aucun sens.

En fait, je me demande sérieusement si je devrais même prendre la peine de continuer à développer cela pour WordPress, étant donné que tout mon travail pourrait être annulé avec la prochaine version.

Comme vous pouvez le voir, j'ai besoin d'accéder au téléchargeur de médias dans mes méta-champs, et reléguer la majorité de la page à une iframe rendrait cette interface extrêmement maladroite.

Il existe des millions d'interfaces comme celle-ci dans les plugins, les outils et les sites personnalisés, construits sur WordPress. Traiter ces utilisateurs comme des citoyens de seconde zone, en faveur de la "nouvelle chaleur" des blocs est inacceptable. Les métabox doivent conserver leur niveau actuel d'intégration et de visibilité dans la page d'édition.

Je soutiens fortement le point de vue de Yoast sur Gutenberg. Je ne sais pas comment "mettre à niveau l'éditeur visuel" a été réinterprété pour être "remplacer l'intégralité de l'interface d'édition de publication" 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 de direction claire et de prise en charge des flux de travail standard existants nuit activement aux développeurs. Comment puis-je progresser dans la construction d'un projet, sans un ensemble de crochets et d'outils fiables sur lesquels je peux compter? Il est inadmissible de penser qu'un projet logiciel aussi important bouleverserait entièrement le flux de travail standard des développeurs en une seule mise à jour. et il est insensé que ces conversations aient lieu maintenant, en novembre, alors que le plan est de faire approuver une fusion au début de l'année.

@aaronjorbin bien, il semble qu'il y ait un problème de communication ici comme dans https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ il a été explicitement dit

Cette version inclut le support tant attendu des méta-boîtes (nécessite des tests!),

ce n'est pas une «idée», ce n'est pas une «expérience», c'est juste quelque chose qui, comme tout logiciel, peut encore inclure des bogues. Je ne l'aurais pas testé si cela s'appelait «une expérience» dans ce post.

Revenant sur le sujet, je vois que le problème principal ici est la tentative d'éviter de déclarer une casse. D'après ma compréhension limitée des framewoks JS, il est très difficile d'être "à moitié enceinte" avec eux, et une fois que vous avez décidé que votre contrôle d'écran principal est fait avec eux, tout doit être fait avec eux, donc la seule façon d'avancer est de faites des méta-boîtes des citoyens de première classe dans l'écran d'édition de gutenberg.
Comme il est peu probable que les plugins "hérités" s'adaptent, cela signifie que gutenberg doit être une option d'acceptation explicite pour les sites existants. Je déteste l'idée d'un fork UX, mais au moins de cette façon, il y aura une voie à suivre qui fonctionnera, et si elle est déclarée maintenant, les gens pourront se préparer.

Après avoir lu la discussion et réfléchi aux projets que je construis avec WordPress, et aux choses que je vois faire avec WordPress, je suis arrivé à la conclusion que Gutenberg devrait accepter les types de publication personnalisés. Cela permettra aux sites Web actuels qui utilisent CPT pour des données structurées de continuer à fonctionner et à de nouveaux sites Web sur lesquels WordPress est utilisé comme CMS à construire. Je veux juste vous rappeler que lors de l'enregistrement d'un type de publication, nous pouvons explicitement déclarer le support du champ éditeur avec d'autres fonctionnalités. Alors pourquoi ne pas simplement ajouter un support explicite pour Gutenberg là-bas? Bien sûr, cela ne résoudra pas le problème avec les méta-boîtes ajoutées aux articles et aux pages, mais cela permettra à WordPress d'être utilisé comme CMS à l'avenir.

Peut ajouter un nouveau problème avec ces iframes. Lorsque la session utilisateur disparaît, l'écran de connexion WP est affiché deux fois sur Gutenberg et dans l'iframe.

Juste pour que les développeurs en soient conscients.

Plus je suis tout cela, plus je suis convaincu que la seule façon possible serait comme Microsoft l'a fait.

Windows XP = WordPress sans Gutenberg
Windows 10 = Wordpress avec Gutenberg.

Ces 2 ne peuvent pas être mélangés et mis à jour avec les packages d'un autre.

Joomla et Drupal l'ont fait. Pourquoi pas. Pas quelque chose que je préfère du tout, mais quelle alternative.

Après avoir lu la discussion et réfléchi aux projets que je construis avec WordPress, et aux choses que je vois faire avec WordPress, je suis arrivé à la conclusion que Gutenberg devrait accepter les types de publication personnalisés.

Un administrateur séparé serait l'un des pires résultats qui puissent sortir de Gutenberg. J'ai expliqué les raisons pour lesquelles dans https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490.

Cette discussion devient vraiment kafkaïenne. Il semble que peu importe le nombre de personnes qui proposent des règlements pragmatiques aux points douloureux actuels, il y a quelques personnes clés qui semblent complètement insensibles à la critique. Malheureusement, ce sont ces personnes qui ont le dernier mot, car jusqu'à présent, la discussion a montré que quelques personnes clés peuvent écraser des centaines de développeurs inquiets. Je m'inquiète de tous les dommages que cela fait à l'écosystème WordPress. Faites de Gutenberg l'éditeur, pas l'écran d'édition. Ne cassez pas WordPress.

Kevin Hoffman:

Je suis tout à fait d'accord avec ce concept proposé 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. Source: https://yoast.com/gutenberg-alternative-approach/

Je pense que la voie à suivre proposée par Yoast serait une grande amélioration de WordPress Core. Un nouvel éditeur pour créer du contenu, que de nombreux utilisateurs adopteraient comme une amélioration par rapport à l'actuel. Un pas plus petit pour WordPress, mais une grande amélioration pour l'utilisateur.

C'est un sujet passionné. J'avoue que parfois nous (du moins moi) pouvons être dédaigneux dans mes commentaires et je m'en excuse. Nous recevons beaucoup de retours, bons, mauvais, objectifs, inutiles et parfois il est difficile de les distinguer. Nous sommes humains. Essayez d'être de l'autre côté de l'équation, soyez le seul à construire cette chose et à recevoir tous ces commentaires. Il peut sembler proche des «attaques personnelles», les cerveaux ont tendance à réagir en étant dédaigneux, nous ne devrions pas.

Les gens qui commentent et lisent des articles de blog pensent souvent que nous découvrons les problèmes des méta-boîtes et tout ce qui y est lié. N'étaient pas. Nous travaillons sur Gutenberg depuis un an maintenant. Peut-être que vous venez de découvrir / essayé Gutenberg, mais nous ne le faisons pas, nous y travaillons assez longtemps maintenant pour être à l'aise avec la plupart des problèmes de compatibilité descendante et nous avons des réponses pour la plupart d'entre eux.

S'il vous plaît, soyez ouverts d'esprit, et commençons par répondre à quelques questions:

Quel est le but de Gutenberg?

Ce n'est pas, et cela ne l'a jamais été, l'objectif principal de Gutenberg est d'ouvrir la voie à l'avenir de WordPress Core. Techniquement, en tirant parti de l'API REST, de l'interface utilisateur côté client et de l'unification des concepts de base: widgets, codes courts, blocs, métaboxes de contenu sous un concept unique «A Block» et expérience en répondant à ces questions: Comment simplifier la création de sites Web (pensez aux personnalisations) et publier du contenu (pensez éditeur) dans WordPress.

Quel est le but de l'éditeur Gutenberg?

Contrairement à ce que vous lisez ici et là, l'accent a toujours été mis sur la refonte de la page entière.La première maquette de la page de l'éditeur Gutenberg a été présentée lors de la deuxième ou troisième réunion hebdomadaire de Gutenberg. Nous étions encore en phase de prototypage. Des mois avant le premier alpha. Le design était proche de ce que nous avons actuellement.

Qu'en est-il des Metabox, sont-ils importants pour WordPress?

Elles sont. Comme les codes courts, les boutons TinyMCE personnalisés, ils sont largement utilisés et abusés pour étendre la page de l'éditeur de WordPress.

Quelle est la différence entre les codes courts, les boutons TinyMCE et les métaboxes?

La principale différence est que les «Metaboxes» n'ont pas de «but», c'est juste un moyen d'étendre la page de l'éditeur sans cohérence alors que les boutons Shortcodes et TinyMCE en ont un.

Les shortcodes sont une chaîne convertie en contenu dans la phase de rendu, les boutons TinyMCE sont des boutons personnalisés ajoutés à la barre d'outils TinyMCE et utilisent l'API TinyMCE pour communiquer avec le contenu de l'éditeur. Métaboxes? Je ne sais pas, ils peuvent être n'importe quoi, il vous suffit d'ajouter un tas de HTML, Javascript et PHP pour étendre la page de l'éditeur et comment il se comporte lors de la sauvegarde.

Cette absence de «but» est-elle un problème ou un avantage?

Bien! Cela peut être considéré comme un «pro», car un plugin peut faire tout ce qu'il veut avec l'éditeur, y compris des choses comme:

• Remplacement de n'importe quel bouton, zone de texte, entrée, div, n'importe quoi. Accès complet au DOM
• Utilisation de n'importe quelle variable javascript globale, y compris l'instance globale de TinyMCE

Droit flexible! Mais qu'en est-il des mises à jour de WordPress. Toute mise à jour de l'écran de l'éditeur. Toute mise à jour de TinyMCE, tout changement de classe, tout nouveau div , tout bouton supprimé / déplacé, tout changement rompt la compatibilité avec les plugins car en tant que développeur WordPress Core, vous ne savez pas pour quels plugins utilisent les métaboxes.

Pouvons-nous en conclure que pour le long terme de WordPress, les Metabox verrouillent son évolution (quel que soit Gutenberg)?

Oui, ils sont. Et l'histoire d'Internet l'a prouvé tant de fois qu'une technologie qui n'évolue pas meurt. (veuillez ne pas réagir avec 👎 Si vous n'aimez pas cette réponse, c'est un fait et non une opinion)

Ok, mais alors comment pouvons-nous faire avancer WordPress si nous sommes coincés avec les métaboxes?

C'est une bonne question et avant de répondre, nous devons comprendre l'utilisation actuelle des métaboxes dans les plugins WordPress

Pourquoi les plugins actuels utilisent-ils les Metaboxes?

Je dirais qu'il existe deux catégories de plugins «Metaboxes»:

• Métaboxes en tant que contenu (souvent stockées dans des méta post mais pas toujours)
• Les métaboxes comme amélioration de l'expérience de l'éditeur (SEO, correcteur orthographique,…)

Ok, sachant cela, comment pouvons-nous avancer?

Nous avons besoin de trois choses:

• Fournir un moyen de créer ou de mettre à niveau ces plugins pendant la livraison de Gutenberg (ou de toute mise à jour de WordPress).
• Fournissez les meilleurs chemins de mise à niveau possibles pour les personnes utilisant ces plugins. Cela comprend: voir si ces plugins peuvent toujours fonctionner avec les évolutions à venir et comment minimiser la casse.

Ok, mais n'avez-vous pas dit que toute modification de la page de l'éditeur cassera les plugins (y compris le remplacement uniquement de la zone de contenu)?

Droite! Donc, si notre souhait est de ne casser aucun plugin, il nous reste une option unique. Fournit un moyen de rester avec la page d'édition actuelle sans changement. C'est exactement à cela que sert le plugin désactivant Gutenberg.

Personnellement, je n'appellerais pas cela une bonne voie de mise à niveau, ce n'est même pas une mise à niveau, rien de mieux?

Ce chemin de mise à niveau (désactiver Gutenberg) est une nécessité mais oui, nous pouvons faire mieux. Si vous regardez les plugins utilisant des métaboxes, 90% d'entre eux n'ont aucune interaction avec la zone de contenu, donc, si nous remplaçons uniquement la zone de contenu (approche yoast), nous ne casserons que 10% des plugins.

Donc, le seul moyen sans casse est de désactiver Gutenberg.

L'expérience utilisateur optimale de Gutenberg consiste à remplacer les plugins de métaboxes par des plugins offrant les mêmes fonctionnalités avec les nouvelles API d'extensibilité de Gutenberg.

Cela dit, nous avons remarqué que la plupart des plugins utilisant des métaboxes les utilisent comme contenu enregistré pour publier des méta et nous pouvons les faire fonctionner dans l'écran Gutenberg pour profiter de toute l'expérience pendant que les auteurs de plugins mettent à jour leurs plugins.

Est-ce la solution iframe dont tout le monde parle?

Oui, ça l'est. Nous montrons les meta box dans des iframes qui ont ses inconvénients (lien, modals, ressources de rechargement) mais en même temps cela permet à 80% des plugins de fonctionner tout en profitant de toute l'expérience Gutenberg. Cette solution vient d'arriver et nous l'expérimentons toujours. Ce qui est certain, c'est qu'il n'y a aucun moyen de faire fonctionner toutes les métaboxes et d'apporter des modifications à l'éditeur.

Je vois, pouvez-vous récapituler les possibilités de mise à niveau s'il vous plaît?

Sûr.

1- Désactiver Gutenberg: ne cassez pas 100% des plugins
2- Gutenberg ne remplace que la zone de contenu: 90% des plugins fonctionnent, l'UX en souffre
3- Gutenberg remplace tout l'écran: 80% des plugins fonctionnent, l'UX est meilleur
4- Gutenberg avec plugins compatibles: Meilleur UX possible

Alors, que devons-nous faire?

Notre objectif est de créer la 4ème option car c'est la meilleure option pour l'avenir de WordPress. Notre objectif est également de construire Gutenberg de manière à pouvoir réutiliser ses pièces pour atteindre les 2ème et 3ème options si nécessaire.

Comment puis-je opter pour une option plutôt qu'une autre?

Cela n'a pas encore été décidé. Avoir un plugin pour choisir le chemin de mise à niveau que vous voulez est une possibilité. Rétrograder automatiquement en détectant certaines Metaboxes est une option ...

C'est mon avis pour expliquer le raisonnement derrière ces problèmes, s'il vous plaît si vous voulez répondre avec des mots comme «ridicule», «mal géré», «mauvaise mise en œuvre» ... ma patience en tant que simple développeur qui a passé toute l'année à réfléchir au La meilleure voie à suivre pour WordPress dans son ensemble (noyau et communauté) est proche d'une limite. Personnellement, je ne répondrai peut-être pas davantage sur cette question, mais j'écoute les commentaires et j'adapterai mon raisonnement si je suis convaincu par les commentaires.

Nous sommes tous sur le même bateau, nous voulons le meilleur pour WordPress.

Explications très approfondies, Riad. Merci d'avoir pris le temps de les écrire. Laissez-moi vous aider à éviter cette limite avec un a et un 🤗. J'espère que cela aide.

En ce qui concerne les métaboxes, je serais extatique d'avoir une API Fields dans le noyau. Réécrire nos plugins juste pour se débarrasser de toutes les solutions de métaboxes personnalisées qui ont tendance à se rassembler après un certain temps.

Désormais, pour les personnes qui ont des configurations de métaboxes complexes, l'API Fields est leur salut tant qu'elles les ont construites sur un framework comme ACF ou CMB. Les développeurs de ces frameworks ont juste besoin de passer à la nouvelle API et tout va bien. Pas une tâche facile, mais bonne pour tout le monde. Maintenant, pour ceux qui ont des trucs "codés en dur" qui traînent, maintenant c'est le meilleur moment que jamais pour réorganiser les choses d'une manière plus propre et plus évolutive. Vous êtes en meilleure forme, Gutenberg ou pas.

Nous sommes humains. Essayez d'être de l'autre côté de l'équation, soyez le seul à construire cette chose et à recevoir tous ces commentaires. Il peut sembler proche des «attaques personnelles», les cerveaux ont tendance à réagir en étant dédaigneux, nous ne devrions pas.

Il y a des humains qui travaillent très dur sur Gutenberg. Il y a des humains dont les moyens de subsistance (leurs thèmes et plugins) seront affectés par Gutenberg. Et il y a des humains qui utilisent les thèmes et les plugins affectés par Gutenberg pour faire leur propre travail. Nous nous recherchons tous et voulons le meilleur pour WordPress à la fin de la journée. Bien que nous puissions être passionnément en désaccord sur ce que signifie «meilleur».

Contrairement à ce que vous lisez ici et là, l'accent a toujours été mis sur la refonte de la page entière.La première maquette de la page de l'éditeur Gutenberg a été présentée lors de la deuxième ou troisième réunion hebdomadaire de Gutenberg ...

Les maquettes seules n'ont pas indiqué que la base de code de la page d'édition entière serait réécrite dans React. Personne n'aurait pu savoir en regardant une maquette que les crochets critiques seraient supprimés ou les méta-boîtes brisées. Cependant, quand il est devenu évident pour moi que la prise de contrôle d'une page entière poserait un problème pour les méta-boîtes, j'ai exprimé cette préoccupation le 15 juin , la veille du tag de publication de 0.1.0 . Quatre mois et 15 versions plus tard, c'était la première fois que nous voyions des méta-boîtes apparaître dans l'interface, dans des iframes.

J'ai créé ce numéro sur la base de mon expérience en suivant de près et en testant Gutenberg depuis ses étapes pré-alpha. Ce n'est que le dernier numéro lié aux défis de la méta-box en cours, mais surtout, c'est le premier basé sur des tests concrets d'une implémentation de méta-box de Gutenberg.

La principale différence est que les «Metaboxes» n'ont pas de «but», c'est juste un moyen d'étendre la page de l'éditeur sans cohérence alors que les boutons Shortcodes et TinyMCE en ont un.

Cela signale à nouveau un malentendu fondamental sur la façon dont les méta-boîtes sont utilisées par les développeurs d'extensions et de thèmes. Nous prévoyons que les codes courts et les boutons TinyMCE devront être adaptés car ils sont réellement utilisés dans l'éditeur de contenu. Les méta-boîtes ne le sont pas.

Suggérer que les méta-boîtes - les blocs de construction fondamentaux du développement WordPress personnalisé - n'ont aucun but, indique à nouveau à la communauté que Gutenberg donne la priorité à l'expérience de base d'une «nouvelle installation» aux dépens des développeurs de plugins et de thèmes.

Toute mise à jour de l'écran de l'éditeur. Toute mise à jour de TinyMCE, tout changement de classe, tout nouveau div, tout bouton supprimé / déplacé, tout changement rompt la compatibilité avec les plugins car en tant que développeur WordPress principal, vous ne savez pas pour quels plugins utilisent les métaboxes.

Nous ne connaissons peut-être pas le but d'une méta-boîte, mais nous connaissons les exigences fondamentales pour enregistrer une méta-boîte et les crochets qu'ils utilisent. Nous savons qu'aucun d'entre eux n'a été développé pour fonctionner dans des iframes. Pendant des années, nous avons compris comment étendre et améliorer WordPress sans les casser. Encore une fois, si 5.0 n'est qu'une autre version de WordPress, le montant de la rupture ne devrait pas être différent de celui de toute autre version.

Nous montrons les meta box dans des iframes qui ont ses inconvénients (lien, modals, ressources de rechargement) mais en même temps cela permet à 80% des plugins de fonctionner tout en profitant de toute l'expérience Gutenberg.

Si vous avez des preuves de ces chiffres de 80% / 90% qui sont constamment référencés, veuillez les partager. Sinon, n'utilisez pas de statistiques hypothétiques lorsque vous demandez à la communauté de prendre une décision de cette ampleur.

Veuillez arrêter et réévaluer maintenant, pas plus tard

Après toute cette discussion et ce que je pensais être la preuve que les iframes ne sont pas une solution viable à long terme, je suis tombé sur https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059 qui cherche à en ajouter un troisième iframe à Gutenberg.

Il est plus que temps d'arrêter de rechercher l'éditeur idéal comme si les limitations n'existaient pas et de commencer à envisager une approche qui ne rompt pas WordPress.

Parlant en tant que développeur qui a regardé et discuté de l'éditeur Gutenberg depuis le premier jour, je suis désolé de dire que l'argument de Riad comporte de gros trous.

Premièrement, les gens ont soulevé la question des métaboxes depuis le premier jour, ainsi que plusieurs autres problèmes qui sont toujours en suspens. dans la phase de maquette, on nous a dit "tout est un meilleur cas visuel, nous aborderons les métaboxes plus tard". Ensuite, dans la phase de prototype, c'était "Tout cela est du code de preuve de concept, les métaboxes seront traitées plus tard". Puis, lorsque la première itération du plugin de fonctionnalité a été publiée (ce qui n'a été, comme une énorme surprise pour personne, pas une réécriture à partir de zéro après tout, et juste un reconditionnement du code de preuve de concept actuel), l'argument est soudainement devenu "les interfaces héritées comme les métaboxes auront un certain support pour le moment". Puis, quand le tollé public est devenu assourdissant, c'était "nous nous sommes mal exprimés, les métaboxes ne sont pas héritées". Mais maintenant, cet argument ne fait que repousser l'agenda de «l'héritage».

Les métabox ne sont pas du code hérité, car il n'y a actuellement aucun remplacement viable.

Dans les métaboxes, je peux facilement ajouter un éditeur imbriqué complet en utilisant wp_editor . Gutenberg n'a actuellement pas d'interface utilisateur pour les blocs imbriqués, et il n'est pas prévu pour la version 5.0, il ne peut donc pas faire l'équivalent, sans une quantité massive de code d'interface utilisateur personnalisé.

C'est un exemple unique, mais dégrader l'expérience des métaboxes n'est pas une solution acceptable, tant que Gutenberg n'est pas au-delà de la parité. Cela n'arrivera pas avec WP 5.0

Voici une feuille de route vers le plan «d'administration unifiée» pour Gutenberg qui fonctionnerait réellement:

• limiter la version initiale à la zone actuellement peuplée par wp_editor, mais fournir l'interface utilisateur du bloc complète dans cet espace
• promouvoir et étendre la flexibilité et les capacités que le bloc ui permet, en expédiant une API de champs qui rend la conception simple dans cet espace
• à mesure que la popularité augmente, remplacez d'autres parties de l'interface utilisateur par des instances Gutenberg similaires en bac à sable. Les menus, les widgets, le personnalisateur et la médiathèque sont tous des interfaces relativement stagnantes pour les développeurs et qui pourraient bénéficier d'une structure d'interface utilisateur commune.
• à mesure que l'interface utilisateur commune devient plus flexible et plus puissante, les utilisateurs choisiront de l'utiliser sur des métaboxes, car elle offre un ensemble d'outils communs et plus d'options
• fusionne progressivement les trous entre les instances isolées de Gutenberg, à mesure que le développement dans ces espaces stagne.

De cette façon, les développeurs peuvent commencer à utiliser Gutenberg sur des outils de production sans perdre les capacités actuelles dont ils disposent. Gutenberg bénéficiera de tous les cas d'utilisation de pointe développés pour ces développeurs, créant une solution flexible qui répondra réellement aux besoins de ceux qui utilisent actuellement des métaboxes.

Au moment où les métaboxes seront obsolètes, les auteurs de plugins auront eu suffisamment de temps pour apprendre et utiliser les avantages de Gutenberg dans la nature, et ce sera le choix évident.

Gutenberg est comme un concept-car. Remettez à l'échelle maintenant et envoyez une amélioration itérative à l'éditeur (pas à la page de l'éditeur). Ensuite, au cours de l'année ou des deux prochaines, vous pouvez diriger le projet vers une couverture administrative à 100%.

Je veux juste parler du point de vue d'un fournisseur de services client qui a fait référence à l'engagement vocal de WordPress en faveur de la compatibilité ascendante pour atténuer les préoccupations des clients concernant les mises à jour interrompant leurs sites Web. Avec cela, je reconnais que mon utilisation de WordPress a probablement faussé / biaisé ma perception de l'écran d'édition.

À ce jour, on a l'impression que ce problème a été écarté / rejeté / minimisé alors que dans mon monde, les méta-boîtes ont été un argument de vente majeur pour WordPress depuis que les types de publication personnalisés sont devenus facilement disponibles pour une utilisation généralisée. Je suis content que cette discussion ait lieu.

Gutenberg est un projet impressionnant, oui, mais les clients avec lesquels j'ai travaillé sont vraiment très satisfaits des solutions basées sur les méta-boîtes qui leur ont été fournies. Avoir une option pour désactiver Gutenberg est bien, mais je suis préoccupé par le fait qu'elle soit désactivée via un plugin. Malgré mes meilleurs efforts pour coacher les clients, je n'imagine pas qu'ils seraient prêts à installer un nouveau plugin par eux-mêmes, et ils ne sauraient pas non plus ce qu'est Gutenberg, même s'il est manifestement présenté sur un écran de bienvenue de mise à niveau.

Il est possible (peut-être même probable) que les plugins de méta-boîte que j'ai utilisés sur les sites clients puissent être mis à jour pour être "compatibles Gutenberg", mais même dans ce cas, tout le flux de travail va changer pour ces clients du jour au lendemain. On a l'impression de demander à beaucoup de ces clients quand leur flux de travail existant a bien fonctionné pour eux depuis que leur site a été livré il y a bien longtemps.

Je soutiens pleinement l'objectif de Gutenberg d'améliorer l'expérience utilisateur, mais à mon avis, nous ne pouvons pas éviter le précédent qui a été mis en place (intentionnellement ou non) pour utiliser des méta-boîtes pour l'édition de contenu. Je pense que l'approche de Yoast est excellente, c'est quelque chose qui coche un certain nombre de cases à cocher pour une grande variété de solutions potentielles à ce problème.

Juste mes deux cents, j'ai hâte d'observer le résultat ici.

Le nombre de plugins fonctionnant avec Gutenberg peut être de 80%, 90% ou 0% comme dans nos tests, ce qui doit être évité est que des milliers et des milliers de propriétaires de sites doivent savoir par eux-mêmes si leur configuration fonctionnera probablement ou ne fonctionnera pas avec Gutenberg. Ce serait une énorme perte de temps (= argent), causerait beaucoup de confusion et tuerait beaucoup de confiance.

Je voudrais voir les plugins / thèmes marqués comme compatibles / non compatibles avec Gutenberg (ou `` non pertinents ''), afin que les propriétaires de sites puissent être informés des problèmes potentiels avant que cette chose ne devienne active sur leurs sites et puissent agir en conséquence. Les données pourraient non seulement provenir des propriétaires de plugins, mais aussi des tests de la communauté pendant la période de test bêta (la vraie bêta ..., et cette période devrait être longue, pas seulement quelques semaines) et au-delà.

Je suis conscient que cela ne sera jamais complet ou précis à 100%, mais devrait être faisable pour les plugins les plus importants.

PS.
Pour mes propres projets (une plateforme de microsites intranet pour un client de plus de 30 000 employés, et un tas de sites de petites entreprises / à but non lucratif), nous avons décidé de désactiver Gutenberg jusqu'à ce qu'il soit au moins un an avec succès dans la nature.

De toute façon, les pourcentages ne racontent pas toute l'histoire. Toute discussion sur l'impact de Gutenberg doit tenir compte du nombre de sites Web affectés par sa mise en œuvre de la métabox, plutôt que du nombre de plugins concernés. Gutenberg ne pourrait avoir un impact que sur une poignée de plugins et affecter encore des millions d'utilisateurs, car certains des plugins les plus utilisés dépendent des métaboxes et des champs personnalisés - ACF et Yoast SEO en sont deux exemples évidents.

Je suis le développement de Gutenberg de loin depuis plusieurs mois maintenant et je sais que la question des métaboxes existe depuis longtemps. Je soutiens la philosophie derrière Gutenberg et je pense que Gutenberg finira par devenir une partie très puissante du noyau WordPress qui permettra à WordPress d'être un logiciel viable et compétitif pendant de nombreuses années dans le futur. Je suis tellement à bord avec tout le concept de Gutenberg et son objectif.

Ce que je ne comprends pas, c'est le désir de passer de 0 à 100 en une seule fois. Pourquoi une version itérative n'est-elle pas le chemin emprunté ici? Pourquoi les deux options «ne cassent rien» ou «cassent tout»?

Les métaboxes sont la raison pour laquelle WordPress est aussi puissant qu'il l'est. Son but est d'étendre l'écran d'édition.

Je pense que c'est génial que Gutenberg veuille refondre tout l'écran, mais je ne pense tout simplement pas que ce soit réaliste de le faire en une seule fois, surtout si cela signifie traiter l'un des composants les plus importants de WordPress (en ce qui concerne le développement personnalisé ... ce qui est une énorme partie du succès de WordPress) en passant.

2- Gutenberg ne remplace que la zone de contenu: 90% des plugins fonctionnent, l'UX en souffre

L'UX ne souffre pas. Les utilisateurs le verront comme la section de l'éditeur en cours de réorganisation. Cela leur donnera une nouvelle façon de créer du contenu - une façon que la plupart d'entre eux trouveront stimulante après s'être ajustées, et cela ne rompra aucun flux de travail existant ou ne les laissera pas se demander comment accomplir les choses qu'ils avaient l'habitude d'accomplir. l'éditeur.

4- Gutenberg avec plugins compatibles: Meilleur UX possible

C'est un excellent objectif, mais c'est l'objectif à long terme. Finalement oui, absolument, cela devrait être Gutenberg avec des plugins qui fonctionnent avec ou à l'intérieur de l'expérience Guteneberg.

Notre objectif est également de construire Gutenberg de manière à pouvoir réutiliser ses pièces pour atteindre les 2ème et 3ème options si nécessaire.

Je ne sais pas vraiment ce que cela signifie. Vous voulez construire Gutenberg en supposant que les plugins fonctionnent tous avec lui, et utiliser cette solution pour revenir aux options 2 et 3? Construire d'abord vers 2 puis itérer vers 3, n'est-ce pas ce qui va nous amener à 4?

J'aime la feuille de route proposée par @gschoppe , en tant que développeur qui crée des sites Web WordPress personnalisés, c'est une approche que je peux

Parallèlement aux préoccupations de Kevin concernant les iframes, j'aimerais souligner quelques problèmes d'accessibilité. Premièrement, alors que les utilisateurs qui font l'expérience visuelle d'un site verront les jeux de cadres et les iframes comme un tout cohérent avec le reste de la page, ce n'est pas le cas pour les utilisateurs de lecteurs d'écran. Les utilisateurs de lecteurs d'écran font l'expérience de chaque image dans un jeu de cadres, et chaque iframe, comme une partie distincte, séparée du reste de la page, car les pages Web sont vécues de manière linéaire. Certains lecteurs d'écran (notamment Jaws pour Windows, qui est celui qui détient le plus de parts de marché selon l'enquête annuelle sur l'utilisation des lecteurs d'écran de WEBAIM), ont un paramètre de configuration pour ignorer les cadres, y compris ceux en ligne, car ils peuvent être si choquants pour certains écrans. utilisateurs lecteurs. Lorsque le paramètre Ignorer les cadres est appelé, le contenu des cadres et des iframes disparaît. Même si Gutenberg suit toutes les meilleures pratiques d'accessibilité en ce qui concerne les iframes, demander aux utilisateurs de désactiver ce paramètre dans le but de pouvoir modifier complètement le contenu les expose également à chaque instance d'iframe et aux pires cadres sur le net. La seule autre alternative pour ces utilisateurs est de leur demander de créer un profil séparé juste pour utiliser Gutenberg, ce qui n'est pas un processus simple, car cela signifie qu'ils doivent configurer à nouveau chaque paramètre de navigateur et paramètre de parole. Cela signifie également qu'ils doivent ensuite suivre au moins deux profils de navigateur distincts. Je serai la première personne à dire à Jaws pour les utilisateurs Windows de migrer à plein temps vers NVDA pour des raisons. Gutenberg utilisant des iframes pour la prise en charge de la métabox n'est pas l'une de ces raisons.

.. ma patience en tant que simple développeur qui a passé toute l'année à réfléchir à la meilleure voie possible pour WordPress dans son ensemble (noyau et communauté) est proche d'une limite.

Je jure que je déteste être impoli, mais vous devrez peut-être avoir une peau plus épaisse dans ce cas. Vous êtes frustré par les réponses face à une «année entière» que vous avez passée à y réfléchir, et merci de le faire, mais ce sont des décisions qui vont avoir un impact sur

Dans mon cas, d'après ce que je lis, presque tous les sites Web que j'ai construits au cours des 3 dernières années peuvent se briser instantanément. Je ne suis plus responsable de ces sites, mais que va-t-il se passer dans l'agence où je travaillais lorsque des dizaines de clients appellent en même temps avec des sites défectueux. Quel impact cela aura-t-il sur cette petite agence, son travail quotidien, ses résultats? Quel impact cela aura-t-il sur leurs clients? Ce sont mes préoccupations et je ne suis qu'un petit développeur (au sens figuré) dans cet écosystème relativement vaste.

J'avoue que parfois nous (du moins moi) pouvons être dédaigneux dans mes commentaires et je m'en excuse.

Les gens sont inquiets et frustrés et il me semble qu'ils ont tout à fait le droit de le faire parce que la perception est que l'équipe qui travaille sur Gutenberg a peu de compréhension de la façon dont les méta-boîtes sont utilisées, peu de souci pour quel sera l'impact, et va aller de l'avant avec leur vision quoi qu'il arrive.

Cela me rend triste d'écrire ceci, mais je ne suggérerais pas dans un million d'années à quiconque de démarrer un projet majeur avec WordPress en ce moment.

2- Gutenberg ne remplace que la zone de contenu: 90% des plugins fonctionnent, l'UX en souffre

@youknowriad , comment pouvez-vous dire que l'UX ne souffre pas avec Gutenberg par rapport à TinyMCE? Je pose vraiment cette question, pas grognon. Je peux vous dire que l'UX souffre en effet énormément à Gutenberg par rapport à TinyMCE et aux méta box. Je vous encourage à le découvrir par vous-même en:

(1) Débranchez votre souris.
(2) Si vous utilisez un Mack, appuyez sur commande + f5 et essayez de faire quelque chose de productif avec VoiceOver.
(3) Si vous êtes sur un PC, téléchargez NVDA, installez-le, débranchez votre souris et effectuez le même test. Essayez de faire quelque chose de productif avec Gutenberg dans ces circonstances.

Je pense que vous trouverez que l'UX est un cauchemar absolu à ce stade. Cela ne veut pas dire que cela ne peut pas changer pour le mieux. Gutenberg offre à WordPress l'occasion de se débarrasser de beaucoup de dette technique en matière d'accessibilité, et si cela est fait avec soin et correctement, alors d'énormes réalisations peuvent être obtenues. Mais si cela est fait de manière incorrecte ou imprudente, une grande partie du travail effectué par l'équipe d'accessibilité de WordPress et d'autres contributeurs principaux depuis 2012 devra être recommencée. Je voudrais voir WordPress comme un projet ne pas commettre la même erreur avec laquelle il a commencé: ne pas considérer l'accessibilité du Web dès le départ, ce qui signifie que l'équipe d'accessibilité et d'autres contributeurs concernés se sont retrouvés à boulonner sur l'accessibilité après coup, ce qui est une tâche cela ne peut jamais être rattrapé, car WordPress n'est pas une base de code stagnante.

Je comprends que vous travaillez sur Gutenberg depuis un an. Je comprends aussi que travailler là-dessus est difficile en soi, et que les commentaires négatifs n'aident pas cette situation. Enfin, je comprends qu'il peut sembler que ceux d'entre nous qui sont aussi critiques que nous peuvent sembler appeler votre bébé laid, ou simplement réagir à la peur du changement, et en tant que créateur, c'est au mieux frustrant et au pire blessant. . Mais pour moi, le bébé n'est pas moche. Il a beaucoup de potentiel non réalisé pour être soit le gamin le plus cool du quartier, soit le petit con qui rend la vie de tout le monde misérable. J'aimerais que ce soit le premier et non le second. En ce qui concerne les méta-boîtes en particulier, elles sont un élément essentiel du développement personnalisé de WordPress, probablement plus que les codes courts ou les boutons TinyMCE. Ils ne doivent pas être brossés à la légère ni poussés dans une iframe jusqu'à ce que nous puissions trouver comment s'en débarrasser.

Mon histoire simple avec WordPress est qu'il a été mon moteur de site Web de choix pour créer des sites Web pour les particuliers, les petites entreprises et les entreprises depuis plus d'une décennie. À cette époque, trois choses ont fait de WordPress l'outil de choix:

1. Open source. Je pense que ce public peut convenir à quel point cela est puissant et avantageux.
2. Facilité d'utilisation. WordPress a rendu incroyablement facile pour les non-développeurs la création et la mise à jour de contenu. C'était énorme dans mes premières années de création de sites Web pour les particuliers et les entreprises.
3. Définition du contenu. Types de publication personnalisés, taxonomies personnalisées et méta-boîtes personnalisées. Lorsque tout ce qui a conduit à ces derniers a atteint une singularité, je ne pense pas que j'arrive à dire que c'est à ce moment-là que WordPress était «vendable» à la communauté des affaires en tant que plus qu'un simple logiciel de blog. (WordCamp Phoenix 2012 - CMB. La grande écriture de Justin Tadlock sur la définition des types de publications, des taxonomies et des méta-boîtes.)

J'irais jusqu'à dire des méta-boîtes personnalisées - cette capacité à créer des interfaces d'administration personnalisées, créant une excellente expérience utilisateur pour les gens, est énorme. Cassez ça, et vous brisez WordPress .

L'idée derrière Gutenberg, qui rend l'expérience de l'éditeur de contenu plus puissante, est une excellente idée. Cela vaut la peine de le faire, mais cela doit être fait correctement, avec soin et sans précipitation. En ce moment, cela semble très précipité et loin d'être prêt.

@jchristopher le dit très bien:

Je soutiens pleinement l'objectif de Gutenberg d'améliorer l'expérience utilisateur, mais à mon avis, nous ne pouvons pas éviter le précédent qui a été mis en place (intentionnellement ou non) pour utiliser des méta-boîtes pour l'édition de contenu. Je pense que l'approche de Yoast est excellente, c'est quelque chose qui coche un certain nombre de cases à cocher pour une grande variété de solutions potentielles à ce problème.

@jnicol et @aurooba font valoir de bons points et posent de bonnes questions. Pourquoi semble-t-il être tout ou rien au lieu d'une feuille de route itérative? L'alternative de Yoast est beaucoup plus sensée que ce qui a été vu et je pense que «l'expérience iframe» le prouve. Merci, @amandarush , d'avoir

@aaronjorbin l'a dit plus tôt, quand quelqu'un adopte WordPress, il n'adopte pas WordPress (numéro de version-ici), il adopte WordPress dans son ensemble.

Il y a une autre version de cela, que n'importe qui dans les services à la clientèle entend probablement souvent. Lorsque quelqu'un vient vous voir et vous dit qu'il a besoin d'un nouveau site Web (nous ne parlons pas de blogs), il ne vous dit généralement pas «j'ai besoin d'un nouveau site Web Wordpress», ou «je veux un nouveau site Drupal», etc. Ils veulent juste un nouveau site qui fonctionne et qui fonctionne bien.

WordPress a été la meilleure solution pour des millions de sites Web: la facilité d'utilisation et l'open source sont la clé. Briser les méta-boîtes personnalisées (oubliez les numéros de plugins, que diriez-vous de tous les sites Web existants avec des interfaces utilisateur d'administration personnalisées?) Avec une implémentation précipitée d'une nouvelle interface d'éditeur endommage cette facilité d'utilisation.

ma patience en tant que simple développeur qui a passé toute l'année à réfléchir à la meilleure voie possible pour WordPress dans son ensemble (noyau et communauté) est proche d'une limite.

Je vais être franc, ici:

Ceci et quelques autres commentaires comme celui-ci me font penser que certains d'entre vous devraient s'éloigner des rôles décisionnels dans ce projet. Si vous ne pouvez pas recevoir de commentaires honnêtes, bien pensés mais critiques sur un produit, alors, franchement, vous ne devriez pas jouer un rôle décisionnel dans une équipe produit. J'ai été à votre place à plusieurs reprises, généralement lors de réunions en face à face et dans les cas de succès, tout le monde dans la salle s'est rendu compte que, peu importe à quel point le débat était passionné, il s'agissait de fournir le meilleur produit possible aux clients. Prendre des critiques sur les idées et la direction des produits fait partie du rôle de décideur dans une équipe de produits et cela devrait conduire à un meilleur produit, car personne ne peut penser à la meilleure façon de tout faire. Cela vaut aussi pour les équipes.

Je n'ai aucun doute que tout le monde dans l'équipe de base veut livrer une révision de WordPress qui soit géniale mais on se rapproche inévitablement d'un projet; vous savez ce qui a été débattu, considéré, rejeté, etc. et il est difficile de voir les choses d'un point de vue extérieur. Mais vous n'êtes pas la totalité de la communauté WP; tu ne peux pas l'être. Ce que vous entendez, ce sont des préoccupations valables concernant l'orientation du produit. Si vous ne pouvez pas prendre cela en compte, pensez à ce qui est dit et pourquoi il est dit alors, s'il vous plaît, éloignez-vous de la prise de décisions concernant la direction de Gutenberg.

Alternativement (et ce serait BEAUCOUP mieux), reprenez ces pensées. Considérez vraiment ce que les gens disent. Comprenez nos préoccupations en tant que personnes qui dirigent des entreprises qui utilisent WordPress et comprenez que nous ne nous soucions pas seulement de nous-mêmes, mais de nos clients.

J'utilise WP depuis début 2008, et je ne peux pas penser à une nouvelle fonctionnalité ou décision qui a créé autant de division pendant tout ce temps que l'introduction de Gutenberg, dans sa forme actuelle.

Bien que WordPress s'adresse aux utilisateurs, ce n'est qu'un outil, et les utilisateurs ne pourront tout simplement pas utiliser cet outil s'ils ne disposent pas des professionnels WP pour les aider à atteindre leurs objectifs.

Je vois des références à vouloir répondre aux besoins des utilisateurs d'une nouvelle installation (quoi? ~ 1% de l'augmentation du Web par an?), Mais cela semble être au détriment de la base d'utilisateurs existante (~ 28%), le dont la majorité est susceptible d'exécuter un plugin qui a au moins une méta-boîte. Cela semble être un mauvais sens des affaires à quelque échelle que ce soit.

Je comprends l'idéologie: créer un éditeur dans le meilleur des cas, puis utiliser un modèle d'adaptateur pour passer de l'ancien au nouveau. Le problème est que PHP et JS sont des technologies différentes, et faire passer ce problème au pays des iframes HTML n'est pas viable, pour toutes les raisons évoquées précédemment.

C'était la première passe, c'était une expérience, mais cet effort n'a pas abouti. Plus vite cela sera reconnu, plus vite nous pourrons passer à la suggestion suivante.

Personne n'a trouvé de solution appropriée dans le cas des méta-boîtes qui satisfasse toutes les parties.

Cela signifie qu'une partie doit céder - et que ce soit 10 à 50 développeurs pro-Gutenberg, ou des centaines / milliers de développeurs qui sont _concernés_ ou l'impact que les changements auront pour eux, sans parler de leurs utilisateurs, nous verrons.

Une fois que toutes les suggestions de solutions de contournement sont épuisées, il y aura peut-être une concession selon laquelle le remplacement de la page entière n'est pas faisable pour toutes les parties. Du moins pas dans le coup unique qui est actuellement tenté.

Pour revenir à la question initiale, les iframes sont-ils la solution à long terme pour les méta-boîtes? Plusieurs développeurs (et n'oublions pas, ce sont aussi des utilisateurs) ont expliqué pourquoi la réponse est non.

Nous avons eu ici une discussion largement constructive. Rappelles toi:

Nous critiquons les idées, le code et les pixels, pas les humains derrière eux. Nous pouvons avoir des opinions différentes sur la meilleure voie à suivre, mais nous ne remettons pas en question les informations d'identification. Lorsque nous nous adressons aux individus, c'est pour les élever et leur rendre hommage pour un travail bien fait. Avec tant de choses dans le monde, nous devons veiller les uns sur les autres. C'est un défi monumental, mais nous y arriverons ensemble.

Permettez-moi de rappeler à tout le monde que les métabox dans Gutenberg étaient le résultat d'un @ BE-Webdesign qui s'est intensifié et a accompli cela, indépendamment de tout le monde avec peu d'aide, apparaissant de nulle part. Sans @ BE-Webdesign, il n'y aurait pas de métaboxes à Gutenberg. Sur les 47 commentaires laissés ici, peut-être que seulement 2 personnes ont réellement touché le code de la métabox à des fins de révision et d'UX.

Le problème fondamental ici cependant, est de savoir comment obtenir en toute sécurité les métaboxes sur la page en tant que citoyens de première classe sans créer de code non sécurisé, ce qui conduit à un compromis entre les kludges hacky ou à avoir des pièges.

• La première itération impliquait un piège, faisant croire à WP que c'était sur la page edit.php , et générer les métaboxes de cette façon. Les rapports initiaux ont indiqué qu'il avait des problèmes de compatibilité et était super piraté, et non une solution viable. En effet, de nombreux plugins n'enregistrent les métaboxes que si certaines circonstances sont remplies et ne font pas confiance à WP pour savoir quand les rendre
• La deuxième itération, qui a été fusionnée, utilise des iframes, de sorte que les métaboxes s'affichent dans l'éditeur classique, mais avec tout sauf la métabox supprimée. C'est un peu dérangé mais les métaboxes fonctionnent, bien qu'avec des problèmes
• Il existe également une solution où nous récupérons le code HTML, puis l'insérons en gros dans un composant, ce qui serait une catastrophe de sécurité, bien que ce soit la solution super évidente. D'où pourquoi cela n'a pas été fait de cette façon.

Ma suggestion est:

au lieu de charger Gutenberg sur une page de paramètres, chargeons-le dans la page principale des éditeurs classiques, chargeons les métaboxes dans leur environnement natif, puis hissons leur nœud DOM de conteneur dans un composant via JS

Nous utilisons ensuite un autre type de bascule pour nous assurer que l'éditeur classique peut toujours être utilisé. Par ici:

• nous évitons les absurdités iframe
• les métabox fonctionnent comme elles l'ont toujours fait en ce qui concerne l'enregistrement
• le JS existant fonctionne comme prévu, et aucun piratage n'est nécessaire pour faire fonctionner les choses du côté PHP

De plus, le design du yoast est joli, mais où va le block meta?

Malheureusement, j'ai très peu d'expérience avec js au niveau requis pour contribuer au code réel à Gutenberg. Je commence à peine à plonger mes orteils dans le monde du développement de WordPress plutôt que de développer par-dessus. Donc, le mieux que je puisse faire est de fournir mes commentaires, de tester l'éditeur (j'utilise activement Gutenberg sur mon blog personnel) et de fournir des suggestions / réflexions. Si je _pouvais_ contribuer au code, je le ferais absolument. S'il y a une autre façon d'aider, j'aimerais le savoir. Parce que je me soucie beaucoup de ça. :)

La contribution prend de nombreuses formes. Bien que le temps et les efforts consacrés à l'élaboration de cette tentative soient appréciés, les tests et les discussions qui évitent les futurs coûts irrécupérables peuvent être tout aussi précieux. Par exemple, il existe un certain nombre de problèmes récemment ouverts liés à l'implémentation d'iframe. Nous pourrions passer de nombreuses heures à essayer de résoudre ces problèmes, ou nous pourrions utiliser les tests et la justification de ce fil pour déterminer qu'une direction différente est nécessaire. J'espère que c'est la réalisation à laquelle nous sommes arrivés en tant que groupe.

Permettez-moi de rappeler à tout le monde que les métabox dans Gutenberg étaient le résultat d'un @ BE-Webdesign qui s'est intensifié et a accompli cela, indépendamment de tout le monde avec peu d'aide, apparaissant de nulle part. Sans @ BE-Webdesign, il n'y aurait pas de métaboxes à Gutenberg.

Bien que les éloges et l'adoration soient gentils 😄, j'ai vraiment eu de l'aide, et c'est en grande partie un effort d'équipe de la part de nombreuses personnes.

Ma suggestion est:

au lieu de charger Gutenberg sur une page de paramètres, chargeons-le dans la page principale des éditeurs classiques, charge> les métaboxes dans leur environnement natif, puis hissons leur nœud DOM conteneur dans un composant via JS

Oui, c'est très probablement la prochaine itération, et je pense que c'est une excellente suggestion ainsi qu'une idée constructive. Je ne sais pas encore à 100% comment faire cela proprement, mais il est tout à fait possible de ne pas utiliser les iframes et d'avoir le même UX amélioré que Gutenberg fournit déjà. Il y aura des mises à jour à venir pour améliorer l'expérience de la méta-box, ce qui impliquera probablement l'élimination des iframes. La méthode iframe a servi de moyen de voir comment le support de la méta-box pourrait être implémenté, maintenant de meilleures améliorations seront apportées. Lorsque les choses ont été explorées pour la première fois avec des méta-boîtes il y a plusieurs mois (ce n'était pas un nouveau sujet), il était logique d'aller de l'avant avec l'approche iframe, en raison de l'état de Gutenberg à l'époque, maintenant qu'il est fusionné et que de nombreux autres éléments ont changé. autour, l'utilisation d'iframes n'est probablement plus nécessaire, d'un point de vue technique. Il faudra faire plus de travail.

@ BE-Webdesign Merci pour vos efforts et vos contributions ici. Clôturons ceci et commençons un nouveau problème lorsque cette approche sera prête pour la discussion.

Veuillez arrêter et réévaluer maintenant, pas plus tard

Tout le monde n'est pas habitué à cette approche de la conception de projet, mais il s'agit d'un projet qui suit une réévaluation quotidienne continue de presque tout. Comparez les maquettes originales à l'éditeur actuel. Les choses changent. La plupart des pièces ne sont pas gravées dans la pierre. La seule façon d'évaluer vraiment si quelque chose fonctionnera est de le faire réellement. Tout le monde n'aborde pas la conception de produits de la même manière, mais je pense que l'itération rapide de Gutenberg l'a bien servi, plutôt que d'essayer de résoudre les inconnues à l'avance.

Merci à tous pour la discussion. Je suis heureux que la conversation se soit recentrée à la fin sur la question du sujet: est-ce que l'approche actuelle des méta-boîtes dans une iframe est viable? La réponse étant non. Les iframes sont un détail d'implémentation que je pense que nous pouvons abandonner relativement facilement. Alors concentrons-nous là-dessus.

Je voudrais ajouter, en guise de conclusion, que ne rien changer à l'écran d'édition serait le chemin le plus simple à faire pour nous. Ce ne serait pas non plus juste pour les objectifs du projet et les utilisateurs à long terme de WordPress. Ce que certaines personnes ont appelé l'approche pragmatique n'est pas concomitante avec la direction de conception que ce projet a eue depuis le début - vers une personnalisation complète du site - et ce qui a dicté nos décisions jusqu'à présent. Rien ici ne doit être une solution finale, nous explorons ce qui est possible dans les locaux de conception et le mettons là-bas pour des tests. Cela ne peut pas être construit par nous seuls et nous saluons sincèrement toute l'aide que nous pouvons obtenir de vous tous, car il y a plusieurs problèmes difficiles enterrés sur la route à surmonter.

WordPress évolue toujours avec l'utilisateur et nous prenons le fardeau de trouver des chemins de développement pour faciliter les transitions de notre code existant. En tant que projet, nous avons déjà dit que nous n'abandonnions pas le support des méta-boîtes de WordPress, mais aussi que nous devions explorer les décisions d'interface que nous aurions à prendre dans le nouveau paradigme, y compris la possibilité de charger l'éditeur classique lorsque nous détectons des méta-boîtes que nous ne pouvons pas gérer ou qui sont directement en conflit avec un éditeur qui cherche à délimiter plus clairement ce qu'est le contenu et ce que sont les méta-données. Il y a des gens qui pourraient bénéficier de l'expérience par défaut de Gutenberg dès maintenant. En tant que développeurs, nous avons le privilège de pouvoir fabriquer des solutions, mais aussi la responsabilité de ne pas éluder les changements que nous devons apporter afin de permettre aux gens, qui auraient autrement du mal, d'avoir leur présence sur le Web ouvert.

@mtias J'apprécie vraiment votre commentaire sensible, en particulier la partie sur "WordPress évolue toujours avec l'utilisateur".

Malheureusement, cela est complètement en contradiction avec ce que @youknowriad communique dans ce fil, et puisque vous travaillez tous les deux chez Automattic, je vous exhorte à lui parler de la direction du produit, car en ce moment, nous recevons des signaux mitigés.

Malheureusement, vous n'avez pas abordé le sketch Yoast proposé qui nous donnerait toute la flexibilité de Gutenberg tout en étant compatible avec les métaboxes existantes. Pourquoi personne ne peut-il reconnaître pourquoi vous n'envisagez pas cette approche?

Malheureusement, cela est complètement en contradiction avec ce que @youknowriad a communiqué dans ce fil

Je pense que vous avez mal compris ce que j'ai dit, je ne faisais qu'énumérer des faits et je partage les pensées @mtias à 100%

@mtias

Ce que certains ont appelé l'approche pragmatique n'est pas concomitant avec la direction de conception que ce projet a eue depuis le début - se diriger vers la personnalisation complète du site

Je suis vraiment en désaccord avec ce point de vue. Faire une amélioration itérative qui est limitée à l'éditeur lui-même, mais qui a le pouvoir de remplacer les métaboxes, ainsi que de publier et de promouvoir une API de champs serait un moyen simple de faire passer la masse de plugins à un paradigme de bloc, simplement par la facilité d'utilisation , par rapport au paysage fracturé que nous avons actuellement.

En effectuant en douceur cette transition intermédiaire, vous rendriez beaucoup plus facile de désapprouver la génération / manipulation directe du DOM sur l'écran post_edit, car d'ici là, la solution standard en pratique n'impliquerait plus une telle manipulation. Je ne crois pas que quiconque dise que "la manipulation directe du DOM doit être l'expérience principale pour toujours". Ils disent: "C'est la première solution maintenant".

si vous pouvez maintenir une flexibilité totale de manipulation dom avec une solution plein écran, allez-y ... mais cela semble être un objectif très ambitieux, et je doute que toute forme de levage de l'écran d'édition classique puisse réellement fournir à tout niveau raisonnable de compatibilité. Peut-être que je me trompe, mais cela semble être un hack incroyablement compliqué d'essayer de faire la transition des utilisateurs, alors qu'une approche plus itérative pourrait faire le même travail.

En conservant la primauté du paradigme actuel, tout en libérant le nouveau, vous encouragez l'adoption sans nuire à l'expérience actuelle de qui que ce soit. Ensuite, une fois que la plupart des flux de travail sont passés à un paradigme de bloc, le contrôle dom direct peut être abandonné au profit d'une solution plein écran.

Il ne trahit pas les objectifs du projet, il s'agit simplement de respecter le calendrier de publication pour rendre le changement plus gérable pour des milliers d'agences et de développeurs.

@youknowriad Permettez-moi de publier quelques extraits de ce que vous avez écrit pour soutenir ce que je dis:

en tirant parti de l'API REST, de l'interface utilisateur côté client et de l'unification des concepts de base: widgets, codes courts, blocs, métaboxes de contenu sous un concept unique «A Block»

Personne n'a demandé que les «métaboxes de contenu» soient transformées en blocs, et cela n'a été communiqué que lorsque Gutenberg a expédié sa version initiale. En fait, c'est ce sur quoi porte l'argumentation. Je ne répéterai pas beaucoup mieux ce que d'autres ont dit, juste que les métaboxes ne sont très souvent pas du contenu de page.

Contrairement à ce que vous lisez ici et là, l'accent a toujours été mis sur la refonte de la page entière.La première maquette de la page de l'éditeur Gutenberg a été présentée lors de la deuxième ou troisième réunion hebdomadaire de Gutenberg. Nous étions encore en phase de prototypage.

L'équipe de Gutenberg n'arrêtait pas de dire que les croquis étaient juste pour le spectacle et non pour la conception finale. De plus, une esquisse ne peut pas montrer si tout l'écran d'édition a été converti en React ou s'il a simplement été stylé différemment. Le fait que la page entière allait être repensée a été une grande surprise pour tous ceux à qui j'ai parlé.

Quelle est la différence entre les codes courts, les boutons TinyMCE et les métaboxes?
La principale différence est que les «Metaboxes» n'ont pas de «but», c'est juste un moyen d'étendre la page de l'éditeur sans cohérence alors que les boutons Shortcodes et TinyMCE en ont un.

C'est une idée fausse géante qui devrait soulever des sourcils au sein d'Automattic. (Et j'espère que @mtias et @m écoutent). Ce n'est tout simplement pas vrai et je remets vraiment en question votre jugement suite à cette déclaration.

Pouvons-nous en conclure que pour le long terme de WordPress, les Metabox verrouillent son évolution (quel que soit Gutenberg)?
Oui, ils sont.

Je dirais que presque personne n'est d'accord avec vous ici, et je pense qu'Automattic doit mettre cela au vote afin de déterminer l'orientation du produit.

J'interroge également

Je n'ai littéralement aucune foi que si je devais faire un PR pour réduire Gutenberg pour être juste le composant d'édition, il serait considéré par l'équipe de Gutenberg, en raison des déclarations faites par quelques personnes au sein d'Automattic.

@mtias ,

Je voudrais ajouter, en guise de conclusion, que ne rien changer à l'écran d'édition serait le chemin le plus simple à faire pour nous. Ce ne serait pas non plus juste pour les objectifs du projet et les utilisateurs à long terme de WordPress.

Franchir une étape à la fois ne pas, en aucune façon, compromettre les objectifs du projet. Vous pouvez toujours vous diriger vers la personnalisation en taille réelle si tel est l'objectif, mais en le faisant par étapes, vous amènerez le reste de la communauté des développeurs avec vous.

Le Customizer en est un excellent exemple. Oui, il a ses critiques, mais le concept final se réalisera au fil du temps, être une fonctionnalité qui permet à certains groupes d'utilisateurs d'utiliser efficacement WP comme outil de gestion de leur site.

Il y a des gens qui pourraient bénéficier de l'expérience par défaut de Gutenberg dès maintenant.

Absolument. Mais il y a aussi un nombre considérablement plus grand de personnes qui auraient une expérience néfaste avec le Gutenberg par défaut en ce moment.

J'espère que nous pourrons tous avancer dans le respect et séparer les gens du produit dans nos réponses. La passion est géniale, mais il est important de penser aux humains avec lesquels nous interagissons dans des fils comme celui-ci. Chaque personne impliquée dans ce projet s'en soucie, elle ne viendrait pas dans ces fils et n'interagirait pas si elle ne le faisait pas. Maintenant, prenons un souffle et rappelons-nous à quel point nous nous soucions tous de WordPress et voulons au cœur de nos commentaires garder cette communauté sûre, productive pour tout le monde.

@khromov , en tant que responsable de la conception de ce projet, tout comme Matias est le responsable technique, je suis à 100% derrière @youknowriad. Je comprends que vous êtes passionné, mais vous n'êtes pas respectueux. Veuillez ajuster l'approche que vous adoptez en appelant une seule personne. Arrêtons d'être personnels.

Il est également important de se rappeler que beaucoup de ceux qui travaillent sur Gutenberg étaient auparavant membres de la communauté WordPress, étaient (sont toujours) des contributeurs principaux avant. Oui, cela m'inclut. Je parlerai de manière très personnelle ici, une fois que vous aurez fait un PR, veuillez m'en informer et je vais jeter un coup d'œil et m'assurer qu'il respecte tous les avis, peu importe leur origine. S'il vous plaît, passons de voir ce projet comme un «nous v eux». Ce n'est pas et nous avons ici des contributeurs non Automattic incroyables, cette déclaration leur fait un mauvais service.

@khromov

Je suis généralement considéré comme un détracteur de Gutenberg, car mes messages et commentaires mettent en évidence les problèmes que je vois avec l'approche et la mise en œuvre, mais je pense que les objectifs et les progrès de Gutenberg sont parfois mal interprétés dans les commentaires, en raison d'une mauvaise communication ou d'un manque de compréhension de l'objectif global du projet.

Les blocs ne sont pas un moyen visuel de représenter et de modifier le contenu des articles, ils ne doivent pas non plus faire partie d'un menu de sélection de contenu ou faire glisser / déposer. Ils peuvent être utilisés pour ces choses, bien sûr, et c'est le flux de travail que la plupart des parties visibles de Gutenberg ont mis en évidence. Cependant, ignorez ce que vous savez sur ce paradigme pendant un moment, et regardez-le plutôt de cette façon:

Les blocs sont censés être une structure de contrôle fondamentale pour le site, indépendamment de l'interface ou du stockage.

• Les widgets sont appelés à devenir des blocs. Cela ne signifie PAS qu'ils existeront dans l'éditeur et seront sauvegardés dans post_content. Cela signifie simplement qu'ils seront contrôlés avec un système construit dans un framework JavaScript, avec une seule API commune.
• Le Customizer devrait être remplacé par des blocs. L'interface restera probablement (à peu près) la même, mais les sections du Customizer seront contrôlées par la même API.
• La page des plugins, l'éditeur de thème, le tableau de bord lui-même, sont tous appelés à devenir des blocs. Si l'idée de ces sections, telle qu'elle est, est impossible à imaginer recréée avec une API commune, alors vous avez probablement des idées fausses liées à ce qu'est un bloc, dans le langage WordPress.

Le problème n'est pas que les métaboxes ne peuvent pas être recréées dans le paradigme de bloc, en fait, les blocs non frontaux qui sont ajoutés par programme à un type de publication, verrouillés en place et stockés dans post-meta au lieu de post_content sont prévus pour la version WordPress 5.0 (corrigez-moi si je me trompe).

En substance, cela couvre tous les besoins de méta-champs triviaux tels que les zones de texte et les sélections. Vous pouvez exactement dupliquer cette interface en blocs, si vous le souhaitez, ou vous pouvez éventuellement en rationaliser une partie, en fonction du nouveau langage visuel qui bloque l'offre ... ce serait entièrement votre appel.

Le problème n'est pas que les métaboxes ne peuvent jamais être des blocs. Le problème est qu'à l'heure actuelle, il existe des interfaces créées dans des métaboxes, qui ne sont pas encore prises en charge dans des blocs (que ce soit par WordPress ou par des tiers), et la réimplémentation de ce travail est une tâche herculéenne pour les développeurs, d'autant plus que ces outils n'ont pas été construits. à partir d'une API commune comme l'API Fields proposée, mais plutôt d'une manière mélodieuse qui modifie directement le DOM de la page et met en file d'attente les ressources de manière ad hoc et non gérée.

Cet état actuel pose également des problèmes aux développeurs. Par exemple, si vous utilisez Visual Composer, avec Piklist pour les champs, Piklist remplacera bon nombre de vos styles d'administration, ce qui rendra la navigation dans VC très difficile.

Ou si vous utilisez WooCommerce avec un plugin qui met en file d'attente la nouvelle version de la bibliothèque Select2, l'un ou l'autre cassera votre interface d'administration, avec une erreur JS critique.

La même chose peut se produire si deux plugins différents reposent sur des versions différentes du framework CMB2.

Blocks a l'intention de résoudre ces problèmes en introduisant un cadre commun autour des différents ajouts de page. Une partie de ce cadre sera axée sur l'offre de trucs visuels par glisser-déposer wiz-bang à l'éditeur, mais la majorité n'est pas réellement liée à cela. Il s'agit simplement de s'assurer que les éléments qui apparaissent dans l'administrateur sont gérés de manière commune.

Maintenant, il existe des arguments valables selon lesquels WordPress a prospéré grâce à une attitude de développement du Far West, et que ce cadre commun soulève la barrière d'entrée pour les développeurs qui ne savent pas réagir. Et il existe des arguments valables selon lesquels l'interface Block n'atteindra rien de proche de l'adoption généralisée des développeurs avant la publication. Il existe même des arguments valables selon lesquels l'API de bloc actuelle est un peu naïve et ne prend pas en compte de nombreux flux de travail courants, ce qui rend impossible l'adaptation des plugins tant que ces capacités ne sont pas créées et documentées.

Mais affirmer que le Metabox free-for-all, tel quel, est la solution ultime et doit être préservé pour l'éternité n'offre pas un grand chemin à suivre pour personne. Pour que WordPress puisse offrir de meilleures options à tous les utilisateurs, développeurs inclus, une sorte de système commun doit exister.

Cela aurait été bien si ce système était une API Fields commune, il y a des années, de sorte que tous ces changements ne seraient principalement qu'un remplacement de l'étape de rendu de cette API, mais dans l'état actuel des choses, une voie à suivre doit être trouvée.

Cela dit, je suis toujours fortement en faveur de la solution provisoire proposée par Yoast, comme étant le meilleur moyen dans le monde réel d'évoluer vers une éventuelle interface utilisateur commune. Je reste critique, bien sûr, mais je veux m'assurer que nous critiquons les faits et non les malentendus.

Malheureusement, cela est complètement en contradiction avec ce que @youknowriad communique dans ce fil, et puisque vous travaillez tous les deux chez Automattic, je vous exhorte à lui parler de la direction du produit, car en ce moment, nous recevons des signaux mitigés.

Je dirais que presque personne n'est d'accord avec vous ici, et je pense qu'Automattic doit mettre cela au vote afin de déterminer l'orientation du produit.

Il est évident que l'équipe de Gutenberg associée à Automattic ne bouge pas d'un pouce et détourne toutes les critiques.

Je n'ai littéralement aucune foi que si je devais faire un PR pour réduire Gutenberg pour être juste le composant d'édition, il serait considéré par l'équipe de Gutenberg, en raison des déclarations faites par quelques personnes au sein d'Automattic.

Je voudrais juste dire l'évidence, mais Gutenberg est un projet communautaire WordPress, pas un produit Automattic . Je suis peut-être un automobiliste moi-même, mais cela ne me donne pas plus d'autorité sur ce projet que quiconque, qu'il s'agisse d'un pigiste, d'un PDG d'agence ou d'un développeur dévoué remplissant un engagement de 5% de l'entreprise, contrairement à ce que certaines personnes ont suggéré. De même, WordPress lui-même est un projet communautaire, pas un projet Automattic.

Automattic ne «libère» ni ne «construit» WordPress, et Gutenberg n'est pas un produit Automattic

De plus, avant que cette conversation ne devienne encore plus émouvante et que les gens perdent de vue la forêt pour les arbres, j'aimerais prendre le temps d'apprécier la difficulté de la tâche qui a été confiée à l'équipe de Gutenberg, et la façon dont ils la gèrent. en général. Ils ont été chargés de créer un paradigme qui deviendra la base de toute l'expérience d'administration de WordPress, avec des contraintes qui ne leur permettent de démontrer son efficacité que dans un petit coin de l'interface.

La quantité de malentendus provoqués par l'idée que «l'éditeur prend le relais» est immense et doit être très difficile à gérer. Leur mission est de créer les blocs de construction communs pour l'administrateur de WordPress et de les tester en reconstruisant l'éditeur. Bien que je pense que cette tâche serait beaucoup plus acceptable et flexible pour le public s'il ne faisait que reconstruire l'interface wp_editor() et se développer à partir de là, il est compréhensible que tous les composants connectés de `` l'expérience d'édition '' en font un essai plus complet du nouveau paradigme proposé.

Je comprends et j'apprécie l'année d'efforts qui a été consacrée à ce travail. Je continue de critiquer certaines des décisions prises et je pense qu'il est temps d'apporter des modifications qui amélioreront considérablement l'adoption initiale, mais je suis tout à fait d'accord avec l'objectif global de fournir éventuellement un cadre plus structuré pour l'expérience d'administration WordPress. , pour les développeurs et les utilisateurs.

@karmatosed

La raison pour laquelle j'ai mentionné @youknowriad est qu'il était le seul à participer à la discussion. Une discussion qui a impliqué des centaines de développeurs et des milliers d'heures sans avancer, malgré un consensus clair du côté des développeurs. Je ne pense pas qu'il soit irrespectueux de remettre en question la légitimité des décisions prises lorsqu'elles sont prises par un petit groupe de développeurs, même si cela implique d'appeler des personnes spécifiques.

Quoi qu'il en soit, j'ai eu une conversation privée avec @youknowriad et il m'a expliqué la feuille de route à venir qui, à mon avis, semble plus raisonnable que ce qui est communiqué vers l'extérieur.

@tomjn

Je suis respectueusement en désaccord. Les décisions importantes sont prises par Automatticians, et après une discussion avec @youknowriad, j'ai compris que la direction du produit est déjà définie depuis longtemps, donc il n'y a rien pour nous, contributeurs réguliers, à faire autre que corriger des bugs et peut-être un visuel mineur. des ajustements.

@gschoppe Je souhaite juste que ce "changement de paradigme" soit discuté ouvertement et réalisé en collaboration avec la communauté des développeurs. C'est peut-être l'intention, mais dans ce cas, le côté communication ne fonctionne pas très bien.

Pourquoi quelqu'un ne peut-il pas reconnaître pourquoi vous n'envisagez pas cette approche?

@khromov nous avions déjà , et à d'autres endroits dans les discussions de l'éditeur, etc. Ce problème concernait en particulier l'implémentation d'iframe.

Je n'ai littéralement aucune foi que si je devais faire un PR pour réduire Gutenberg pour être juste le composant d'édition, il serait considéré par l'équipe de Gutenberg, en raison des déclarations faites par quelques personnes au sein d'Automattic.

Pas du tout. Nous l'avons considéré nous-mêmes très tôt auparavant, le voyant trop limitatif et inapproprié pour conduire la vision que nous avions. Cela pourrait encore être un compromis raisonnable pour beaucoup et pourrait être un bon plugin à explorer. Le travail nécessaire pour y arriver, cependant, améliorerait Gutenberg en général en le rendant plus réutilisable, donc je ne m'opposerais pas aux gens qui y travaillent. Si quelqu'un travaillait sur un tel PR, je suggérerais probablement d'ajouter un paramètre dans la section Écriture pour basculer le comportement au lieu de le définir par défaut.

Nous avons des fonctionnalités importantes autour des blocs imbriqués, des blocs globaux, des modèles de blocs de déclaration, des colonnes, etc., qui bénéficient vraiment du fait que la feuille de contenu est la page complète et qui se sentiraient plutôt pauvres sinon, limitant ce que les développeurs peuvent faire et ce que les utilisateurs peuvent expérimenter. Il existe également de bons outils comme le contour du document qui s'intègrent de manière transparente et en temps réel dans l'éditeur plein écran qui seraient créés dans un simple remplacement de TinyMCE.

Aller une étape à la fois ne compromet en aucun cas les objectifs du projet.

Absolument! Nous avons proposé une approche par étapes, à partir du nouvel article original de Matt, elle considère simplement les étapes différemment. Il y a généralement trois étapes pour le projet Gutenberg: de l'éditeur de publication, aux modèles de page, à la construction du site. Ce qui est primordial, c'est que le paradigme est celui où le contenu est un domaine unique, avec le bloc comme concept principal, et où le résultat peut être représenté visuellement avec clarté et sans abstractions excessives.

Absolument. Mais il y a aussi un nombre considérablement plus grand de personnes qui auraient une expérience néfaste avec le Gutenberg par défaut en ce moment.

Bien sûr, et c'est pourquoi il existe à la fois un plugin pour revenir à l'expérience actuelle à volonté, et nous aurons des mécanismes pour gérer les incompatibilités, permettant à plus de choses d'être opt-in (par exemple, si vous êtes à l'aise avec vos méta-boîtes montrant dans Gutenberg, vous pouvez déclarer son soutien, ou vice versa).

@gschoppe Je sais que nous avons eu notre juste part de désaccords dans le passé, mais j'apprécie vos commentaires ici et votre volonté de participer même à travers les différents points de vue. Vous faites quelques remarques intéressantes sur le facteur d'agglutination du bloc. Peut-être qu'un jour nous nous rencontrerons lors d'une conférence WC et nous pourrons nous lancer dans une discussion philosophique amusante sur le navire du paradoxe de Theseus. Qui sait. 😉

Vous, d'Automattic, ne devriez pas vous plaindre que nous ne pouvons pas respecter votre travail et que nous vous poussons trop.
Pas pour 7000 - 10.000 € de salaire mensuel par mois, vous êtes payé. Idiot. Ce n'est pas comme quand les gens se plaignent sur WP Trac aux développeurs bénévoles.
Si Gutenberg vous donne des maux de tête, parlez-en à votre patron. Il vous a confié une tâche impossible à accomplir.

Deuxièmement, vous êtes bien meilleur codeur que la majorité des gens qui ont commenté ici. Pourquoi avez-vous essayé de passer la solution "Iframes"?
Je vous l'ai dit, vous traitez les gens comme des enfants. Essayons les iframes et voyons si les gens vont crier trop, être trop émotifs. S'il y a beaucoup de bruit, nous nous éloignons des iframes.

Pourquoi avez-vous essayé de passer la solution "Iframes"?
Je vous l'ai dit, vous traitez les gens comme des enfants. Essayons les iframes et voyons si les gens vont crier trop, être trop émotifs. S'il y a beaucoup de bruit, nous nous éloignons des iframes.

Lorsque le support des méta-boîtes a été mis en œuvre pour la première fois, le nouvel éditeur existait sur une toute nouvelle page d'administration, pas post.php, l'éditeur se chargeait différemment, et en général, il y avait de nombreuses contraintes, une partie de la résolution du problème des méta-boîtes à l'aide d'iframes, en éclairait certaines de ces contraintes, qui n'existent plus, et par conséquent des méta-boîtes, n'auront probablement plus besoin d'utiliser des iframes.

Ce projet favorise l'amélioration incrémentielle entre les versions plutôt que la perfection dans une seule version. Personne n'essaie de voir si les gens vont crier. La réalité est que l'approche iframe a bien fonctionné pour la plupart des méta-boîtes, malgré ce que les gens en ont fait. Maintenant, il sera amélioré et il y aura de moins en moins de 😱 🙀.

@StaggerLeee veuillez être respectueux envers chacun dans ce projet, peu importe où il travaille. Tout comme vous aimeriez que quelqu'un vous traite bien, faites de même avec les autres.

En tant que responsable de la conception de ce projet, je ne verrai pas les déclarations personnelles que vous avez faites à quiconque. Je me fiche de l'endroit où quelqu'un travaille ou de son expérience, ce sont des détails personnels que vous n'avez pas le droit d'appeler. S'il vous plaît laissez tomber le personnel et revenez à vous concentrer sur le produit.

Maintenant, passons à autre chose et concentrons-nous sur la fabrication du meilleur produit possible. Je comprends parfaitement que vos remarques proviennent souvent d'un lieu de passion. Vous pouvez être respectueux et passionné, revenez à l'être.

Vous, d'Automattic, ne devriez pas vous plaindre que nous ne pouvons pas respecter votre travail et que nous vous poussons trop.
Pas pour 7000 - 10.000 € de salaire mensuel par mois, vous êtes payé. Idiot. Ce n'est pas comme quand les gens se plaignent sur WP Trac aux développeurs bénévoles.
Si Gutenberg vous donne des maux de tête, parlez-en à votre patron. Il vous a confié une tâche impossible à accomplir.

@StaggerLeee Je voudrais être payé ce soupçon beaucoup

Alors croyez que le message a été reçu, la preuve est dans l'onglet Pull Requests en haut, ce n'est pas une conspiration Automattic pour casser votre code et envoyer vos clients (_n'oubliez pas, Automattic a des clients payants qui utilisez aussi des métaboxes_)

Pour ceux qui sont toujours concernés par les iframes , je suggère de regarder ici cette demande d'extraction (https://github.com/WordPress/gutenberg/pull/3345) qui tente d'annuler les iframes et de mettre en œuvre ma suggestion faite précédemment.

Comme les prochaines itérations des implémentations de métaboxes, il serait bon de tester et d'identifier les problèmes de compatibilité, lancer des fruits pourris vers A8C peut sembler bon, mais cela n'aide pas.