Colaboradores de Gutenberg discuten los inconvenientes de usar iframes para metaboxes

En GitHub se está produciendo un debate animado y productivo sobre el uso de iframes por parte de Gutenberg para metaboxes. Ayer, el desarrollador de WordPress Kevin Hoffman creó un problema titulado "¿Son los iframes una solución viable a largo plazo para metaboxes?"

Gutenberg 1.5 introdujo soporte inicial para metaboxes. Hoffman identificó varios problemas con iframes que han estado apareciendo a medida que los desarrolladores comenzaron a probar la implementación actual de meta box. Hizo algunas pruebas de rendimiento que revelaron que el uso de iframes por parte de Gutenberg triplica la cantidad de solicitudes de activos, ya que pone en cola todos los activos CSS y JS en la ventana principal, así como en todos los iframes.

“En términos generales, los iframes se han desaconsejado en el desarrollo web durante muchos años por razones que están bien documentadas”, dijo Hoffman, antes de citar una letanía de problemas que los desarrolladores de complementos ya han descubierto al probar el soporte de meta box de Gutenberg. “¿Se pueden abordar estos problemas sin requerir la modificación del tema o complemento que genera el metabox? Tenemos que considerar que el código de terceros que ha impulsado metaboxes durante años puede no tener el lujo de actualizarse para ser compatible dentro de un iframe”.

La líder de diseño de Gutenberg, Tammie Lister, respondió a las preocupaciones de Hoffman, indicando que la implementación actual de metaboxes es simplemente un experimento y no necesariamente lo que aterrizaría en WordPress 5.0:

Es bueno pensar un poco que lo que tenemos hoy para las cajas meta en Gutenberg es un experimento, en muchos aspectos es un patrón de espera a medida que el proyecto determina la dirección a seguir. Al decir que es uno que funciona 'por ahora' pero no es lo que enviaríamos.

Dicho todo lo anterior, creo que es importante ver para qué se usarán los metaboxes en el futuro. ¿Cuáles son los casos (si los hay) que no se convertirían en bloques? ¿Todos los metaboxes tienen que funcionar en el móvil? ¿Hay incluso una interfaz alternativa que no hayamos explorado? Apuesto a que hay. En este momento, se trata de ver esas posibilidades y tomar un camino que funcione para el estado ahora y el estado futuro.

La presentación de esta implementación como un experimento que "funciona por ahora" (pero no se enviará) sorprende después de que llegara Gutenberg 1.5 con el anuncio de que "esta versión incluye la compatibilidad con meta-boxes largamente esperada (¡necesita pruebas!)".

Hoffman sostiene que el enfoque de iframe ni siquiera funciona 'por ahora', ya que el problema se abrió para citar varias formas importantes en las que se rompe. Si Gutenberg avanza con el enfoque actual, sería necesario modificar muchos complementos para que sean compatibles con WordPress 5.0, lo que, según Hoffman, anularía todo el propósito de admitir metaboxes heredados.

“No he visto ninguna evidencia hasta la fecha que sugiera que las cajas meta seguirán funcionando con Gutenberg”, dijo Hoffman. “Si la respuesta es no, entonces deberíamos dejar de fingir que 5.0 será solo otro lanzamiento de WordPress y comenzar a ser honestos acerca de romper la compatibilidad con versiones anteriores”.

Edwin Cromley, colaborador del proyecto, dijo que el equipo anticipa que ciertos temas y complementos se romperán y que no es posible adaptarse a todos los casos de uso posibles. Admitió que es posible que la solución iframe no cumpla con los objetivos del proyecto. En cambio, aboga por crear la mejor experiencia para la gran mayoría de los usuarios.

Sin embargo, el enfoque actual afectaría negativamente a muchos sitios que usan WordPress principalmente como un CMS con metaboxes. El responsable principal de WordPress, Scott Taylor, expresó su preocupación por los tipos de publicaciones personalizadas, muchas de las cuales no utilizan la sección tradicional de "contenido" en favor de los metaboxes únicamente.

“En esta iteración actual, la compatibilidad con metaboxes es un complemento, cuando en la realidad de muchas personas, los metaboxes SON la interfaz de usuario, la API, el mecanismo que utilizan para componer su CMS”, dijo Taylor. “Los iframes son el gulag.

“Y estamos olvidando los valores en los que se ha creado WP desde siempre: debería poder actualizar a la última versión de WP y no tener que volver a escribir nada. Tengo tantos proyectos en libertad en WP que nunca volveré a tocar. ¿Puedo estar seguro de que algunos de ellos no romperán salvajemente con este cambio?”

Hoffman abogó por reducir el alcance del proyecto para centrarse en el componente del editor, una opinión popular que comparten muchos desarrolladores de complementos y que se ilustró en detalle en la publicación de Yoast que propone un enfoque alternativo a Gutenberg. Este enfoque presenta los cambios en la pantalla de edición, dando a los desarrolladores más tiempo para actualizar sus complementos, además de permitir que el equipo de Gutenberg encuentre una solución adecuada para los metaboxes.

