Gutenberg respecte le support de l'éditeur tel que déclaré par un CPT et ne se chargera pas s'il n'est pas supporté.

Si cela signifie que Gutenberg ne se charge pas du tout et que l'éditeur Classic est utilisé à la place, cela nous met sur la voie d'un administrateur WP fracturé qui est divisé entre les environnements Gutenberg et Classic. Ce serait mauvais pour WordPress à bien des égards.

• Les nouveaux utilisateurs devraient apprendre les différences majeures et subtiles entre les deux types d'interfaces. Une action aussi simple que publier un article ou passer en mode texte fonctionne différemment dans les éditeurs Gutenberg et Classic.

• Les développeurs existants seraient obligés de maintenir les fonctionnalités de leurs thèmes et plugins dans les deux environnements. Nous ne parlons pas d'une période de transition; nous parlons indéfiniment. Les plugins destinés à étendre n'importe quel type de publication seraient les plus affectés. Si ces développeurs finissent par convertir leurs méta-boîtes en blocs, ils devront toujours conserver les anciennes méta-boîtes au cas où quelqu'un utiliserait son plugin dans un type de publication non Gutenberg.

• Les nouveaux développeurs de plugins entrant dans le développement WordPress devraient apprendre à créer des plugins de deux manières différentes. En supposant qu'ils adoptent les blocs Gutenberg, leur fonctionnalité de plug-in peut même ne pas être disponible dans les types de publication utilisant l'éditeur classique.

Autant que je pense que nous devons faire fonctionner les méta-boîtes, désactiver simplement Gutenberg n'est pas la meilleure solution à long terme.

Si cela signifie que Gutenberg ne se charge pas du tout et que l'éditeur Classic est utilisé à la place, cela nous met sur la voie d'un administrateur WP fracturé qui est divisé entre les environnements Gutenberg et Classic.

Dans les cas où un CPT ne veut pas du tout activer l'éditeur, cela semble être la meilleure voie à suivre. Il s'agit simplement d'une vue d'administration différente, optimisée pour une expérience différente. (La vue "commandes" de Woo, par exemple.) Cela n'aiderait personne d'essayer de les rendre dans le contexte de Gutenberg.

C'est similaire à l'avènement du Customizer - c'était un nouveau paradigme d'interface qui faisait certaines des mêmes choses dans un contexte différent. Nous aurons toujours besoin d'une interface "gestion" et d'une interface "édition". C'est en partie ainsi qu'on avance, en clarifiant les différentes finalités des interfaces.

Mais en raison de la dérive de la portée de Gutenberg, il ne s'agit pas simplement d'activer ou de désactiver le type d'éditeur. Étant donné que Gutenberg détermine désormais l'intégralité de l'interface d'édition, il existe toute une liste d'effets secondaires associés au type d'éditeur que j'ai répertorié ci-dessus.

Nous aurons toujours besoin d'une interface "gestion" et d'une interface "édition".

Ce sont exactement les rôles que l'éditeur et les boîtes méta remplissent aujourd'hui. Ce ne sont pas des expériences isolées. Ils travaillent ensemble.

alors peut-être que le fluage de la portée devrait être traité, et Gutenberg devrait être contraint à la zone peuplée par wp_editor() . Cela résoudrait certainement de nombreux problèmes de compatibilité.

Fluage portée

Ma préférence est de remédier à la dérive de la portée et c'est quelque chose que beaucoup d'entre nous ont réclamé au cours des derniers mois. Cela nous permettrait d'améliorer l'éditeur sans diviser l'expérience d'administration.

Activation de Gutenberg par type de publication

En ce qui concerne la possibilité de désactiver Gutenberg par type de publication, je tiens à souligner qu'éviter le problème n'est pas la même chose que d'arriver à une solution. Désactiver Gutenberg par type de publication peut éviter l'incompatibilité de la boîte de méta pour certains plugins, mais cela endommage le paysage WordPress à long terme.

Si vous ne voyez pas pourquoi, imaginez être un nouveau développeur de plugins entrant dans l'industrie dans deux ans, après la fusion de Gutenberg.

