L'équipe de développement de Gutenberg confirme que l'API Meta Box ne sera pas officiellement obsolète

Publié: 2017-08-09
crédit photo : Doors Open Toronto 2008 – Archives de Toronto – (licence)

La discussion sur la façon dont Gutenberg gérera les méta-boîtes s'est réchauffée au cours du week-end après qu'un participant a commenté le problème de GitHub avec inquiétude concernant la suppression de la prise en charge des méta-boîtes du jalon le plus récent.

"Je vois que ce problème vital a été supprimé de toute étape importante", a déclaré @steveangstrom. «Il a de nouveau été dépriorisé tandis que les cloches et les sifflets pour l'édition de blogs demandent beaucoup de travail et sont ajoutés aux bêtas. C'est très inquiétant pour l'avenir de WordPress en tant que CMS.

James Nylen, l'un des principaux développeurs du projet, a rassuré les adeptes du sujet que l'équipe de Gutenberg n'a pas oublié le problème mais plutôt qu'il s'agit "d'un problème extrêmement compliqué que nous commençons seulement à examiner, avec beaucoup, beaucoup d'autres priorités pour que l'éditeur fonctionne bien. Il a également demandé l'aide de la communauté pour planifier et tester des implémentations pour prendre en charge les méta-boîtes.

Cette réponse a laissé beaucoup de choses dans le flou. Les participants à la discussion, dont beaucoup sont des développeurs préoccupés par la perspective de devoir réécrire toutes leurs méta-boîtes en tant que composants React, se demandent pourquoi les méta-boîtes ne peuvent pas fonctionner avec le nouvel éditeur Gutenberg et pourquoi l'équipe a choisi d'inclure les méta-boîtes dans la portée du projet.

"Est-il possible de remplacer l'éditeur de publication TinyMCE existant par Gutenberg tout en laissant le reste de l'interface, y compris les méta-boîtes et les crochets existants, inchangés ?" a demandé Kevin Hoffman. Lorsque Nylen a précisé que Gutenberg, tel qu'il est écrit aujourd'hui, est destiné à être un éditeur de post_content , Hoffman a résumé les préoccupations exprimées par de nombreux développeurs :

Si Gutenberg est vraiment destiné à être un éditeur post_content , alors les méta-boîtes doivent être laissées seules car elles ne sont pas concernées par post_content .

De plus, le besoin d'une API pour traduire les méta-boîtes PHP en méta-boîtes React est un problème fabriqué. Cela n'a pas à être un problème, mais c'est devenu un problème car quelque part le long de la ligne, il a été décidé que la réécriture de l'éditeur post_content devrait également changer complètement le fonctionnement des boîtes méta.

Vous avez décrit l'énorme défi d'écrire une telle API dans #2251. Traduire les méta-boîtes PHP en React pour une solution de champs personnalisés populaire comme ACF est déjà assez difficile, sans parler d'essayer de le faire pour chaque implémentation de méta-boîte qui existe aujourd'hui, populaire ou non. Il n'est pas à l'échelle.

Comme les contributeurs de Gutenberg ont partagé qu'ils venaient tout juste de commencer à se pencher sur le problème de la méta-boîte, il est maintenant clair pourquoi il n'y a pas de feuille de route sur la façon dont le projet gérera les méta-boîtes PHP "héritées". En juillet, Nylen a déclaré : "Si je devais deviner où nous nous retrouverions ici : les métaboxes actuelles seront déplacées vers une zone "héritée" et nous fournirons des API, de la documentation et des exemples pour l'enregistrement d'un bloc de métaboxes "nouveau style". -trucs.

Les développeurs de plugins qui gèrent les bibliothèques de méta-boîtes, les agences et les autres parties concernées suivent le ticket pour savoir comment planifier WordPress 5.0, qui a été ciblé comme la version de Gutenberg. Andrey Savchenko a demandé si WordPress prévoyait de déprécier formellement l'API de la méta-boîte, ce qui a finalement attiré une réponse claire de l'équipe. Matias Ventura a répondu

"Est-ce que WordPress a l'intention de déprécier formellement l'API Metabox ?"
Non.

La question à laquelle il n'y a pas encore de réponse complète est de savoir comment fonctionnent les méta-boîtes dans le contexte de l'éditeur Gutenberg. Doivent-ils rester les mêmes ou évoluer ? Comment pouvons-nous progresser vers les objectifs de conception avec le moins de perturbations possible ?