“Creo que ese objetivo sería mucho más alcanzable si Gutenberg se limitara a revisar el editor en lugar de hacerse cargo de toda la página”, dijo Hoffman. “Entonces podríamos dejar los ganchos existentes en su lugar y las cajas meta podrían continuar comunicándose entre sí como lo hacen ahora. Además, la puesta en cola de activos no sería un problema, ya que funcionaría como lo hace hoy.

"Estoy totalmente de acuerdo con este concepto presentado por Yoast, que me parece que mantendría gran parte del trabajo ya realizado mientras reduce el alcance del proyecto para centrarse en el componente del editor".

El ingeniero de Gutenberg, Riad Benguella, indicó que el equipo no está muy interesado en trabajar en este concepto.

“Reutilizar piezas de Gutenberg para construir este concepto es relativamente factible, pero este no es el UX para el que queremos optimizar, primero queremos construir el mejor editor posible y ponerlo a disposición de las personas sin problemas de compatibilidad con versiones anteriores (instalaciones nuevas, sin metaboxes… )”, dijo Benguella.

“Cuando pensemos que la visión ideal de Gutenberg está lista para enviarse, tendremos tiempo para discutir estrategias de ruta de actualización, un concepto como este es una opción para una ruta de actualización, pero definitivamente no como el producto final. También son posibles otras rutas de actualización”.

Sin embargo, la comunidad de desarrolladores de WordPress no está a favor de retrasar esta discusión una vez más. Muchos están ansiosos por responder finalmente a la pregunta de cómo encajarán los metacuadros en el contexto del editor de Gutenberg para que sepan cómo prepararse. Dados los numerosos problemas con el enfoque de iframes, renderizar metaboxes PHP heredados bajo el nuevo editor requerirá más experimentación y posiblemente una solución alternativa.

"¿Por qué dedicar miles de horas a desarrollar el editor ideal si no se puede hacer compatible con los sitios existentes?" dijo Hoffmann. “Si la primera impresión es que rompe la interfaz de usuario de la que dependen, los usuarios nunca experimentarán el editor ideal en primer lugar”.

“Creo que puede ser un error posponer esto demasiado”, dijo Aaron Jorbin, responsable principal de WordPress. “Especialmente porque muchas organizaciones necesitarán al menos 1 o 2 trimestres para prepararse”.

Mark Kaplun sugiere que el equipo de Gutenberg use un complemento popular como indicador del éxito de los experimentos actuales y futuros de soporte de meta box.

"Mi sugerencia productiva es no declarar metaboxes listos, siempre y cuando Yoast SEO no funcione correctamente en ellos", dijo Kaplun. “Es un poco complejo en términos de interacciones y está instalado en un montón de sitios. Si Gutenberg no puede trabajar con él, probablemente nadie lo vaya a usar”.

Greg Schoppe, quien ha probado y escrito extensamente sobre el desarrollo continuo de Gutenberg, se unió a la conversación para abogar por el enfoque alternativo de Yoast para el proyecto también.

“Apoyo mucho la opinión de Yoast sobre Gutenberg”, dijo Schoppe. “No me queda claro cómo el equipo de Gutenberg reinterpretó 'actualizar el editor visual' para que sea 'reemplazar toda la interfaz de edición posterior', pero parece directamente en desacuerdo con el llamado 'Barco de Teseo'.

“En este caso, la falta de una dirección clara y soporte para los flujos de trabajo estándar existentes está perjudicando activamente a los desarrolladores ahora. ¿Cómo puedo avanzar en la construcción de un proyecto sin un conjunto confiable de ganchos y herramientas en los que pueda confiar? Es inconcebible pensar que un proyecto de software tan grande alteraría por completo el flujo de trabajo estándar para los desarrolladores en una sola actualización. y es una locura que estas conversaciones estén sucediendo ahora, en noviembre, cuando el plan es aprobar una fusión a principios de año”.

La discusión sobre el enfoque de iframes para los metaboxes que se abrió ayer todavía es relativamente nueva, pero hasta ahora las respuestas del equipo de Gutenberg no han logrado abordar adecuadamente las preocupaciones de la comunidad de desarrolladores en este hilo. Uno de los mayores desafíos del equipo de Gutenberg es encontrar un enfoque para los metaboxes que preserve las poderosas capacidades de CMS de WordPress, sin alejar a los usuarios y desarrolladores. Todavía tienen como objetivo producir una propuesta de fusión a principios del próximo año, pero con los metaboxes aún en la etapa de experimentación, el cronograma anticipado del equipo continúa poniendo el proyecto en desacuerdo con la comunidad de desarrolladores de WordPress.