• En tant que développeur, écrivez-vous l'interface utilisateur de votre plugin sous forme de bloc ou de méta-boîte ? Si vous souhaitez prendre en charge tous les types de publication, vous devrez l'écrire à la fois.
• Lorsqu'un utilisateur recherche des plugins, est-il conscient que la fonctionnalité que vous promettez sur votre page de plugin ne fonctionne que dans les types de publication compatibles avec Gutenberg ? Seront-ils déçus lorsqu'ils découvriront qu'ils ne peuvent pas l'utiliser avec l'éditeur Classic ?
• Lorsque ce même utilisateur vous contacte pour obtenir de l'aide, savez-vous s'il vous demande comment fonctionne votre plugin dans l'éditeur Classic ou l'éditeur Gutenberg. Ce client connaît-il même la différence ?
• Lorsque vous souhaitez ajouter des fonctionnalités des mois après le lancement, êtes-vous prêt à multiplier votre temps de développement pour intégrer cette fonctionnalité à la fois dans la méta-boîte PHP et dans le bloc JS ?

Ce ne sont là que quelques-unes des questions qui perturbent le paysage lorsque nous avançons avec deux éditeurs et aucun chemin vers la singularité dans l'interface utilisateur.

show_in_rest

Le fait que les publications ne puissent pas utiliser Gutenberg lorsque show_in_rest n'est pas défini n'est qu'un autre exemple de fonctionnalité indépendante affectant l'expérience d'édition. Il n'y a aucune raison pour que ma préférence pour la visibilité des publications publiques dans l'API REST affecte l'interface que j'utilise lors de l'édition. Je comprends les raisons techniques mais la logique n'est pas là, et je soupçonne que de nombreux développeurs ne sont même pas conscients qu'il s'agit d'une limitation à ce stade.

Comment Gutenberg est-il jamais sorti de la portée des paramètres wp_editor() me déconcerte toujours. Si "l'éditeur" Gutenberg était limité à wp_editor(), alors "l'activation en option" par type de publication deviendrait une réalité et beaucoup plus gérable et extensible à l'avenir. Je n'ai toujours pas vu d'explication rationnelle sur la raison pour laquelle le fluage de la portée de Gutenberg ne peut pas être réduit et simplement contenu dans wp_editor().

Il n'est pas logique que Gutenberg soit activé pour les types de publication personnalisés qui n'utilisent pas l'éditeur et qui ne sont pas directement affichés sur le frontend.

J'ai vu divers sites Web où les CPT sont utilisés non seulement pour les types de publication authentiques, mais comme méthode de création d'interfaces d'administration pour divers paramètres et éléments.

Par exemple, un site d'auteur sur lequel j'ai travaillé a des CPT pour « Livres » et « Liens de boutique ». Avoir Gutenberg comme éditeur des pages de listes de livres est tout à fait logique. Mais les « liens de boutique » n'ont pas de publications ou de pages propres, mais sont utilisés pour fournir la logique des liens vers des librairies en ligne sur chaque page « Livre ». Le modèle de page Livres affiche les liens de la boutique vers les pages de produits qui correspondent à la région (par exemple, Royaume-Uni, États-Unis) et au format (par exemple, ebook, impression), en insérant l'ISBN stocké dans un champ post meta dans la structure URL de chaque boutique en ligne - voir les captures d'écran.

Les CPT ne sont peut-être pas le meilleur moyen de gérer ce type de données et de paramètres, mais il existe de nombreux sites Web qui ont assemblé diverses fonctions à l'aide de CPT sans éditeur et de champs méta personnalisés - je pourrais fournir d'autres exemples de ce type d'utilisation. Il serait déroutant et contre-productif de forcer l'éditeur Gutenberg sur des CPT qui n'utilisent pas du tout l'éditeur.

Il n'est pas logique que Gutenberg soit activé pour les types de publication personnalisés qui n'utilisent pas l'éditeur et qui ne sont pas directement affichés sur le frontend.

Non, cela n'a pas de sens, mais tant que Gutenberg est un remplacement en plein écran, la décision d'inclure ou d'exclure Gutenberg a des ramifications plus importantes qui vont au-delà du fait que vous souhaitiez ou non un éditeur dans votre type de publication.

Par exemple, imaginez que vous êtes un développeur de plugin et que vous souhaitez que votre méta-boîte « Paramètres du lien de la boutique » soit disponible dans un type de publication qui utilise Gutenberg et un deuxième type de publication qui ne le fait pas. Lorsque vous distribuez un plugin à des milliers d'utilisateurs qui s'attendent à ce qu'il fonctionne avec n'importe quel type de publication, vous n'avez pas le luxe de choisir. C'est alors que les questions mentionnées dans https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663 entrent en jeu.

