El equipo de desarrollo de Gutenberg confirma que la API de Meta Box no quedará obsoleta formalmente

La discusión sobre cómo Gutenberg manejará los metaboxes se calentó durante el fin de semana después de que un participante comentara sobre el problema de GitHub con su preocupación sobre la eliminación del soporte de metaboxes del hito más reciente.

“Veo que este tema vital se ha eliminado de cualquier hito”, dijo @steveangstrom. “Se le ha quitado prioridad nuevamente, mientras que las campanas y silbatos para la edición de blogs requieren mucho trabajo y se agregan a las versiones beta. Esto es muy preocupante para el futuro de WordPress como CMS”.

James Nylen, uno de los principales desarrolladores del proyecto, aseguró a los seguidores del tema que el equipo de Gutenberg no se ha olvidado del problema, sino que es “un problema extremadamente complicado que recién estamos comenzando a investigar, junto con muchos, muchas otras prioridades para que el editor funcione bien”. También pidió ayuda a la comunidad para planificar y probar implementaciones para admitir cajas meta.

Esta respuesta dejó muchas cosas sin aclarar. Los participantes en la discusión, muchos de los cuales son desarrolladores preocupados por la posibilidad de tener que reescribir todos sus metaboxes como componentes de React, se preguntan por qué los metaboxes no pueden funcionar junto con el nuevo editor de Gutenberg y por qué el equipo eligió incluir metaboxes en el alcance del proyecto.

"¿Es posible reemplazar el editor de publicaciones TinyMCE existente con Gutenberg y dejar el resto de la interfaz, incluidos los metaboxes y los ganchos existentes, sin cambios?" preguntó Kevin Hoffmann. Cuando Nylen aclaró que Gutenberg, tal como está escrito hoy, pretende ser un editor de post_content , Hoffman resumió las preocupaciones que muchos desarrolladores han expresado:

Si Gutenberg está realmente destinado a ser un editor de post_content , entonces los metaboxes deben dejarse solos, ya que no están relacionados con post_content .

Además, la necesidad de una API para traducir metaboxes de PHP a metaboxes de React es un problema fabricado. No tiene por qué ser un problema, pero se ha convertido en un problema porque en algún momento se decidió que reescribir el editor post_content también debería cambiar por completo la forma en que funcionan los metaboxes.

Ha esbozado el tremendo desafío de escribir una API de este tipo en el n.º 2251. Traducir metaboxes de PHP a React para una solución popular de campos personalizados como ACF es lo suficientemente desafiante, y mucho menos intentar hacerlo para cada implementación de metaboxes que existe hoy en día, popular o no. No escala.

Como los colaboradores de Gutenberg compartieron que acaban de comenzar a analizar el problema del metabox, ahora está claro por qué no hay una hoja de ruta sobre cómo el proyecto manejará los metaboxes "heredados" de PHP. En julio, Nylen dijo: "Si tuviera que adivinar dónde terminaremos aquí: los metaboxes actuales se moverán a un área "heredada" y proporcionaremos API, documentación y ejemplos para registrar metabox-block de 'nuevo estilo'. cositas.

Los desarrolladores de complementos que administran bibliotecas de metabox, agencias y otras partes interesadas están siguiendo el ticket para descubrir cómo planificar WordPress 5.0, que se ha considerado como el lanzamiento de Gutenberg. Andrey Savchenko preguntó si WordPress planea desaprobar formalmente la API de metabox, lo que finalmente obtuvo una respuesta clara del equipo. Matías Ventura respondió:

“¿Pretende WordPress desaprobar formalmente la API de Metabox?”
No.

La pregunta que aún no está completamente respondida es cómo funcionan los meta-boxes en el contexto del editor de Gutenberg. ¿Deberían permanecer igual o evolucionar? ¿Cómo podemos avanzar hacia los objetivos de diseño con la menor cantidad de interrupciones posible?