Ce problème persiste non pas par manque de volonté, mais par manque de ressources. L'objectif principal de ce projet est d'offrir une interface d'édition de contenu riche qui optimise la manipulation directe du contenu utilisateur grâce à la notion de blocs. (Ayant largement utilisé les méta-boîtes pour divers projets, je pense que les blocs peuvent offrir un meilleur pas en avant pour bon nombre de ces besoins tout en offrant une meilleure expérience utilisateur.) »

Ventura a répertorié plusieurs options que l'équipe a envisagées pour gérer les méta-boîtes et a demandé l'aide de la communauté pour créer la meilleure solution :

  • Si nous détectons qu'une méta-boîte est enregistrée, nous pouvons revenir à l'ancienne interface, rien ne change.
  • Nous pourrions diviser l'édition du contenu et la modification des méta-informations en deux écrans ou étapes.
  • Nous pouvons essayer de voir dans quelle mesure il est possible de les rendre tels quels (PHP) sous le contenu : #2251.
  • Un thème/plugin/CPT pourrait désenregistrer la nouvelle interface si nécessaire.
  • Divers éléments qui reposaient sur des boîtes méta pouvaient être convertis en blocs pour l'interface utilisateur (en stockant toujours les données séparément).
  • Nous pourrions implémenter l'extensibilité des méta-boîtes basées sur l'API, comme l'API Fields.

Lorsqu'on lui a demandé pourquoi les méta-boîtes étaient incluses dans le contexte du nouvel éditeur, le responsable de la conception de Gutenberg, Joen Asmussen, a expliqué comment l'équipe avait décidé d'inclure les méta-boîtes dans le cadre du projet :

Gutenberg a commencé juste avec la boîte de l'éditeur. L'objectif de lancement était d'unifier plusieurs interfaces disparates sous une seule interface de bloc unifiée. Il est rapidement devenu évident que pour que nous puissions créer une expérience convaincante autour de cette interface de bloc unifiée, nous devions prendre en compte le flux d'écriture complet, y compris les paramètres et la publication.

Si la principale force de WordPress est de permettre à quiconque de créer facilement des publications riches, nous ne pouvons pas simplement concevoir pour ceux d'entre nous qui savent déjà utiliser l'éditeur. Nous devons tenir compte des utilisateurs qui n'ont jamais utilisé WordPress auparavant et de ce qu'ils attendent d'une interface de publication moderne. Sinon, nous ne ferions qu'ajouter une charge cognitive à une interface déjà lourde.

La question de savoir comment les méta-boîtes s'intégreront dans le contexte de l'éditeur Gutenberg est toujours ouverte. Les participants à la discussion sont impatients d'avoir une réponse à cette question pour des raisons de rétrocompatibilité et aussi parce qu'elle affecte les décisions en cours concernant le développement de Gutenberg et la conception de l'écran.

"Je comprends parfaitement tout le travail qui a été fait pour l'approche de remplacement" de l'écran "", a commenté Xavi Ivars sur la question. "Mais un projet qui a commencé avec l'objectif de remplacer un 'post content editor' n'aurait-il pas dû revenir à la communauté avant de décider unilatéralement qu'il remplacerait tout l'écran de l'éditeur?"

L'API de la méta-boîte n'est pas obsolète, mais il n'y a pas non plus de voie claire pour savoir comment Gutenberg prendra en charge les méta-boîtes PHP "héritées". L'équipe de Gutenberg a déclaré que le problème n'avait pas été résolu en raison du manque de ressources. Le projet a besoin de la contribution de la communauté et d'une meilleure communication si l'équipe veut atterrir sur une solution qui fera entrer de manière transparente la majorité des sites WordPress dans l'ère Gutenberg avec le moins de casse.

Actuellement, la faisabilité du rendu des méta-boîtes PHP héritées sous le contenu est semée d'embûches et reste à débattre. S'il n'y a pas assez de temps ou de ressources client pour que les développeurs réécrivent leur travail dans des méta-boîtes basées sur JS, un chemin clair pour se retirer de l'interface Gutenberg peut être nécessaire pour les sites qui doivent conserver les anciennes méta-boîtes "PHP". .