Il vaut la peine de répéter que les boîtes méta isolées dans leur propre type de publication sont les moins affectées par Gutenberg, nous devons donc considérer comment cela affecte la fonctionnalité du plugin qui sert à travers les types de publication.

Oui, je peux voir que les plugins devant prendre en charge à la fois les interfaces Gutenberg et non Gutenberg seraient un problème permanent majeur

Je suppose que la question qui se pose alors est de savoir comment Gutenberg devrait gérer les CPT qui ne prennent pas en charge l'éditeur - comment Gutenberg fonctionne-t-il dans des contextes où cela n'a pas de sens de créer une page à partir de blocs, où elle est uniquement axée sur les méta ?

...comment Gutenberg devrait-il gérer les CPT qui ne prennent pas en charge l'éditeur - comment Gutenberg fonctionne-t-il dans des contextes où cela n'a pas de sens de créer une page à partir de blocs, où elle est uniquement axée sur les méta ?

Si Gutenberg devait réduire et remplacer uniquement l'éditeur comme dans le concept Yoast que j'ai mentionné dans https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018, alors activer ou désactiver Gutenberg devient assez simple.

• Si editor est activé, alors l'éditeur de blocs est présent et des méta-boîtes peuvent apparaître au-dessus ou au-dessous de celui-ci en fonction des crochets utilisés.
• Si editor est désactivé, alors l'éditeur de blocs est absent et les boîtes méta glissent vers le haut pour devenir l'interface principale pour le type de publication.

C'est essentiellement comme cela que cela fonctionne aujourd'hui, et en maintenant ce comportement, cela permettrait aux plugins de passer progressivement des méta-boîtes aux blocs dans les cas où cela a du sens. Cela éviterait également un grand nombre des questions déroutantes énumérées ci-dessus qui sont associées à une expérience d'administration partagée.

Je trouve que « fluage de la portée » est un terme étrange à utiliser, compte tenu du message de lancement et de la bénédiction que le projet a reçue . Cela semble désobligeant pour le travail qui a déjà été fait, en public, depuis le 11 janvier, où nous avons commencé à discuter et à rechercher comment améliorer l'expérience de montage dans son ensemble . Rien ne s'est glissé sur nous, cela a toujours été le plan, et c'est pourquoi il n'y a pas de terme défini pour le focus.

Quoi qu'il en soit, j'aimerais parler un peu du point de vue de la Le statu quo est la solution de facilité, mais pas toujours la bonne.

Ajouter des blocs à l'éditeur existant sans repenser le flux aurait ajouté de la complexité là où il y en avait déjà .

Compte tenu du mandat – repenser la création de publications pour impliquer des blocs pour remplacer les codes courts, le HTML personnalisé, les widgets et plus encore – je gaspillerais ma responsabilité de concepteur en n'examinant pas l'ensemble du flux d'écriture, d'édition et de publication de manière holistique.

Je ne suis pas convaincu que WordPress sera pertinent dans cinq ans , à moins que le projet dans son ensemble ne prenne des mesures audacieuses pour répondre à l'avenir. Un noyau JavaScript a été annoncé dans les keynotes State of the Word pendant des années. En gardant cela à l'esprit, et l'opportunité que nous avons de simplifier radicalement la création de contenu de publication riche, regarder l'ensemble de l'expérience d'édition au lieu d'une petite fenêtre n'est pas seulement une opportunité, mais il serait sans doute négligent de concevoir autrement, malgré les défis qu'elle apporte avec ça.

Il est impossible de concevoir un bon éditeur sans regarder tout l'écran . C'est gênant, cela rend le projet difficile, et compte tenu de l'héritage de WordPress, cela le rend encore plus difficile. Cela n'a pas été facile, et nous avons encore du chemin à parcourir, notamment sur la façon dont Gutenberg peut être étendu nativement. Mais faire un demi-pas, construire Gutenberg pour remplacer uniquement la zone de texte de contenu, serait un mauvais service pour WordPress et une mauvaise conception pour démarrer.

Il est possible de charger un composant de Gutenberg , juste le canevas de l'éditeur, dans l'écran d'édition actuel. Ce sera une expérience fortement compromise et un Frankenstein d'une interface utilisateur, mais cela peut être une piste à explorer pour assurer un bon chemin de migration de 4.9 à 5.0. Mais il faut préciser que ce n'est ni l'expérience de stock, ni l'optimale.