Este problema ha estado persistiendo no por falta de ganas, sino por falta de recursos. El objetivo principal de este proyecto es ofrecer una rica interfaz de edición de contenido que se optimice para la manipulación directa del contenido del usuario a través de la noción de bloques. (Después de haber usado meta-boxes extensivamente para varios proyectos, creo que los bloques pueden ofrecer un mejor paso adelante para muchas de esas necesidades al tiempo que brindan una mejor experiencia de usuario).

Ventura enumeró varias opciones que el equipo ha considerado para manejar metaboxes y solicitó ayuda de la comunidad para construir la mejor solución:

• Si detectamos que un meta-box está registrado, podemos recurrir a la interfaz anterior, nada cambia.
• Podríamos dividir la edición del contenido y la modificación de la metainformación en dos pantallas o etapas.
• Podemos intentar ver qué tan factible es representarlos tal como están (PHP) debajo del contenido: #2251.
• Un tema/complemento/CPT podría anular el registro de la nueva interfaz según sea necesario.
• Varios elementos que dependían de los metacuadros podrían convertirse en bloques para la interfaz de usuario (todavía almacenando datos por separado).
• Podríamos implementar la extensibilidad de metaboxes basada en API como la API de campos.

Cuando se le presionó para responder a la pregunta de por qué se incluyen los metaboxes en el contexto del nuevo editor, el líder de diseño de Gutenberg, Joen Asmussen, aclaró cómo el equipo decidió incluir metaboxes en el alcance del proyecto:

Gutenberg comenzó solo con el cuadro del editor. El objetivo inicial era unificar múltiples interfaces dispares bajo una sola interfaz de bloque unificado. Rápidamente se hizo evidente que para que pudiéramos crear una experiencia convincente en torno a esta interfaz de bloque unificado, teníamos que considerar el flujo de escritura completo, incluida la configuración y la publicación.

Si la fortaleza clave de WordPress es facilitar a cualquier persona la creación de publicaciones ricas, entonces no podemos simplemente diseñar para aquellos de nosotros que ya sabemos cómo usar el editor. Tenemos que considerar a los usuarios que nunca antes han usado WordPress y lo que esperan de una interfaz de publicación moderna. De lo contrario, solo estaríamos agregando carga cognitiva a una interfaz que ya es pesada.

La cuestión de cómo encajarán los metaboxes en el contexto del editor de Gutenberg sigue abierta. Los participantes en la discusión están ansiosos por que se responda esta pregunta por el bien de la compatibilidad con versiones anteriores y también porque afecta las decisiones en curso con respecto al desarrollo de Gutenberg y el diseño de la pantalla.

“Entiendo completamente cuánto trabajo se ha hecho para el enfoque de reemplazo de la 'pantalla'”, comentó Xavi Ivars sobre el tema. “Pero, ¿no debería un proyecto que comenzó con el objetivo de reemplazar un 'editor de contenido posterior' volver a la comunidad antes de decidir unilateralmente que reemplazaría toda la pantalla del editor?”

La API de metabox no está en desuso, pero tampoco hay un camino claro sobre cómo Gutenberg admitirá metaboxes de PHP "heredados". El equipo de Gutenberg dijo que el problema no se ha resuelto debido a la falta de recursos. El proyecto necesita aportes de la comunidad y una mejor comunicación si el equipo va a aterrizar en una solución que llevará sin problemas a la mayoría de los sitios de WordPress a la era Gutenberg con la menor cantidad de roturas.

Actualmente, la viabilidad de renderizar metaboxes de PHP heredados debajo del contenido está plagada de desafíos y aún está en debate. Si no hay suficiente tiempo o recursos del cliente para que los desarrolladores reescriban su trabajo en cajas de metadatos impulsadas por JS, entonces puede ser necesario un camino claro para optar por no participar en la interfaz de Gutenberg para los sitios que necesitan preservar las cajas de metadatos "PHP" heredadas. .