Je suppose que la question qui se pose alors est de savoir comment Gutenberg devrait gérer les CPT qui ne prennent pas en charge l'éditeur - comment Gutenberg fonctionne-t-il dans des contextes où cela n'a pas de sens de créer une page à partir de blocs, où elle est uniquement axée sur les méta ?

@CalebWoodbridge c'est déjà comme ça que ça marche. Voir : https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

Je soutiendrais que l'utilisation du terme « fluage de la portée » n'est pas correcte. C'est un terme qui ne s'applique certainement pas à un projet qui est censé faire ce qu'est Gutenberg.

Pardonnez-moi d'avoir pris un point de côté à ce sujet, mais je pense que cela vaut la peine de le dire. Tout comme le respect est accordé aux développeurs lorsqu'ils disent quelque chose de technique, pensez aux concepteurs de la même manière. Les designers travaillant sur ce projet ont beaucoup d'expérience et de compétences, je respecte profondément le travail et c'est un plaisir d'être le responsable de la conception d'un projet avec des designers aussi incroyables.

Je me sens honoré d'avoir l'opportunité de travailler avec les designers de Gutenberg. C'est un plaisir quotidien et quelque chose que nous n'obtenons pas toujours dans WordPress. La plupart du temps, en tant que designer in core, vous êtes une personne seule, cela a été incroyable de pouvoir travailler ensemble.

L'expérience est la clé quand on regarde l'approche de conception. @jasmussen dans la vision originale avec @matias a jeté les bases d'une expérience complète. En tant que deuxième responsable de la conception, c'est quelque chose que j'apprécie et que je veux préserver.

L'un des gros problèmes avec WordPress dans le passé du point de vue de la conception a été une spirale de petites itérations en plus des petites itérations. Bien que cela fonctionne pour les premiers, au fil du temps, cela s'ajoute à une expérience maintenue avec des correctifs d'améliorations. Il y a beaucoup de WordPress qui en souffre. L'éditeur en est un, les médias en sont un autre et il y en a bien d'autres qui peuvent être pointés du doigt.

Gutenberg nous a donné de l'espace pour supprimer les correctifs, pour regarder ce que nous avons et reconstruire à nouveau. Cela nous a donné le début d'un langage visuel fort pour passer à la personnalisation et au-delà. Avoir un langage visuel qui fait avancer WordPress dans les 10 prochaines années. Oui, il faut penser aussi loin.

Je veux prendre un point pour mettre également en garde contre Frankendesigns. Chaque designer dans le monde a à un moment donné quelqu'un qui lui a suggéré de « mettre simplement x ici ou y là ». Cela ne permet pas au concepteur de concevoir. En tant que projet, nous sommes sur une spirale descendante si nous ne laissons pas les concepteurs concevoir. C'est le genre de processus qui, pour être franc, tue le feu chez les concepteurs. Gardons le feu allumé.

C'est une note personnelle, qui va au-delà de Gutenberg. Je suis passionné par le fait que nous créons un espace où les designers peuvent s'épanouir et grandir - nous ne l'avons pas toujours fait en tant que projet. Montrons avec Gutenberg que nous le faisons. La passion est grande, mais respectez la vision du design comme nous le faisons dans WordPress pour la vision technique. Écoutons les concepteurs autant que nous écoutons ceux qui parlent du dernier framework JS.

Au point d'être audacieux soulevé par @jasmussen , un bon design est audacieux. Ça l'a toujours été. Cela nécessite également de l'espace pour explorer et réfléchir, Gutenberg a été incroyable pour cela. Nous avons (nous avons toujours) un espace où nous pouvons explorer des idées qui, auparavant, nous paraissaient trop complexes à aborder. Il y a eu la liberté d'itérer, d'expérimenter et d'essayer. Cela a produit un design incroyable, ne l'oublions pas.

Je veux être clair, je ne dis pas que Gutenberg est "fini" ou parfait en tant que design. Nous devons itérer et nous devons tester. Ce dont nous n'avons pas besoin, c'est de revenir en arrière, de nous éloigner du langage de conception fort établi. Nous n'avons pas besoin de Frankendesign. Ce dont nous avons besoin, c'est de tester, d'obtenir des commentaires et de permettre aux concepteurs d'itérer.

L'un des gros problèmes avec WordPress dans le passé du point de vue de la conception a été une spirale de petites itérations en plus des petites itérations. Bien que cela fonctionne pour les premiers, au fil du temps, cela s'ajoute à une expérience maintenue avec des correctifs d'améliorations.

Essayer de concilier des déclarations comme celle-ci avec des déclarations publiques comme celle-ci http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ rend très difficile pour les utilisateurs l'impression qu'ils reçoivent une communication honnête sur le travail étant fait. WordPress est utilisé par des millions de personnes de millions de manières, et il a été clairement établi qu'en ce qui concerne les aspects techniques tels que la prise en charge des métabox ou le format de post-stockage, une approche incrémentielle est nécessaire, avec le moins de casse possible. Cette décision a compliqué plusieurs parties de la mise en œuvre et a forcé des décisions sous-optimales mais mieux soutenues à bien des égards.

Il n'est pas raisonnable de limiter le développement à une norme et la conception à une autre. Parfois, la « conception audacieuse » doit être réduite pour une production raisonnable. C'est bien connu dans la construction automobile, et c'est pourquoi il est facile de comparer Gutenberg à un concept-car.

Bien sûr, vous voulez une conception holistique qui utilise javascript pour l'intégralité de l'administrateur, mais cela ne peut pas être la version v5 sans casser l'expérience de millions d'utilisateurs. Au lieu de cela, si vous vous concentrez sur l'éditeur plutôt que sur la page d'édition, vous pouvez offrir une bien meilleure expérience (qui peut atteindre bon nombre de vos objectifs secondaires avec une utilisation judicieuse de CSS), sans casse.

Ensuite, en fournissant une API Fields bien documentée, vous pouvez convertir les plugins et les thèmes à la mentalité des blocs Gutenberg au cours de la prochaine année, en rendant plus facile et plus logique la production de la même interface. Très rapidement, les métabox deviennent l'ancienne façon de faire les choses, et tous les plugins de grande valeur passeront aux blocs... encore une fois, cela doit se faire de manière organique. Forcer la main des gens en dépréciant des fonctionnalités ou en créant une interface divisée où les auteurs de plugins doivent coder à la fois pour gutenberg et métabox est intenable.

C'est bien que vous mentionniez la refonte des médias comme un domaine qui doit être retravaillé... c'est un domaine qui a souffert à cause d'une refonte incontrôlable et inflexible. C'était la première section de WordPress à adopter pleinement un framework JS, et c'était en grande partie un énorme pas en arrière pour les développeurs. Le manque de personnalisation de la médiathèque n'est pas un signe qu'elle est parfaite, mais plutôt qu'elle manque de conception réfléchie qui prend en compte les cas d'utilisation futurs et actuels. J'ai essayé de modifier l'interface multimédia à plusieurs reprises, seulement pour découvrir que quelqu'un, à un moment donné, a décidé que les principaux composants devraient être codés en dur dans les modèles de backbone. J'ai littéralement rencontré l'un de ces cas hier ! (comme vous pouvez le voir dans le septième paragraphe ici : https://gschoppe.com/wordpress/disable-attachment-pages/)

Remettre Gutenberg à l'échelle de l'éditeur, plutôt que de la page d'édition, vous donnerait une voie à suivre qui ne casse pas tout. Une fois que Gutenberg est bien établi comme base des interfaces de publication personnalisées, la vision JavaScript uniquement peut alors prendre le relais du reste de la page d'édition. Ce type d'itération est absolument crucial dans les gros packages logiciels, à moins (comme matt l'a prétendu inacceptable) que vous proposiez des versions LTS et que vous fassiez de chaque version majeure un changement complet.

Il y a deux fosses dans lesquelles vous risquez de tomber et vous en avez identifié une. Oui, sans évoluer vers une interface unifiée utilisant les technologies modernes, WordPress mourra probablement au cours de la prochaine demi-décennie. Mais aussi, si WordPress ne parvient pas à fournir un support adéquat à sa communauté massive de développeurs et d'utilisateurs professionnels pendant cette transition, il mourra beaucoup plus tôt.

Prenez un rythme, réduisez la taille et proposez quelque chose qui ouvre la boîte à outils aux utilisateurs, sans interrompre le flux de travail existant. Ensuite, vous pouvez évoluer vers l'avant, version par version. Vous avez un beau concept car, mais ce dont nous avons besoin, c'est d'une voiture de série qui fonctionne pour tous les cas extrêmes de la conduite dans le monde réel. Mais en fournissant le concept, vous pouvez prendre cette idée et l'appliquer à une portée plus limitée, et d'ici un an, ces principes seront omniprésents

@gschoppe , merci d'avoir pris le temps de répondre.

Tout d'abord, un peu de clarté. Je ne suis pas d'accord que mon commentaire contrecarre le post de Matias. Je soutiens pleinement le message qu'il a fait, c'est ma vision aussi et nous sommes en tant que chefs de file de ce projet unis dans la façon dont nous voyons la direction. Votre opinion personnelle est la vôtre, alors passons à partir de ce point.

Il n'est pas raisonnable de limiter le développement à une norme et la conception à une autre.

Je suis d'accord et mon commentaire ne vise pas à ce que le design soit davantage entendu ou ait des normes différentes, il s'agit d'entendre toutes les voix, d'appliquer la même norme à tous.

C'est bien que vous mentionniez la refonte des médias comme un domaine qui doit être retravaillé... c'est un domaine qui a souffert à cause d'une refonte incontrôlable et inflexible.

J'adorerais voir un média se concentrer à partir de zéro sur les concepteurs et les développeurs, ce qui n'a pas été le cas.

Mais aussi, si WordPress ne parvient pas à fournir un support adéquat à sa communauté massive de développeurs et d'utilisateurs professionnels pendant cette transition, il mourra beaucoup plus tôt.

C'est intéressant que vous disiez cela car personne ne supprime aucune fonctionnalité. Aucune suggestion de conception de Gutenberg n'a fait cela. D'une manière ou d'une autre, toutes les fonctionnalités existantes peuvent être exécutées, même si cela utilise le plugin d'éditeur classique.

Je ne vois rien de plus Frankendesign que de s'appuyer sur des iframes pour reconstituer une interface utilisateur. Bien que je comprenne que les méta-boîtes jettent une clé majeure dans le processus de conception, une partie de la conception traite des limitations. Avancer comme si ces limitations n'existaient pas ou reporter le plan de transition jusqu'à la fin ajoutera une inquiétude supplémentaire à une communauté déjà inquiète et sceptique.

Si le plan à long terme pour Gutenberg était un territoire de plugin, alors je dirais expérimenter sans limites. Mais s'il n'est pas destiné à être un plugin auquel les gens doivent adhérer plutôt que de se retirer, alors il doit traiter de manière réaliste le noyau et tout le bagage qu'il apporte.

mon commentaire ne vise pas à ce que le design soit davantage entendu

Chaque designer dans le monde a à un moment donné quelqu'un qui lui a suggéré de « mettre simplement x ici ou y là ». Cela ne permet pas au concepteur de concevoir. En tant que projet, nous sommes sur une spirale descendante si nous ne laissons pas les concepteurs concevoir. C'est le genre de processus qui, pour être franc, tue le feu chez les concepteurs. Gardons le feu allumé.

Dans toutes les entreprises du monde, les conceptions sont ajustées aux contraintes de la mise en œuvre. Si la rétrocompatibilité des métaboîtes est une contrainte, la conception doit l'accepter et respecter les contraintes.

Pour être franc, la prise en charge complète des métabox, sans perte d'accessibilité, est-elle une contrainte de conception ou non ? J'aimerais une réponse claire, comme des milliers d'autres.

Aucune suggestion de conception de Gutenberg n'a fait cela. D'une manière ou d'une autre, toutes les fonctionnalités existantes peuvent être exécutées, même si cela utilise le plugin d'éditeur classique.

Actuellement, Gutenberg place tous les champs méta dans un iframe. Cela casse la fonctionnalité à un niveau très profond. Nous sommes à l'ère de l'accessibilité, et prendre la principale méthode attendue pour créer des expériences utilisateur personnalisées et l'enfermer dans un iframe supprime fondamentalement toute accessibilité de ces outils. Il triple également le nombre de requêtes requises pour charger l'éditeur et offre aux utilisateurs une interface utilisateur terrible, emprisonnant des expériences modales en plein écran dans une zone minuscule.

Actuellement, ce fil discute si Gutenberg doit être activé ou désactivé pour les types de publication personnalisés. Si opt-in, les décisions d'interface utilisateur précédemment cohérentes prises par les développeurs qui souhaitent prendre en charge tous les types de publication seront fracturées entre l'expérience Gutenberg et l'expérience classique, nécessitant deux fois plus de travail de développement pour fournir une expérience utilisateur raisonnable pour les deux, et n'assurant aucune cohérence de l'expérience utilisateur.

Actuellement, la fonction wp_editor() (qui est la meilleure méthode actuelle pour implémenter une copie complète de l'expérience d'édition sur des pages non éditées) ne fournit pas d'interface Gutenberg, ce qui signifie que je ne peux pas créer des expériences d'édition personnalisées sur des pages non publiées... quelle est ma voie à suivre, à part donner aux utilisateurs une UX partagée ?

Bien que le plugin pour supprimer Gutenberg puisse résoudre certains problèmes, vous ne pouvez pas l'envoyer comme solution pour les développeurs de plugins. Ils n'ont pas la liberté de dire "si vous voulez une interface utilisateur cohérente et accessible pour tous les types de publication, vous devez désactiver le nouvel éditeur".

La suppression de fonctionnalités n'est PAS une rétrocompatibilité pour le flux de travail standard. La suppression de fonctionnalités est le dernier recours pour les 1% d'utilisateurs qui ne peuvent pas être hébergés comme des expériences de première classe. Dans ce cas, aucun des exemples que j'ai donnés n'est un problème de 1%.

Pour ajouter un peu d'huile dans les flammes : la semaine dernière, j'ai rencontré un énorme problème avec l'utilisation d'iFrames, c'est-à-dire. ils peuvent jouer bien sur les systèmes Desktop, mais dans 90% des cas testés, ils échouent massivement sur Mobile / Responsive. Après avoir parcouru de nombreux fils de discussion, des articles sur le net et des questions sur Stack Overflow, j'ai décidé d'abandonner totalement l'approche iframe, car la réactivité devient si horriblement compliquée avec em .. ugh. Certaines tâches de conversion étaient plutôt faciles à faire, comme "utiliser une redirection vers le sous-domaine réel où réside le projet" au lieu de s'appuyer sur une iframe pour mettre en place une belle décoration, c'est-à-dire ne montrant que le domaine principal supposé, mais d'autres étaient beaucoup plus misérables.

Néanmoins, par rapport à l'énorme quantité de travail que je devais faire pour obtenir RWD correctement, et surtout, fiable ET maintenable, pour travailler avec des iframes, le revirement était beaucoup moins d'effort et donc la meilleure solution.

Pour résumer, bien que les iframes semblent à première vue être une solution de facilité, elles constituent un TRÈS MAUVAIS choix de conception, pas seulement à cause de (beaucoup) de problèmes d'accessibilité.

Juste mon .02 centimes,
cu, w0lf.

Merci @mtias d' avoir montré ce problème.
Ci-dessous, je publie mes réflexions sur la façon dont Gutenberg peut ouvrir des portes aux développeurs de plugins WordPress.

Classe CSS personnalisable pour tout bloc existant

Nécessaire : classe CSS pour chaque wrapper de bloc et accès complet pour le personnaliser. Ce sera formidable si Gutenberg exige une classe CSS sur l'élément tout en haut, même de la part de développeurs tiers.

Objectif : De cette façon, nous pouvons ajouter des classes personnalisées aux blocs pour un style avancé. Nous pouvons également utiliser des classes pour ajouter des animations ou d'autres propriétés de bloc avancées.

Exemple d'utilisation : nous créons un site Web pour un gros client avec un langage de conception strictement défini. Side editor devrait pouvoir créer des blocs avec un nombre prédéfini de styles créés par notre designer, spécialement pour ce client.

Attributs de données personnalisables pour tout bloc existant

Nécessaire : possibilité d'ajouter des attributs de données personnalisés pour n'importe quel wrapper de bloc.

Objectif : alternative plus propre et plus flexible aux classes CSS personnalisées décrites ci-dessus. Avec les attributs de données, nous pouvons styliser n'importe quel élément de la page. Outre le style, les attributs de données personnalisés peuvent être utilisés pour stocker des métadonnées supplémentaires pour JS.

Exemple d'utilisation :

• blocs réactifs : marquez un bloc à afficher uniquement sur mobile/ordinateur de bureau
• blocs conditionnels : marquer un bloc à afficher/masquer avec JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...
• animation de bloc : marquer un bloc à animer <div data-animation="on-load animation-style-3"...
• conception de bloc : <div data-skin="dark"...