Gutenberg: ¿Son los iframes una solución viable a largo plazo para las metacajas?

1. ... Gutenberg actualmente usa dos iframes separados para la columna principal y la barra lateral. Si admitimos metacuadros que aparecen después del Título, eso teóricamente resultaría en un tercer iframe. ¿Presentará esto algún problema con respecto a cómo los complementos ponen en cola los activos que deben afectar a todas las metacajas iframed?

Hice algunas pruebas de rendimiento esta noche y encontré este descubrimiento en mi pestaña Red, lo cual es alarmante. Parece que todos los activos de CSS y JS que están en cola en la ventana principal también están en cola en el iframe de la columna principal y en el iframe de la barra lateral, lo que significa que cada activo se solicita un total de tres veces, triplicando efectivamente el número de solicitudes de activos cuando se usa Gutenberg .

El daño del peso de la página se reduce con el almacenamiento en caché del navegador habilitado, pero la cantidad de solicitudes de activos aún se triplica. Supongo que esto se está haciendo para que cada iframe tenga los activos que necesita para permitir que las metacajas funcionen, pero seguramente esta no puede ser la solución para poner en cola los activos en el futuro.

Gracias por crear el problema y tus ideas @kevinwhoffman. Es bueno pensar un poco que lo que tenemos hoy para los metaboxes en Gutenberg es un experimento, en muchos aspectos es un patrón de espera mientras el proyecto determina la dirección a seguir. Al decir que es uno que funciona 'por ahora' pero que no es con lo que enviaríamos.

Dicho todo lo anterior, creo que es importante ver para qué se utilizarán las 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 dispositivos móviles? ¿Existe alguna interfaz alternativa que no hayamos explorado? Apuesto a que sí. En este momento, se trata de mirar esas posibilidades y tomar un camino que funcione para el estado en este momento y el estado futuro.

En este momento, los errores que existen con la versión actual de metaboxes en Gutenberg deben corregirse y ese es un enfoque. El rendimiento debe entrar en esta solución. En cuanto a los dispositivos móviles, los metaboxes han sido un problema durante mucho tiempo, no lo estamos empeorando aquí. Dicho esto, deberíamos trabajar por una mejor solución en el futuro. Es importante retroceder y recordar que esta es solo una solución "actual" a medida que iteramos y seguimos siendo libres para pensar en una mejor opción.

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

El enfoque de iframe no funciona, ni siquiera "por ahora". Los problemas relacionados enumerados anteriormente proporcionan ejemplos de metacajas que no funcionan de manera importante. Además, incluso si esos problemas se corrigieran, triplicar el peso de la página y el número de solicitudes no debe considerarse "funcional" bajo ninguna circunstancia.

Dicho todo lo anterior, creo que es importante ver para qué se utilizarán las metaboxes en el futuro.

Respetuosamente, esto sucede cada vez que se plantea el tema de las metacajas. Por favor, en lugar de cambiar la conversación a futuros metabloques, sería realmente útil enmarcar esta discusión en torno a los problemas que enfrentan los metaboxes existentes. Una vez más:

¿Se pueden abordar estos problemas sin necesidad de modificar el tema o el complemento que genera el metabox?

Hasta la fecha, no he visto ninguna evidencia que sugiera que las metacajas continuarán trabajando con Gutenberg. Si la respuesta es no, entonces debemos dejar de fingir que 5.0 será solo otra versión de WordPress y comenzar a ser honestos acerca de romper la compatibilidad con versiones anteriores.

Hola Kevin,

Gracias por el informe detallado. Creo que muchos de los temas se pueden retocar hasta cierto punto. Esta es también una exploración de si el enfoque de iframe funcionará y hasta dónde se puede llevar, por lo que es bueno tener este tipo de diálogo y hacer una crónica de las deficiencias de este enfoque.

¿Es posible abrir una ventana de contenido desde un metabox que se extiende más allá del iframe?

¿Te refieres a una caja de luz modal que debería ocupar toda la página?

¿Te refieres a una caja de luz modal que debería ocupar toda la página?

Ese sería un ejemplo, pero me refiero más a cualquier escenario en el que sea necesario revelar contenido que no esté dentro de los límites del iframe.

Por ejemplo, ¿puedo hacer clic en un botón de la barra lateral que activa un cuadro de contenido en el centro de la página? Si ese cuadro de contenido está dentro del iframe, entonces no será visible fuera de las dimensiones del iframe en la barra lateral.

El siguiente paso lógico sería llamar a la función en el documento principal desde el iframe. Pero los complementos actualmente no están escritos para funcionar así, y requerir que se modifiquen anularía todo el propósito de admitir cajas meta _legacy_. No puedo enfatizar lo suficiente que cualquier solución que se decida debe funcionar sin modificar los temas o complementos existentes.

Sabiendo cuán negativa es la implementación de iFrame con respecto a los activos de complementos / temas, creo que esto debería hacer que el proyecto se detenga. La respuesta real aquí es que WordPress envía la API de Fields https://github.com/sc0ttkclark/wordpress-fields-api ; sin eso, implementar metaboxes de manera efectiva con Gutenberg es prácticamente imposible si nos preocupamos por el rendimiento.

Si realmente no enviamos Gutenberg hasta que esté "listo", entonces digo que deberíamos prestar la misma atención a la API de Fields para que los metboxes funcionen correctamente y sin problemas con React en Gutenberg.

El siguiente paso lógico sería llamar a la función en el documento principal desde el iframe. Pero los complementos actualmente no están escritos para funcionar de esa manera, y requerir que se modifiquen anularía todo el propósito de admitir cajas meta heredadas. No puedo enfatizar lo suficiente que cualquier solución que se decida debe funcionar sin modificar los temas o complementos existentes.

Sí, definitivamente una preocupación que tuve mientras hacía esto. La comunicación cruzada entre iframes no suena muy bien. También hay otras alternativas para explorar.

Sin embargo, definitivamente habrá casos en los que ciertos complementos de temas se romperán, y no es posible acomodar todos los casos de uso posibles, creo que tal vez un mejor objetivo es crear una buena experiencia para la gran mayoría de usuarios y casos de uso. . Es muy posible que la solución de iframe actual no cumpla con ese objetivo.

Puede valer la pena señalar que en una publicación reciente de

Hola mathetos,

Si realmente no enviamos Gutenberg hasta que esté "listo", entonces digo que deberíamos prestar la misma atención a la API de Fields para que los metboxes funcionen correctamente y sin problemas con React en Gutenberg.

Estoy de acuerdo en que una API de Fields sería algo agradable. Sin embargo, eso también implicaría que las personas adopten la API de campos. Si no muchos están dispuestos a reescribir su complemento / tema para Gutenberg, no creo que estén dispuestos a hacerlo para una API de Fields. También creo que eso se mencionó en un número anterior en alguna parte, por lo que recomendaría buscarlo en el historial de GitHub y agregar sus pensamientos sobre cómo la API Fields podría beneficiar a Gutenberg.

... no es posible acomodar todos los casos de uso posibles, creo que tal vez un mejor objetivo es crear una buena experiencia para la gran mayoría de usuarios y casos de uso.

Estoy de acuerdo, y 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. Entonces podríamos dejar los ganchos existentes en su lugar y las metacajas 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 al tiempo que reduciría el alcance del proyecto para centrarse en el componente del editor.

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

También estoy totalmente de acuerdo con la propuesta presentada por Yoast. Proporciona una buena etapa intermedia que proporciona a los autores de complementos tiempo para convertir metaboxes en los nuevos bloques. Luego, como parte del plan para el eventual reemplazo de toda la experiencia del editor, WP como proyecto puede decir algo como "En las versiones x, los metaboxes quedarán obsoletos", por lo que tenemos un _plan_ para avanzar hacia un mejor objetivo final.

Solo notando que este concepto rompe los metaboxes existentes, porque no hay una instancia central de TinyMCE con la que comunicarse. En lugar de admitir el 80% de los metaboxes, esto admitirá el 90% (inventé estos números).

Este concepto no resuelve el problema de compatibilidad con versiones anteriores, sino que solo retrasa su resolución para más adelante con el mismo problema. Gutenberg es el primer paso hacia las interfaces JS en WP y no se detendrá con Gutenberg.

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

Cuando pensemos que la visión ideal de Gutenberg está lista para ser lanzada, tendremos tiempo para discutir las estrategias de la 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.

Construyamos el mejor editor posible ahora.

Cuando pensamos que la visión ideal de Gutenberg está lista para ser lanzada, tendremos tiempo para discutir las estrategias de ruta de actualización ...

No podría estar más en desacuerdo con esto. ¿Por qué dedicar miles de horas a desarrollar el editor ideal si no se puede hacer compatible con los sitios existentes? 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.

¿Por qué dedicar miles de horas a desarrollar el editor ideal si no se puede hacer compatible con los sitios existentes?

Para ser claro,

• es imposible ser 100% compatible con los sitios web existentes sin importar la opción que elija para el editor porque los complementos tienen acceso completo al DOM, cualquier cosa que modifique en el dom está rompiendo la compatibilidad con versiones anteriores
• Solo hay una forma de garantizar el 100% de compatibilidad con versiones anteriores para cualquier cambio: no realice el cambio. El complemento que deshabilita a Gutenberg ya está disponible.
• El editor ya es compatible con una gran cantidad de sitios web. Pero como todo lo demás, cuando se rompe, siempre es más visible.

es imposible ser 100% compatible con los sitios web existentes

Ahora que esto está claro, construyamos el editor que creemos que es mejor para el futuro de WordPress, por favor.

¿Todos los metaboxes tienen que funcionar en dispositivos móviles?

Sí, ¿por qué no lo harían?

¿Cuáles son los casos (si los hay) que no se convertirían en bloques?

Para las publicaciones de blog, entiendo por qué Blocks For Everything podría tener sentido, pero esto podría ignorar el caso de uso general de los metadatos: datos que no se ven. Por ejemplo, puedo usar un metabox para exponer la interfaz de usuario para agregar datos analíticos a una publicación.

Para cosas como los tipos de publicaciones personalizadas, que pueden estar compuestas ÚNICAMENTE por metacajas, tengo problemas para entender la nueva interfaz de usuario. Debido a que WordPress carece de una API CRUD completa para datos, muchos desarrolladores usan WP_Query y su conjunto de API relacionadas como un sustituto, y usan metacajas en las pantallas de edición de CPT para aislar la interfaz de usuario para agregar datos específicos o asociaciones. Muchos (la mayoría) de los tipos de publicaciones personalizadas en la naturaleza restan importancia o ignoran el uso tradicional de "contenido"; por lo tanto, para las publicaciones de blog, sí, el contenido está al frente y al centro, pero para muchos casos de uso de CMS, un WYSIWYG no hace mucho sentido.

En esta iteración actual, el soporte de Meta Box es un complemento, cuando en la realidad de muchas personas, los Meta Box SON la interfaz de usuario, la API, el mecanismo que utilizan para componer su CMS. <iframe> s son el gulag.

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

Terminaré con este ejemplo: si una de mis "antiguas" cajas meta activa la interfaz de usuario para que se abra Media, ¿cómo funcionará eso en este "nuevo" escenario, desde dentro de un iframe, sin alguien (un cliente con el que ya no trabajo ) reescribiendo el código?

Como he seguido estas conversaciones, no puedo evitar sentir que los poderes fácticos que se están desarrollando y haciendo las tomas con respecto a Gutenberg no usan ni tratan con los metaboxes en sí. Se siente como una especie de argumento en el que el fin justifica los medios en el que es fácil decirlo porque los medios no se valoran significativamente para empezar.

Por favor, comprenda que para muchos de nosotros tenemos docenas de sitios que se romperían instantáneamente cuando se actualizan a WordPress 5.0, un producto que históricamente ha enseñado a las personas que es seguro actualizar porque es maníaco con la compatibilidad con versiones anteriores. Lo que se está discutiendo aquí no es una interrupción menor (por ejemplo, de estilo), sino un obstáculo potencial que dejaría al lado de administración de miles (o más) de sitios instantáneamente inutilizables. Eso es algo aterrador. Como industria, hemos vendido a la gente la sólida confiabilidad de WordPress.

Como @staylor señaló anteriormente, en la mayoría de nuestros sitios web (sitios corporativos de complejidad media a alta) las metaboxes _son_ la interfaz de usuario. El editor (si se usa) es simplemente una parte de él.

Cuando pensemos que la visión ideal de Gutenberg está lista para ser lanzada, tendremos tiempo para discutir las estrategias de la 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.

Creo que puede ser un error posponer esto demasiado. Especialmente porque muchas organizaciones necesitarán al menos 1-2 trimestres para prepararse.

Hay un adagio que he escuchado de varios desarrolladores principales de WordPress que creo que es importante recordar aquí: cuando alguien adopta WordPress para su sitio, no está adoptando WordPress 3.7 o WordPress 4.8, está adoptando WordPress. Hacer que este camino sea lo más fluido posible es absolutamente necesario. Esto romperá las cosas, y está bien (hay interrupciones de compatibilidad con versiones anteriores de WordPress), pero deben minimizarse, documentarse y comunicarse.

es imposible ser 100% compatible con los sitios web existentes

Si no va a ser compatible, entonces vaya y rompa cosas. Llame a la primera versión WP ++ o WPNG. Es mucho mejor declarar de antemano que es muy probable que las cosas se rompan y dejar que las personas se preparen para ello. El "engaño" actual como si las cosas funcionaran como siempre es malo para todos.

Los iframes son un callejón sin salida en términos de usabilidad. Abrí un widget de selección de fecha basado en jquery en un cuadro meta, y me sorprendió cuando al hacer clic en algún otro lugar aleatorio de la ventana no se cerró. Me tomó un minuto darme cuenta de que el evento de clic estaba en la ventana principal y no se propagó al iframe. Así que me sorprendió, pero al final lo entendí, pero ¿cómo vas a explicar tal cosa a los usuarios? ¿Espera que cada complemento responda a la pregunta de cada usuario sobre expectativas tan triviales de UX?
¿Y cómo espera que funcionen los enlaces externos?

Hay grandes razones por las que la gente usa iframes solo como último recurso.

Mi sugerencia productiva es no declarar el cuadro de meta listo, siempre y cuando su SEO no funcione correctamente en él. Es un poco complejo en términos de interacciones y está instalado en muchos sitios de mierda. Si gutenberg no puede trabajar con él, probablemente nadie lo usará.

Mi sugerencia productiva es no declarar el metabox listo

Como lo señaló @karmatosed anteriormente: "Es bueno pensar un poco que lo que tenemos hoy para metaboxes en Gutenberg es un experimento, en muchos aspectos es un patrón de espera ya que el proyecto determina la dirección a seguir. Al decir que es una eso funciona 'por ahora' pero no es con lo que enviaríamos ".

Para proporcionar algunos datos del mundo real, quiero compartir esta interfaz de un sitio de WordPress en el que he trabajado en el pasado. El campo de contenido es una parte menor de este tipo de publicación personalizada, y aunque algunos de los campos de metabox personalizados se pueden convertir en bloques, la mayoría contiene datos que son utilizados por el administrador, utilizados por un servicio de terceros a través de la API REST, o se usa para agregar metadatos a la entrada. Si bien puede parecer un poco caótico, esta configuración está diseñada específicamente para trabajar con el flujo de trabajo del cliente y utiliza un modelo de contenido estricto basado en una separación clara para garantizar que las versiones futuras del sitio puedan manejar cada tipo de contenido de forma independiente.

Refactorizar este sitio para que funcione dentro de la realidad de Gutenberg llevará mucho tiempo y requerirá recursos sustanciales, por lo que, a menos que los metaboxes se manejen de una manera que coincida estrechamente con lo que ya existe, el propietario de este sitio probablemente volverá a una versión anterior a Gutenberg de WP y se quedará allí por un período de tiempo indefinido.

Como referencia, si bien esto parece extenso, no es ni la configuración de metabox más compleja que he construido ni la configuración más compleja que he visto. Lo que muestra este ejemplo es la solución del mundo real, a través de metaboxes, para satisfacer la necesidad de un modelado y una separación de contenido adecuados más allá del blob de contenido, algo que Gutenberg _debe_ manejar con elegancia y funcionalidad.

Hacer que este camino sea lo más fluido posible es absolutamente necesario.

Convenido

Esto romperá las cosas, y está bien (hay interrupciones de compatibilidad con versiones anteriores de WordPress), pero deben minimizarse, documentarse y comunicarse.

Convenido

es imposible ser 100% compatible con los sitios web existentes sin importar la opción que elija para el editor porque los complementos tienen acceso completo al DOM, cualquier cosa que modifique en el dom está rompiendo la compatibilidad con versiones anteriores

De acuerdo, no creo que nadie esté en desacuerdo contigo aquí. Sin embargo, creo que todavía hay espacio para discutir qué se rompe y cuándo se rompe. Ese tipo de decisiones _también_ influyen en el tipo de trabajo que los desarrolladores tienen que hacer para arreglar lo que está roto. Hay una diferencia significativa entre ajustar las cosas porque los selectores de dom se han modificado y tener que reescribir un modelo de contenido personalizado para que se ajuste al nuevo paradigma de Gutenberg donde los metaboxes solo funcionan de alguna manera :) es bueno apuntar a romper en el lanzamiento inicial de Gutenberg en el núcleo.

Entiendo que todo esto es un experimento, creo que @kevinwhoffman también lo hace. Veo este tema como una _evaluación_ bien pensada de este experimento y debería tomarse como tal. ¿Será suficiente este experimento como solución final? No. Entonces, ¿cuál es el próximo experimento?

Tampoco creo que veremos un gran aumento de desarrolladores que conviertan su trabajo existente a Gutenberg hasta que se establezca una propuesta de fusión, con eso en mente, lo que se rompe en el lanzamiento inicial de Gutenberg _ sí_ importa.

tldr; ¿Esperamos ruptura con Gutenberg? ¡Si! Pero aún deberíamos ser selectivos sobre lo que rompemos y hasta dónde llega esa ruptura en la iteración inicial de Gutenberg fusionada con el núcleo.

Sí, todos hemos estado en torno al desarrollo de WordPress lo suficiente como para esperar que algunas cosas se rompan de una versión a la siguiente. Y de alguna manera ese es exactamente mi punto. Siempre que presentemos Gutenberg como una actualización más de WordPress, entonces no debería romper nada más o menos que cualquier otra actualización. Si rompemos esa confianza, no importará lo bueno que sea el editor al final del día.

Aquí hay una captura de pantalla actual de un complemento que he estado desarrollando durante los últimos meses. En esta situación, un editor visual no tiene ningún valor, y tratar de calzar el tipo de interfaz necesaria en una interfaz diseñada para la edición visual de contenido no tiene sentido.

De hecho, estoy considerando seriamente si debería molestarme en continuar desarrollando esto para WordPress, dado que todo mi trabajo puede deshacerse con la próxima versión.

Como puede ver, necesito acceder al cargador de medios en mis metacampos, y relegar la mayor parte de la página a un iframe haría que esta interfaz fuera extremadamente torpe.

Hay millones de interfaces como esta en complementos, herramientas y sitios personalizados, creados en WordPress. Tratar a estos usuarios como ciudadanos de segunda, a favor del "nuevo calor" de los bloques es inaceptable. Los metaboxes deben conservar su nivel actual de integración y prominencia en la página de edición.

Apoyo mucho la opinión de Yoast sobre Gutenberg. No me queda claro cómo "actualizar el editor visual" fue reinterpretado para ser "reemplazar toda la interfaz de edición posterior" por el equipo de Gutenberg, 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 cambiarí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 que se apruebe una fusión a principios de año.

@aaronjorbin bueno, parece que hay un problema de comunicación aquí, ya que en https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ se dijo explícitamente

Esta versión incluye soporte de meta-cajas largamente esperado (¡necesita pruebas!),

no es una "idea", no es un "experimento", es simplemente algo que, como todo software, puede incluir errores. No lo habría probado si se llamara "un experimento" en esa publicación.

Volviendo al tema, veo que el principal problema aquí es el intento de evitar declarar una rotura. Desde mi limitada comprensión de los JS framewoks, es muy difícil estar "medio embarazada" con ellos, y una vez que hayas decidido que el control de tu pantalla principal se realiza con ellos, todo debe hacerse con ellos, por lo tanto, la única forma de avanzar es hacer ciudadanos de primera clase de metacajas en la pantalla de edición de gutenberg.
Dado que es poco probable que los complementos "heredados" se adapten, esto significa que gutenberg debe ser una opción de suscripción explícita para los sitios existentes. Odio la idea de una bifurcación de UX, pero al menos de esta manera habrá un camino a seguir que funcionará, y si se declara ahora, la gente podrá prepararse.

Después de leer la discusión y pensar en los proyectos que construyo con WordPress, y las cosas que veo que la gente hace con WordPress, llegué a la conclusión de que Gutenberg debería optar por los tipos de publicaciones personalizadas. Esto permitirá que los sitios web actuales que usan CPT para datos estructurados continúen funcionando y que se creen nuevos sitios web donde se usa WordPress como un CMS. Solo quiero recordarle que al registrar un tipo de publicación, podemos declarar explícitamente el soporte para el campo editor junto con otras características. Entonces, ¿por qué no agregar un apoyo explícito para Gutenberg allí? Por supuesto, esto no solucionará el problema con los metaboxes agregados a publicaciones y páginas, pero permitirá que WordPress se use como un CMS en el futuro.

Puede agregar un nuevo problema con esos iframes. Cuando la sesión de usuario se apaga, la pantalla de inicio de sesión de WP se muestra sobre Gutenberg y dentro del iframe dos veces.

Solo para que los desarrolladores lo sepan.

Más sigo todo esto más estoy convencido de que la única forma posible sería como lo hizo Microsoft.

Windows XP = WordPress sin Gutenberg
Windows 10 = Wordpress con Gutenberg.

Esos 2 no se pueden mezclar y actualizar con paquetes de otro.

Joomla y Drupal lo hicieron. Por qué no. No es algo que prefiera en absoluto, sino lo alternativo.

Después de leer la discusión y pensar en los proyectos que construyo con WordPress, y las cosas que veo que la gente hace con WordPress, llegué a la conclusión de que Gutenberg debería optar por los tipos de publicaciones personalizadas.

Una administración dividida sería uno de los peores resultados que puede obtener Gutenberg. He descrito las razones por las que en https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490.

Esta discusión se está volviendo realmente kafkiana. Parece que no importa cuántas personas propongan arreglos pragmáticos para los puntos débiles actuales, hay algunas personas clave que parecen completamente inmunes a las críticas. Desafortunadamente, estas personas son las que tienen la última palabra, porque hasta ahora la discusión ha demostrado que algunas personas clave pueden atropellar a cientos de desarrolladores preocupados. Me preocupa todo el daño que esto le está haciendo al ecosistema de WordPress. Haz que Gutenberg sea el editor, no la pantalla de edición. No rompa WordPress.

Kevin Hoffman:

Estoy totalmente de acuerdo con este concepto presentado por Yoast, que me parece que mantendría gran parte del trabajo ya realizado al tiempo que reduciría el alcance del proyecto para centrarse en el componente del editor. Fuente: https://yoast.com/gutenberg-alternative-approach/

Creo que el camino a seguir propuesto por Yoast sería una gran mejora para WordPress Core. Un nuevo editor para crear contenido, que muchos usuarios adoptarían como una mejora con respecto al actual. Un paso más pequeño para WordPress, pero una gran mejora para el usuario.

Este es un tema acalorado. Admito que a veces nosotros (al menos yo) podemos ser desdeñosos en mis comentarios y me disculpo por ello. Estamos recibiendo muchos comentarios, buenos, malos, objetivos, inútiles y, a veces, es difícil distinguirlos. Somos humanos. Trate de estar en el otro lado de la ecuación, sea el que construya esta cosa y reciba todos estos comentarios. Puede sentirse cerca de los "ataques personales", los cerebros tienden a reaccionar con desdén, no deberíamos.

Las personas que comentan y leen publicaciones de blogs a menudo piensan que estamos descubriendo los problemas de las metacajas y todo lo relacionado. No eran. Estamos trabajando en Gutenberg desde hace un año. Tal vez acaba de descubrir / probar Gutenberg, pero nosotros no, trabajamos en él durante el tiempo suficiente para estar cómodos con la mayoría de los problemas de compatibilidad con versiones anteriores y tenemos respuestas para la mayoría de ellos.

Por favor, tenga la mente abierta y comencemos respondiendo algunas preguntas:

¿Cuál es el objetivo de Gutenberg?

No es, y nunca lo fue, el objetivo principal de Gutenberg es allanar el camino hacia el futuro de WordPress Core. Técnicamente, aprovechando la API REST, la interfaz de usuario del lado del cliente y unificando los conceptos básicos: widgets, códigos cortos, bloques, metaboxes de contenido bajo un concepto único "Un bloque" y con experiencia al responder estas preguntas: ¿Cómo se pueden simplificar la creación de sitios web (piense en las personalizaciones)? y publicación de contenido (piensa en editor) en WordPress.

¿Cuál es el objetivo del editor Gutenberg?

A diferencia de lo que lee aquí y allá, el enfoque siempre ha sido rediseñar toda la página. La primera maqueta de la página del editor de Gutenberg se mostró en la segunda o tercera reunión semanal de Gutenberg. Todavía estábamos en la fase de creación de prototipos. Meses antes del primer alfa. El diseño estaba cerca de lo que tenemos ahora.

¿Qué pasa con las Metaboxes, son importantes para WordPress?

Son. Al igual que los códigos cortos, los botones personalizados TinyMCE, se usan y abusan mucho para extender la página del editor de WordPress.

¿Cuál es la diferencia entre códigos cortos, botones TinyMCE y Metaboxes?

La principal diferencia es que los "Metaboxes" no tienen "propósito", es solo una forma de extender la página del editor sin consistencia, mientras que los códigos cortos y los botones TinyMCE tienen uno.

Los códigos cortos son una cadena que se convierte en contenido en la fase de renderizado, los botones TinyMCE son botones personalizados que se agregan a la barra de herramientas TinyMCE y usan la API TinyMCE para comunicarse con el contenido del editor. ¿Metaboxes? No lo sé, pueden ser cualquier cosa, solo agregas un montón de HTML, Javascript y PHP para extender la página del editor y cómo se comporta al guardar.

¿Es esta falta de "propósito" un problema o una ventaja?

¡Bien! Puede verse como un "profesional", porque un complemento puede hacer lo que quiera con el editor, incluidas cosas como:

• Reemplazo de cualquier botón, área de texto, entrada, div, cualquier cosa. Acceso completo al DOM
• Usando cualquier variable javascript global, incluida la instancia global de TinyMCE

¡Derecho flexible! Pero, ¿qué pasa con las actualizaciones de WordPress? Cualquier actualización de la pantalla del editor. Cualquier actualización de TinyMCE, cualquier cambio de clase, cualquier div , cualquier botón eliminado / movido, cualquier cambio está rompiendo la compatibilidad con los complementos porque, como desarrollador principal de WordPress, no sabe para qué están usando los complementos Metaboxes.

¿Podemos concluir que para el largo plazo de WordPress, los Metaboxes están bloqueando su evolución (independientemente de Gutenberg)?

Sí lo son. Y la historia de Internet demostró tantas veces que una tecnología que no evoluciona muere. (por favor no reaccione con 👎 Si no le gusta esta respuesta, es un hecho y no una opinión)

Bien, pero entonces, ¿cómo podemos hacer avanzar WordPress si estamos atrapados con Metaboxes?

Esa es una buena pregunta y antes de responder, debemos comprender el uso actual de Metaboxes en los complementos de WordPress.

¿Para qué usan los complementos actuales Metaboxes?

Yo diría que hay dos categorías de complementos de "Metaboxes":

• Metaboxes como contenido (a menudo almacenados en post meta, pero no siempre)
• Metaboxes como mejora de la experiencia del editor (SEO, corrector ortográfico,…)

Ok, sabiendo esto, ¿cómo podemos avanzar?

Necesitamos tres cosas:

• Proporcione una forma de crear o actualizar estos complementos mientras se envía Gutenberg (o cualquier actualización de WordPress).
• Proporcione las mejores rutas de actualización posibles para las personas que utilizan estos complementos. Esto incluye: ver si estos complementos aún pueden funcionar con las evoluciones que se avecinan y cómo minimizar la rotura.

Ok, pero ¿no dijiste que cualquier cambio en la página del editor romperá los complementos (incluido el reemplazo solo del área de contenido)?

¡Correcto! Entonces, si nuestro deseo es no romper ningún complemento, nos queda una opción única. Proporcionar una forma de permanecer en la página de edición actual sin cambios. Para eso es exactamente el complemento que deshabilita a Gutenberg.

Personalmente, no llamaría a esto una buena ruta de actualización, ni siquiera es una actualización, ¿algo mejor?

Esta ruta de actualización (deshabilitar Gutenberg) es una necesidad, pero sí, podemos hacerlo mejor. Si echa un vistazo a los complementos que usan Metaboxes, el 90% de ellos no tienen ninguna interacción con el área de contenido, por lo tanto, si reemplazamos solo el área de contenido (enfoque más reciente), estaremos rompiendo solo el 10% de los complementos.

Entonces, la única forma sin que se rompa es deshabilitar a Gutenberg.

La experiencia de usuario óptima de Gutenberg consiste en reemplazar los complementos de metaboxes con complementos que brindan la misma funcionalidad con las nuevas API de extensibilidad de Gutenberg.

Dicho esto, notamos que la mayoría de los complementos que usan Metaboxes los están usando como contenido que se guarda para publicar meta y podemos hacer que funcionen en la pantalla de Gutenberg para disfrutar de toda la experiencia mientras los autores de complementos actualizan sus complementos.

¿Es esta la solución de iframe de la que todo el mundo habla?

Sí lo es. Mostramos los meta boxes en iframes lo cual tiene sus inconvenientes (enlace, modales, recarga de assets) pero al mismo tiempo permite que el 80% de los plugins funcionen mientras disfrutas de toda la Experiencia Gutenberg. Esta solución acaba de aterrizar y todavía estamos experimentando con ella. Lo que es seguro es que no hay forma de hacer que todos los metaboxes funcionen y realizar cambios en el editor.

Ya veo, ¿puede recapitular las posibilidades de actualización, por favor?

Por supuesto.

1- Deshabilitar Gutenberg: no rompa el 100% de los complementos
2- Gutenberg reemplaza solo el área de contenido: el 90% de los complementos funcionan, la UX sufre
3- Gutenberg reemplaza toda la pantalla: el 80% de los complementos funcionan, la UX es mejor
4- Gutenberg con complementos compatibles: la mejor experiencia de usuario posible

entonces ¿que debemos hacer?

Nuestro objetivo es construir la cuarta opción porque es la mejor opción para el futuro de WordPress. Nuestro objetivo también es construir Gutenberg de manera que podamos reutilizar sus piezas para lograr la segunda y tercera opción si es necesario.

¿Cómo puedo optar por una opción en lugar de otra?

Esto aún no se ha decidido. Tener un complemento para elegir qué ruta de actualización desea es una posibilidad. La degradación automática mediante la detección de algunos Metaboxes es una opción ...

Esa es mi opinión para explicar el razonamiento detrás de estos problemas, por favor, si desea responder con palabras como "ridículo", "mal administrado", "implementación deficiente" ... mi paciencia como un simple desarrollador que pasó todo el año pensando en La mejor forma posible de avanzar para WordPress en su conjunto (núcleo y comunidad) está cerca de su límite. Personalmente, es posible que no responda más sobre este tema, pero estoy escuchando los comentarios y adaptaré mi razonamiento si los comentarios me convencen.

Todos estamos en el mismo barco, queremos lo mejor para WordPress.

Explicaciones muy completas, Riad. Gracias por tomarse el tiempo para escribirlos. Déjame ayudarte a mantenerte alejado de ese límite con una 💪 y una 🤗. Espero eso ayude.

Con respecto a los metaboxes, estaría encantado de tener una API de Fields en el núcleo. Reescribiría nuestros complementos solo para deshacerse de todo el lío que las soluciones de metaboxes personalizadas tienden a acumular después de un tiempo.

Ahora, para las personas que tienen configuraciones complejas de metaboxes, la API Fields es su salvación siempre que las hayan construido sobre un marco como ACF o CMB. Los desarrolladores de esos marcos solo necesitan cambiar a la nueva API y todo está bien. No es una tarea fácil, pero es buena para todos. Ahora, para aquellos con cosas "codificadas de forma rígida", ahora es el mejor momento para reorganizar las cosas de una manera más limpia y preparada para el futuro. Estás en mejor forma, Gutenberg o no.

Somos humanos. Trate de estar en el otro lado de la ecuación, sea el que construya esta cosa y reciba todos estos comentarios. Puede sentirse cerca de los "ataques personales", los cerebros tienden a reaccionar con desdén, no deberíamos.

Hay humanos trabajando muy duro en Gutenberg. Hay humanos cuyos medios de vida (sus temas y complementos) se verán afectados por Gutenberg. Y hay humanos que usan los temas y complementos afectados por Gutenberg para hacer su propio trabajo. Todos nos cuidamos unos a otros y queremos lo mejor para WordPress al final del día. Aunque podemos estar en desacuerdo apasionadamente sobre lo que significa "mejor".

A diferencia de lo que lee aquí y allá, el enfoque siempre ha sido rediseñar toda la página. La primera maqueta de la página del editor de Gutenberg se mostró en la segunda o tercera reunión semanal de Gutenberg ...

Las maquetas por sí solas no indicaron que el código base de toda la página de edición se volvería a escribir en React. Al mirar una maqueta, nadie podría haber sabido que se eliminarían los ganchos críticos o que se romperían las metacajas. Sin embargo, cuando me resultó obvio que la adquisición de página completa plantearía un problema para las metacajas, expresé esa preocupación el 15 de junio , el día antes de que 0.1.0 fuera marcado para su lanzamiento. Cuatro meses y 15 lanzamientos más tarde fue la primera vez que vimos aparecer metacajas en la interfaz, dentro de iframes.

Creé este problema en base a mi experiencia siguiendo de cerca y probando a Gutenberg desde sus etapas pre-alfa. Este es solo el último problema relacionado con los desafíos en curso de metabox, pero lo que es más importante, es el primero basado en pruebas concretas de una implementación de metabox de Gutenberg.

La principal diferencia es que los "Metaboxes" no tienen "propósito", es solo una forma de extender la página del editor sin consistencia, mientras que los códigos cortos y los botones TinyMCE tienen uno.

Esto nuevamente indica un malentendido fundamental de cómo los desarrolladores de complementos y temas utilizan las metacajas. Esperamos que los códigos cortos y los botones TinyMCE necesiten adaptarse porque en realidad se usan dentro del editor de contenido. Las metacajas no lo son.

Sugerir que las metacajas (los bloques de construcción fundamentales del desarrollo personalizado de WordPress) no tienen ningún propósito nuevamente le dice a la comunidad que Gutenberg está priorizando la experiencia central de una "instalación nueva" a expensas de los desarrolladores de complementos y temas.

Cualquier actualización de la pantalla del editor. Cualquier actualización de TinyMCE, cualquier cambio de clase, cualquier div nuevo, cualquier botón eliminado / movido, cualquier cambio está rompiendo la compatibilidad con los complementos porque, como desarrollador de Core WordPress, no sabe para qué están usando los complementos Metaboxes.

Es posible que no sepamos el propósito de un metabox, pero conocemos los requisitos fundamentales para registrar un metabox y los ganchos que utilizan. Sabemos que ninguno de ellos fue desarrollado para funcionar dentro de iframes. Durante años hemos entendido cómo ampliar y mejorar WordPress sin romperlos. Nuevamente, si 5.0 es solo otra versión de WordPress, entonces la cantidad de roturas no debería ser diferente de cualquier otra versión.

Mostramos los meta boxes en iframes lo cual tiene sus inconvenientes (enlace, modales, recarga de assets) pero al mismo tiempo permite que el 80% de los plugins funcionen mientras disfrutas de toda la Experiencia Gutenberg.

Si tiene alguna evidencia de estas cifras del 80% / 90% a las que se hace referencia constantemente, compártala. De lo contrario, no utilice estadísticas hipotéticas cuando le pida a la comunidad que tome una decisión de esta magnitud.

Deténgase y reevalúe ahora, no más tarde

Después de toda esta discusión y lo que pensé que era una prueba de que los iframes no son una solución viable a largo plazo, me encontré con https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059 que busca agregar un tercio iframe a Gutenberg.

Ya es hora de dejar de buscar el editor ideal como si las limitaciones no existieran y comenzar a considerar un enfoque que no rompa WordPress.

Hablando como un desarrollador que ha estado observando y discutiendo sobre el editor de Gutenberg desde el día 1, lamento decir que el argumento de Riad tiene algunos grandes agujeros.

En primer lugar, la gente ha estado sacando a relucir el tema de los metaboxes desde el primer día, junto con varios otros problemas que aún están en el aire. en la fase de Mockup nos dijeron que "todo es un mejor caso visual, abordaremos los metaboxes más tarde". Luego, en la fase de prototipo fue "Todo esto es código de prueba de concepto, los metaboxes se tratarán más adelante". Luego, cuando se lanzó la primera iteración del complemento de funciones (que fue, como una gran sorpresa para nadie, no fue una reescritura desde cero después de todo, y solo un reempaquetado del código actual de prueba de concepto), el argumento de repente se convirtió en "Las interfaces heredadas como las metaboxes tendrán algún soporte por ahora". Luego, cuando el clamor público se volvió ensordecedor, fue "nos equivocamos, los metaboxes no son un legado". Pero ahora, este argumento está impulsando nuevamente la agenda del "legado".

Los metaboxes no son código heredado, porque actualmente no hay un reemplazo viable.

En los metaboxes, puedo agregar trivialmente un editor anidado con todas las funciones usando wp_editor . Gutenberg actualmente no tiene una interfaz de usuario para bloques anidados, y no está programado para la versión 5.0, por lo que no puede hacer el equivalente sin una gran cantidad de código de interfaz de usuario personalizado.

Ese es un solo ejemplo, pero degradar la experiencia de los metaboxes no es una solución aceptable, hasta que Gutenberg esté más allá de la paridad. Eso no sucederá con WP 5.0

Aquí hay una hoja de ruta para el plan de "administración unificada" para Gutenberg que realmente funcionaría:

• limite la versión inicial al área actualmente poblada por wp_editor, pero proporcione la IU de bloque completa dentro de ese espacio
• promover y expandir la flexibilidad y las capacidades que permite la interfaz de usuario del bloque, mediante el envío de una API de campos que hace que sea trivial diseñar en ese espacio
• a medida que crece la popularidad, reemplace otras partes de la interfaz de usuario con instancias de Gutenberg en espacio aislado similares. Los menús, los widgets, el personalizador y la biblioteca multimedia son interfaces que están relativamente estancadas para los desarrolladores y podrían beneficiarse de una estructura de interfaz de usuario común.
• A medida que la interfaz de usuario común se vuelve más flexible y poderosa, las personas optarán por usarla en lugar de las metaboxes, porque ofrece un conjunto común de herramientas y más opciones.
• fusionar gradualmente los agujeros entre las instancias aisladas de Gutenberg, a medida que el desarrollo en esos espacios se estanca.

De esa manera, los desarrolladores pueden comenzar a utilizar Gutenberg en herramientas de producción sin perder las capacidades actuales que tienen. Gutenberg se beneficiará de todos los casos de uso de vanguardia que se desarrollan para estos desarrolladores, creando una solución flexible que realmente satisfará las necesidades de quienes actualmente usan metaboxes.

Para cuando las metaboxes estén obsoletas, los autores de complementos habrán tenido tiempo suficiente para aprender y utilizar los beneficios de Gutenberg en la naturaleza, y será la elección obvia.

Gutenberg es como un concept car. Escale ahora y envíe una mejora iterativa al editor (no a la página del editor). Luego, durante el próximo año o dos, puede llevar el proyecto hacia una cobertura administrativa del 100%.

Solo quiero saltar desde la perspectiva de un proveedor de servicios al cliente que ha hecho referencia al compromiso vocal de WordPress con la compatibilidad con versiones anteriores para aliviar las preocupaciones de los clientes sobre las actualizaciones que rompen sus sitios web. Con eso, reconozco que mi uso de WordPress probablemente haya sesgado / sesgado mi percepción de la pantalla de edición.

Hasta la fecha, parece que este problema ha sido rechazado / descartado / minimizado cuando, en mi mundo, las metacajas han sido un _mayor_ punto de venta para WordPress desde que los tipos de publicaciones personalizadas se hicieron fácilmente disponibles para su uso generalizado. Me alegro de que esta discusión esté sucediendo.

Gutenberg es un proyecto impresionante, sí, pero los clientes con los que he trabajado están muy contentos con las soluciones basadas en metabox que se les han proporcionado. Tener una opción para deshabilitar Gutenberg es bueno, pero me preocupa que se cancele a través del complemento. A pesar de mis mejores esfuerzos para entrenar a los clientes, no creo que estén dispuestos a instalar un nuevo complemento por sí mismos, ni sabrían qué es Gutenberg incluso si aparece abiertamente en una pantalla de bienvenida de actualización.

Es posible (quizás incluso probable) que los complementos de metabox que he usado en los sitios de los clientes puedan actualizarse para ser "compatibles con Gutenberg", pero incluso entonces todo el flujo de trabajo cambiará para esos clientes de la noche a la mañana. Parece que a muchos de esos clientes les está preguntando cuándo su flujo de trabajo existente les ha ido bien desde que se entregó su sitio hace mucho tiempo.

Respaldo plenamente el objetivo de Gutenberg de mejorar la experiencia del usuario, pero en mi opinión no podemos evitar el precedente que se ha establecido (intencionalmente o no) para usar metacajas para la edición de contenido. Creo que el enfoque de Yoast es excelente, es algo que marca varias casillas de verificación para una amplia variedad de posibles soluciones a este problema.

Solo mis dos centavos, deseando observar el resultado aquí.

La cantidad de complementos que funcionan con Gutenberg puede ser del 80%, 90% o 0% como en nuestras pruebas, lo que se debe evitar es que miles y miles de propietarios de sitios tengan que averiguar por sí mismos si su configuración probablemente funcionará o no. con Gutenberg. Eso sería una enorme pérdida de tiempo (= dinero), causaría mucha confusión y mataría mucha confianza.

Me gustaría ver complementos / temas marcados como compatibles / no compatibles con Gutenberg (o 'no relevantes'), para que los propietarios de sitios puedan estar informados sobre posibles problemas antes de que eso se active en sus sitios y puedan actuar en consecuencia. Los datos no solo podrían provenir de los propietarios de complementos, sino también de las pruebas de la comunidad durante el tiempo de prueba beta (la versión beta real ..., y ese período de tiempo debería ser largo, no solo unas pocas semanas) y más.

Soy consciente de que esto nunca será completo o 100% exacto, pero debería ser factible para los complementos más destacados.

PD.
Para mis propios proyectos (una plataforma de micrositios de intranet para un cliente> 30.000 empleados y un montón de sitios de pequeñas empresas / sin fines de lucro) decidimos desactivar Gutenberg hasta que haya pasado al menos un año con éxito en la naturaleza.

De todos modos, los porcentajes no cuentan toda la historia. Cualquier discusión sobre el impacto de Gutenberg debe considerar cuántos sitios web se ven afectados por su implementación de metabox, en lugar de cuántos complementos se ven afectados. Gutenberg podría afectar solo a un puñado de complementos y aún afectar a millones de usuarios, ya que algunos de los complementos más utilizados dependen de metaboxes y campos personalizados; ACF y Yoast SEO son dos ejemplos obvios.

He estado siguiendo el desarrollo de Gutenberg desde lejos durante muchos meses y _sé_ que el tema de las metaboxes ha existido durante mucho tiempo. Apoyo la filosofía detrás de Gutenberg y creo que eventualmente Gutenberg se convertirá en una parte muy poderosa del núcleo de WordPress que permitirá que WordPress sea una pieza de software viable y competitiva durante muchos años en el futuro. Estoy TAN a bordo con todo el concepto de Gutenberg y su objetivo.

Lo que no entiendo es el deseo de pasar de 0 a 100 de una vez. ¿Por qué una versión iterativa no es el camino que se está tomando aquí? ¿Por qué las dos opciones son "no romper nada" o "romper todo"?

Los metaboxes son la razón por la que WordPress es tan poderoso como lo es. Su propósito es ampliar la pantalla de edición.

Creo que es genial que Gutenberg quiera revisar toda la pantalla, pero no creo que sea realista hacerlo de una vez, especialmente si significa tratar uno de los componentes más importantes de WordPress (en cuanto al desarrollo personalizado ... que es una gran parte del éxito de WordPress) como un aparte.

2- Gutenberg reemplaza solo el área de contenido: el 90% de los complementos funcionan, la UX sufre

La UX no sufre. Los usuarios lo verán como la sección del editor que se está renovando. Les dará una nueva forma de crear contenido, una forma que la mayoría de ellos encontrará empoderadora después de adaptarse, y no romperá ningún flujo de trabajo existente que tengan ni los dejará preguntándose cómo lograr las cosas que solían lograr en el editor.

4- Gutenberg con complementos compatibles: la mejor experiencia de usuario posible

Este es un objetivo excelente, pero es el objetivo a largo plazo. Eventualmente sí, absolutamente, debería ser Gutenberg con complementos que funcionen junto o dentro de la experiencia de Guteneberg.

Nuestro objetivo también es construir Gutenberg de manera que podamos reutilizar sus piezas para lograr la segunda y tercera opción si es necesario.

No estoy seguro de lo que esto significa. ¿Quieres construir Gutenberg asumiendo que todos los complementos simplemente funcionan con él y usar esa solución para volver a las opciones 2 y 3? Construyendo primero hacia 2 y luego iterando hacia 3, ¿no es eso lo que nos llevará a 4?

Me gusta la hoja de ruta propuesta por @gschoppe , como desarrollador que crea sitios web personalizados de WordPress, este es un enfoque que puedo respaldar, uno que no afectará negativamente a los desarrolladores o sus clientes o usuarios normales de WordPress, y aún así nos llevará al final. gol de Gutenberg, aunque a un ritmo que es más fácil de tragar.

Junto con las preocupaciones de Kevin sobre los iframes, me gustaría señalar algunas preocupaciones de accesibilidad. Primero, mientras que los usuarios que experimentan un sitio visualmente experimentarán los conjuntos de marcos e iframes como un todo cohesivo junto con el resto de la página, los usuarios de lectores de pantalla no. Los usuarios de lectores de pantalla experimentan cada marco dentro de un conjunto de marcos y cada iframe, como una parte distinta, separada del resto de la página, porque las páginas web se experimentan de manera lineal. Algunos lectores de pantalla (en particular, Jaws para Windows, que es el que tiene la mayor participación de mercado según la encuesta anual de uso de lectores de pantalla de WEBAIM), tienen un ajuste de configuración para ignorar los marcos, incluidos los en línea, porque pueden ser muy molestos para algunas pantallas usuarios lectores. Cuando se invoca la configuración de ignorar marcos, el contenido dentro de marcos e iframes desaparece. Incluso si Gutenberg sigue todas las mejores prácticas de accesibilidad cuando se trata de iframes, pedir a los usuarios que deshabiliten esta configuración para poder editar completamente el contenido también los expone a todas las instancias de iframe y las peores prácticas en la red. La única otra alternativa para estos usuarios es pedirles que creen un perfil separado solo para usar Gutenberg, lo cual no es un proceso simple, porque significa que necesitan configurar cada configuración del navegador y configuración de voz de nuevo. También significa que deben mantenerse al día con al menos dos perfiles de navegador separados. Seré la primera persona en decirle a los usuarios de Jaws para Windows que migren a NVDA a tiempo completo por razones. Gutenberg usando iframes para el soporte de metabox no es una de esas razones.

.. mi paciencia como un simple desarrollador que pasó todo el año pensando en la mejor manera de avanzar para WordPress en su conjunto (núcleo y comunidad) está cerca de su límite.

Te juro que odio ser grosero, pero es posible que tengas que ponerte la piel más gruesa en ese caso. Está frustrado por las respuestas de cara a un "año entero" que ha pasado pensando en esto, y gracias por hacerlo, pero estas son decisiones que van a impactar varios años de trabajo que otros han hecho.

En mi caso, por lo que estoy leyendo, casi todos los sitios web que he construido durante los últimos 3 años pueden romperse instantáneamente. Ya no soy responsable de estos sitios, pero ¿qué pasará en la agencia donde solía trabajar cuando decenas de clientes llamen a la vez con sitios dañados? ¿Cómo afectará eso a esa pequeña agencia, su trabajo diario, sus resultados finales? ¿Cómo afectará a sus clientes? Esas son mis preocupaciones y soy solo un pequeño desarrollador (en sentido figurado) en este ecosistema relativamente grande.

Admito que a veces nosotros (al menos yo) podemos ser desdeñosos en mis comentarios y me disculpo por ello.

La gente está preocupada y frustrada y me parece que tienen todo el derecho a hacerlo porque la percepción es que el equipo que trabaja en Gutenberg tiene poca comprensión de cómo se están usando las metacajas, poca preocupación por cuál será el impacto, y va a seguir adelante con su visión pase lo que pase.

Me entristece escribir esto, pero ni en un millón de años sugeriría que nadie comience un proyecto importante con WordPress en este momento.

2- Gutenberg reemplaza solo el área de contenido: el 90% de los complementos funcionan, la UX sufre

@youknowriad , ¿cómo puede decirse que la UX no sufre con Gutenberg versus TinyMCE? Realmente estoy haciendo esa pregunta, no sarcásticamente. Puedo decirles que la UX de hecho sufre mucho en Gutenberg en comparación con TinyMCE y meta boxes. Te animo a que descubras esto por ti mismo:

(1) Desenchufe su mouse.
(2) Si está en un Mack, presione el comando + f5 e intente hacer algo productivo con VoiceOver.
(3) Si está en una PC, descargue NVDA, instálelo, desconecte el mouse y realice la misma prueba. Intente hacer algo productivo con Gutenberg en esas circunstancias.

Creo que encontrarás que la UX es una pesadilla absoluta en este momento. Eso no quiere decir que no pueda cambiar para mejor. Gutenberg brinda una oportunidad para que WordPress elimine una gran cantidad de deudas técnicas con respecto a la accesibilidad, y si esto se hace con cuidado y correctamente, entonces se pueden obtener grandes logros. Pero si esto se hace de manera incorrecta o descuidada, gran parte del trabajo que el Equipo de Accesibilidad de WordPress y otros colaboradores principales han hecho desde 2012 deberá comenzar de nuevo. Me gustaría ver que WordPress como un proyecto no cometa el mismo error con el que comenzó: no considerar la accesibilidad web desde el principio, lo que significa que el equipo de accesibilidad y otros colaboradores preocupados se han encontrado a sí mismos apostando por la accesibilidad después del hecho, que es una tarea que nunca puede ponerse al día, ya que WordPress no es una base de código estancada.

Entiendo que ustedes han estado trabajando en Gutenberg durante un año. También entiendo que trabajar en esto es difícil en sí mismo, y que los comentarios negativos no ayudan en esa situación. Finalmente, entiendo que puede parecer que aquellos de nosotros que somos tan críticos como nosotros podemos parecer que estamos llamando feo a su bebé, o simplemente reaccionando al miedo al cambio, y como creador, eso es frustrante en el mejor de los casos y doloroso en el peor. . Pero hablando por mí, el bebé no es feo. Tiene un gran potencial no realizado para ser el niño más genial de la cuadra o el pequeño idiota que hace que la vida de todos sea miserable. Me gustaría que fuera lo primero y no lo segundo. Con respecto a los metaboxes específicamente, son un elemento básico literal del desarrollo personalizado de WordPress, probablemente más que los códigos cortos o los botones TinyMCE. No deben cepillarse a la ligera ni introducirse en un iframe hasta que sepamos cómo deshacernos de ellos.

Mi simple historia con WordPress es que ha sido el motor de mi sitio web preferido para crear sitios web para clientes individuales, pequeñas y empresariales durante más de una década. En ese tiempo, ha habido tres cosas que han hecho de WordPress la herramienta de elección:

1. Fuente abierta. Creo que esta audiencia puede estar de acuerdo en lo poderoso y ventajoso que es esto.
2. Facilidad de uso. WordPress hizo que fuera increíblemente fácil para los no desarrolladores crear y actualizar contenido. Esto fue muy importante en mis primeros años de creación de sitios web para particulares y empresas.
3. Definición de contenido. Tipos de publicaciones personalizadas, taxonomías personalizadas y metacajas personalizadas. Cuando todo lo que condujo a estos alcanzó una singularidad, no creo que esté alcanzando cuando digo que esto es cuando WordPress era "vendible" a la comunidad empresarial como algo más que un simple software de blogs. (WordCamp Phoenix 2012 - CMB. Excelente escritura de Justin Tadlock sobre la definición de tipos de publicaciones, taxonomías y metacajas).

Me atrevería a decir metaboxes personalizados: esta capacidad para crear interfaces de administración personalizadas, creando una gran experiencia de usuario para las personas, es enorme. Rompe eso y estás rompiendo WordPress .

La idea detrás de Gutenberg, hacer que la experiencia del editor de contenido sea más poderosa, es una gran idea. Vale la pena hacerlo, pero debe hacerse bien, con cuidado y sin apresurarse. En este momento, se siente muy apresurado y nada listo.

@jchristopher lo dice muy bien:

Respaldo plenamente el objetivo de Gutenberg de mejorar la experiencia del usuario, pero en mi opinión no podemos evitar el precedente que se ha establecido (intencionalmente o no) para usar metacajas para la edición de contenido. Creo que el enfoque de Yoast es excelente, es algo que marca varias casillas de verificación para una amplia variedad de posibles soluciones a este problema.

@jnicol y @aurooba hacen grandes puntos y hacen buenas preguntas. ¿Por qué parece que es todo o nada en lugar de una hoja de ruta iterativa? La alternativa de Yoast es mucho más sensata de lo que se ha visto y creo que el “experimento iframe” prueba ese punto. Gracias, @amandarush , por señalar los problemas de accesibilidad. Desafío a todos a que intenten trabajar con Gutenberg de la manera que ella describió. Podría cambiar algunas perspectivas.

@aaronjorbin lo dijo antes, cuando alguien adopta WordPress, no está adoptando WordPress (versión-número-aquí), está adoptando WordPress como un todo.

Hay otra versión de eso, que cualquiera en el servicio al cliente probablemente escucha a menudo. Cuando alguien viene a usted y le dice que necesita un nuevo sitio web (no estamos hablando de blogs), generalmente no dice, "Necesito un nuevo sitio web de Wordpress", o "Quiero un nuevo sitio de Drupal", etc. Solo quieren un sitio nuevo, uno que funcione y funcione bien.

WordPress ha sido la mejor solución para millones de sitios web: la facilidad de uso y el código abierto son la clave. Romper las cajas meta personalizadas (olvídese de los números de los complementos, ¿qué hay de todos los sitios web existentes con IU de administración personalizadas?) Con una implementación apresurada de una nueva interfaz de editor daña esa facilidad de uso.

mi paciencia como simple desarrollador que pasó todo el año pensando en la mejor manera de avanzar para WordPress en su conjunto (núcleo y comunidad) está cerca de su límite.

Voy a ser franco, aquí:

Este y un par de comentarios como este me hacen pensar que algunos de ustedes deberían alejarse de los roles de toma de decisiones en este proyecto. Si no puede recibir comentarios honestos, bien pensados, pero críticos sobre un producto, entonces, francamente, no debería estar en un rol de toma de decisiones en un equipo de producto. He estado en su lugar varias veces, generalmente en reuniones cara a cara y, en los casos exitosos, todos en la sala se dieron cuenta de que, sin importar cuán acalorado se volviera el debate, se trataba de entregar el mejor producto posible a los clientes. Recibir críticas sobre las ideas y la dirección de los productos es parte de ser un tomador de decisiones en un equipo de producto y debería conducir a un mejor producto porque nadie puede pensar en la mejor manera de hacer todo. Eso también se aplica a los equipos.

No tengo ninguna duda de que todos en el equipo central quieren entregar una revisión de WordPress que sea impresionante, pero inevitablemente te acercas a un proyecto; sabes lo que se ha debatido, considerado, rechazado, etc. y es difícil detenerse y ver las cosas desde una perspectiva externa. Pero no eres la totalidad de la comunidad de WP; no puedes ser Lo que está escuchando son preocupaciones válidas sobre la dirección del producto. Si no puede tomar eso en cuenta, piense en lo que se dice y por qué se dice, por favor, aléjese de tomar decisiones sobre la dirección de Gutenberg.

Alternativamente (y esto sería MUCHO mejor), ASUME estos pensamientos. Considere realmente lo que dice la gente. Comprender nuestras preocupaciones como personas que dirigen negocios que usan WordPress y comprender que nos preocupamos no solo por nosotros mismos, sino también por nuestros clientes.

He estado usando WP desde principios de 2008, y no puedo pensar en una nueva característica o decisión que haya creado tanta división en todo ese tiempo como la introducción de Gutenberg, en su forma actual.

Si bien WordPress está dirigido a los usuarios, no es más que una herramienta, y los usuarios simplemente no podrán hacer uso de esa herramienta si no tienen a los profesionales de WP para ayudarlos a lograr sus objetivos.

Veo referencias a querer atender a los usuarios de una instalación nueva (¿qué? ¿~ 1% del aumento web por año?), Pero eso parece ser a costa de la base de usuarios existente (~ 28%), el la mayoría de los cuales probablemente ejecute un complemento que tenga al menos un cuadro de meta. Eso parece una falta de sentido comercial a cualquier escala.

Entiendo la ideología: crear un editor del mejor de los casos, luego usar un patrón de adaptador para envejecer hablando con lo nuevo. El problema es que PHP y JS son tecnologías diferentes, y pasar ese problema a la tierra de los iframes HTML no es viable, por todas las razones dadas anteriormente.

Fue el primer paso, fue un experimento, pero este esfuerzo no tiene éxito. Cuanto más rápido se reconozca, más rápido podremos pasar a la siguiente sugerencia.

Sin embargo, nadie ha encontrado una solución adecuada cuando se trata de cajas meta que satisfaga a todas las partes.

Eso significa que una de las partes debe ceder, y ya sean 10-50 desarrolladores a favor de Gutenberg, o cientos / miles de desarrolladores que están _ asustados_ o el impacto que tendrán los cambios para ellos, y mucho menos para sus usuarios, ya veremos.

Una vez que se hayan agotado todas las sugerencias de soluciones, tal vez haya una concesión de que anular toda la página no es factible para todas las partes. Al menos no en el único hit que se está intentando actualmente.

Para volver a la pregunta original: ¿son los iframes la solución a largo plazo para las metacajas? Varios desarrolladores (y no olvidemos que también son usuarios) han explicado por qué la respuesta es no.

Hemos tenido una discusión muy constructiva aquí. Recuerda:

Criticamos las ideas, el código y los píxeles, no a los humanos detrás de ellos. Es posible que tengamos diferentes opiniones sobre el mejor camino a seguir, pero no cuestionamos las credenciales. Cuando nos dirigimos a las personas, es para animarlas y darles crédito por un trabajo bien hecho. Con tantas cosas sucediendo en el mundo, debemos cuidarnos unos a otros. Este es un desafío monumental, pero lo lograremos juntos.

Permítanme recordarles a todos que los metaboxes en Gutenberg fueron el resultado de un @ BE-Webdesign que avanzó y logró que esto se hiciera, independientemente de todos los demás, con poca ayuda, apareciendo de la nada. Si no fuera por @ BE-Webdesign, no habría metaboxes en Gutenberg. De los 47 comentarios que quedan aquí, quizás solo 2 personas realmente tocaron el código de metabox para fines de revisión y UX.

Sin embargo, el problema fundamental aquí es cómo hacer que los metaboxes aparezcan en la página de forma segura como ciudadanos de primera clase sin crear un código inseguro, lo que lleva a una compensación de errores hacky o errores.

• La primera iteración involucró un gotcha, haciendo que WP fingiera que estaba en la página edit.php y generara las metaboxes de esa manera. Los informes iniciales indicaron que tenía problemas de compatibilidad y era súper pirata, y no era una solución viable. Esto se debe a que muchos complementos solo registran metaboxes si se cumplen ciertas circunstancias y no confían en que WP sepa cuándo renderizarlos.
• La segunda iteración, que es la que se fusionó, usa iframes, por lo que los metaboxes se muestran en el editor clásico, aunque con todo menos el metabox eliminado. Esto es un poco complicado, pero consiguió que los metaboxes funcionaran, aunque con problemas
• También hay una solución en la que obtenemos el código HTML y luego lo insertamos al por mayor en un componente, lo que sería una catástrofe de seguridad, a pesar de ser la solución súper obvia. De ahí por qué no se ha hecho de esta manera.

Mi sugerencia es:

en lugar de cargar Gutenberg en una página de configuración, cargámoslo en la página principal de editores clásicos, carguemos metaboxes en su entorno nativo y luego elevemos el nodo DOM de su contenedor a un componente a través de JS

Luego usamos un tipo diferente de alternancia para asegurarnos de que el editor clásico aún se pueda usar. De esta manera:

• evitamos las tonterías del iframe
• Los metaboxes funcionan como siempre en lo que respecta al registro.
• el JS existente funciona como se esperaba, y no se necesitan hacks para que las cosas funcionen en el extremo de PHP

Además, el diseño más reciente es bonito, pero ¿a dónde va el meta de bloque?

Desafortunadamente, tengo muy poca experiencia con js al nivel requerido para contribuir con código real a Gutenberg. Solo estoy empezando a sumergirme en el mundo del desarrollo de WordPress en lugar de desarrollar sobre él. Así que lo mejor que puedo hacer es proporcionar mis comentarios, probar el editor (uso activamente Gutenberg en mi blog personal) y proporcionar sugerencias / pensamientos. Si yo pudiera contribuir con el código, absolutamente lo haría. Me encantaría saber si hay otra forma en que pueda ayudar. Porque me preocupo mucho por esto. :)

Contribuir viene de muchas formas. Si bien se agradece el tiempo y el esfuerzo dedicados a desarrollar este intento, las pruebas y la discusión que previenen futuros costos irrecuperables pueden ser igualmente valiosas. Por ejemplo, hay una serie de problemas recientemente abiertos relacionados con la implementación del iframe. Podríamos dedicar muchas más horas a tratar de solucionar esos problemas, o podríamos usar las pruebas y la justificación de este hilo para determinar que se necesita una dirección diferente. Espero que esa sea la comprensión a la que hemos llegado como grupo.

Permítanme recordarles a todos que los metaboxes en Gutenberg fueron el resultado de un @ BE-Webdesign que avanzó y logró que esto se hiciera, independientemente de todos los demás, con poca ayuda, apareciendo de la nada. Si no fuera por @ BE-Webdesign, no habría metaboxes en Gutenberg.

Si bien los elogios y la adoración son agradables 😄, definitivamente tuve ayuda, y es en gran parte un esfuerzo de equipo de muchas personas.

Mi sugerencia es:

en lugar de cargar Gutenberg en una página de configuración, cargámoslo en la página principal de los editores clásicos, carguemos> metaboxes en su entorno nativo, luego elevemos su nodo DOM contenedor en un componente a través de JS

Sí, lo más probable es que esta sea la próxima iteración, y creo que es una gran sugerencia y una idea constructiva. Todavía no estoy 100% seguro de cómo hacer esto de manera limpia, pero es completamente posible no usar iframes y tener la misma UX mejorada que Gutenberg ya está proporcionando. Habrá actualizaciones para mejorar la experiencia del metabox, lo que probablemente involucrará la eliminación de iframes. El método iframe ha servido como una forma de ver cómo se podría implementar el soporte de metabox, ahora se realizarán mejores mejoras. Cuando las cosas se exploraron por primera vez con metacajas hace muchos meses (no es un tema nuevo), tenía sentido avanzar con el enfoque de iframe, debido al estado de Gutenberg en ese entonces, ahora que se fusionó y muchas otras piezas se han movido alrededor, el uso de iframes probablemente ya no sea necesario, desde un punto de vista técnico. Será necesario realizar más trabajo.

@ BE-Webdesign Gracias por sus esfuerzos y aportes aquí. Terminemos con esto y comencemos un nuevo tema cuando ese enfoque esté listo para la discusión.

Deténgase y reevalúe ahora, no más tarde

No todo el mundo está acostumbrado a este enfoque del diseño de proyectos, pero este es un proyecto que sigue una reevaluación diaria continua de prácticamente todo. Compare las maquetas originales con el editor actual. Las cosas cambian. La mayoría de las piezas no están grabadas en piedra. La única forma de evaluar verdaderamente si algo funcionará es hacerlo. No todos se acercan al diseño de productos de la misma manera, pero creo que la rápida iteración de Gutenberg le ha servido bien, en lugar de tratar de eliminar las incógnitas con anticipación.

Gracias a todos por la discusión. Me alegro de que la conversación se haya reenfocado al final en el problema del tema: _¿es viable el enfoque actual de los meta-cuadros en un iframe_? Con la respuesta siendo no. Los iframes son un detalle de implementación que creo que podemos eliminar con relativa facilidad. Así que centrémonos en eso.

Me gustaría agregar, como pensamientos finales, que no cambiar nada sobre la pantalla de edición sería el camino más simple para nosotros. Tampoco sería justo para los objetivos del proyecto y los usuarios a largo plazo de WordPress. Lo que algunas personas han llamado el enfoque pragmático no es concomitante con la dirección de diseño que este proyecto ha tenido desde el principio, hacia la personalización completa del sitio, y lo que ha dictado nuestras decisiones hasta ahora. Nada aquí tiene que ser una solución final, estamos explorando lo que es posible dentro de las premisas de diseño y poniéndolo a prueba. Esto no lo podemos construir nosotros solos y agradecemos sinceramente toda la ayuda que podamos obtener de todos ustedes, ya que hay varios problemas difíciles enterrados en el camino a superar.

WordPress siempre se mueve con el usuario, y nos tomamos la carga de averiguar las rutas de desarrollo para facilitar las transiciones de nuestro código existente. Como proyecto, hemos dicho antes que no dejaríamos de admitir metacajas de WordPress, pero también que teníamos que explorar qué decisiones de interfaz tendríamos que tomar dentro del nuevo paradigma, incluida la posibilidad de cargar el editor clásico cuando detectamos metacajas que no podemos manejar o que entran directamente en conflicto con un editor que busca delinear más claramente qué es contenido y qué son metadatos. Hay personas que podrían beneficiarse de la experiencia Gutenberg predeterminada en este momento. Como desarrolladores, tenemos el privilegio de poder fabricar soluciones, pero también la responsabilidad de no eludir los cambios que tenemos que hacer para permitir que las personas, que de otra manera tendrían dificultades, tengan presencia en la web abierta.

@mtias Realmente aprecio su comentario sensato, especialmente la parte sobre "WordPress siempre se mueve con el usuario".

Desafortunadamente, eso está completamente en desacuerdo con lo que @youknowriad ha estado comunicando en este hilo, y dado que ambos trabajan en Automattic, les insto a que hablen con él sobre la dirección del producto, porque en este momento estamos recibiendo señales contradictorias.

Desafortunadamente, no abordó el boceto de Yoast propuesto que nos daría toda la flexibilidad de Gutenberg y al mismo tiempo sería compatible con los metaboxes existentes. ¿Por qué alguien no puede reconocer por qué no está considerando este enfoque?

Desafortunadamente, eso está completamente en desacuerdo con lo que @youknowriad ha estado comunicando en este hilo.

Creo que entendiste mal lo que dije, solo estaba enumerando hechos y comparto los pensamientos de

@mtias

Lo que algunas personas han llamado el enfoque pragmático no es concomitante con la dirección de diseño que este proyecto ha tenido desde el principio, dirigiéndose hacia la personalización completa del sitio.

Realmente no estoy de acuerdo con esta opinión. Hacer una mejora iterativa que esté restringida al editor en sí, pero que tenga el poder de reemplazar las metaboxes, así como lanzar y promover una API de campos sería una manera sencilla de hacer la transición de la masa de complementos a un paradigma de bloque, simplemente por la facilidad de uso. , en comparación con el paisaje fracturado que tenemos ahora.

Al hacer esa transición intermedia sin problemas, sería mucho más fácil desaprobar la generación / manipulación directa de DOM en la pantalla post_edit, porque para entonces, la solución estándar en la práctica ya no implicaría dicha manipulación. No creo que nadie esté diciendo que "la manipulación directa del DOM debe ser la experiencia principal para siempre". Están diciendo "Ahora es la solución principal".

si puede mantener una flexibilidad total de manipulación de dom con una solución de pantalla completa, hágalo ... pero ese parece ser un objetivo muy elevado, y dudo que cualquier forma de izar desde la pantalla de edición clásica sea realmente capaz de ofrecer en cualquier nivel razonable de compatibilidad. Quizás estoy equivocado, pero parece un truco increíblemente complicado para intentar la transición de usuarios, cuando un enfoque más iterativo podría hacer el mismo trabajo.

Al mantener la primacía del paradigma actual, mientras se lanza el nuevo, fomenta la adopción sin dañar la experiencia actual de nadie. Luego, una vez que la mayoría de los flujos de trabajo hayan pasado a un paradigma de bloque, el control de dom directo puede quedar obsoleto en favor de una solución de pantalla completa.

No se trata de traicionar los objetivos del proyecto, simplemente abordar el cronograma de lanzamiento para que el cambio sea más manejable para miles de agencias y desarrolladores.

@youknowriad Permítanme publicar algunos fragmentos de lo que ha escrito para respaldar lo que estoy diciendo:

aprovechando la API REST, la interfaz de usuario del lado del cliente y unificando conceptos básicos: widgets, códigos cortos, bloques, metaboxes de contenido bajo un concepto único "Un bloque"

Nadie pidió que los "metaboxes de contenido" se convirtieran en bloques, y no se comunicó hasta que Gutenberg envió su versión inicial. De hecho, de esto se trata el núcleo del argumento. No repetiré mucho mejor lo que otros han dicho, solo que los metaboxes muy a menudo no son contenido de página.

A diferencia de lo que lee aquí y allá, el enfoque siempre ha sido rediseñar toda la página. La primera maqueta de la página del editor de Gutenberg se mostró en la segunda o tercera reunión semanal de Gutenberg. Todavía estábamos en la fase de creación de prototipos.

El equipo de Gutenberg seguía diciendo que los bocetos eran solo para mostrar y no el diseño final. Además, un boceto no puede mostrar si toda la pantalla de edición se ha convertido a React o si simplemente se le ha aplicado un estilo diferente. El hecho de que toda la página fuera rediseñada fue una gran sorpresa para todos con los que he hablado.

¿Cuál es la diferencia entre códigos cortos, botones TinyMCE y Metaboxes?
La principal diferencia es que los "Metaboxes" no tienen "propósito", es solo una forma de extender la página del editor sin consistencia, mientras que los códigos cortos y los botones TinyMCE tienen uno.

Este es un gran error que debería sorprender a Automattic. (Y espero que @mtias y @m estén escuchando). Simplemente no es cierto y realmente cuestiono su juicio después de esta declaración.

¿Podemos concluir que para el largo plazo de WordPress, los Metaboxes están bloqueando su evolución (independientemente de Gutenberg)?
Sí lo son.

Yo diría que casi nadie está de acuerdo contigo aquí, y creo que Automattic necesita someter esto a votación para determinar la dirección del producto.

También cuestiono a @mtias diciendo cosas como personas que necesitan contribuir. Es obvio que el equipo de Gutenberg asociado con Automattic no se mueve ni un centímetro y está desviando todas las críticas.

Literalmente, no tengo fe en que si tuviera que hacer un PR para reducir a Gutenberg a ser solo el componente de edición, el equipo de Gutenberg lo consideraría, debido a las declaraciones hechas por algunas personas dentro de Automattic.

@mtias ,

Me gustaría agregar, como pensamientos finales, que no cambiar nada sobre la pantalla de edición sería el camino más simple para nosotros. Tampoco sería justo para los objetivos del proyecto y los usuarios a largo plazo de WordPress.

Yendo un paso a la vez no, de ninguna manera, comprometer los objetivos del proyecto. Aún puede dirigirse a la personalización de tamaño completo si ese es el objetivo, pero al hacerlo de manera escalonada, traerá al resto de la comunidad de desarrolladores con usted.

El Personalizador es un excelente ejemplo de esto. Sí, tiene sus críticos, pero el concepto final se realizará con el tiempo, como una característica que permite a ciertos grupos de usuarios utilizar WP de manera eficiente como herramienta para administrar su sitio.

Hay personas que podrían beneficiarse de la experiencia Gutenberg predeterminada en este momento.

Absolutamente. Pero también hay un número considerablemente mayor de personas que tendrían una experiencia perjudicial con el Gutenberg predeterminado en este momento.

Espero que todos podamos avanzar con respeto y separar a las personas del producto en nuestras respuestas. La pasión es genial, pero es importante que pensemos en los humanos con los que interactuamos en hilos como este. A todas las personas involucradas en este proyecto les importa, no entrarían en estos hilos e interactuarían si no lo hicieran. Ahora, tomemos un respiro y recordemos cuánto nos preocupamos por WordPress y queremos, en el centro de nuestros comentarios, mantener esta comunidad segura y productiva para todos.

@khromov , como líder de diseño de este proyecto, al igual que Matias es el líder tecnológico, estoy 100% detrás de @youknowriad. Entiendo que eres apasionado, pero no respetuoso. Ajuste el enfoque que está tomando llamando a una sola persona. Dejemos de ser personales.

También es importante recordar que muchos de los que trabajaban en Gutenberg eran miembros de la comunidad de WordPress antes, eran (siguen siendo) contribuyentes principales antes. Sí, eso me incluye a mí. Hablaré de manera súper personal aquí, una vez que hagas un PR, por favor notifícame y echaré un vistazo y me aseguraré de que tenga el mismo respeto que todas las reseñas, sin importar de dónde vengan. Por favor, dejemos de ver este proyecto como uno de 'nosotros contra ellos'. No lo es y tenemos algunos contribuyentes que no son de Automattic increíbles aquí, esa declaración les hace un mal servicio.

@cromov

Generalmente se me ve como un detractor de Gutenberg, ya que mis publicaciones y comentarios destacan los problemas que veo con el enfoque y la implementación, pero siento que los objetivos y el progreso de Gutenberg a veces se malinterpretan en los comentarios, debido a una falta de comunicación o falta de comprensión de el objetivo general del proyecto.

Los bloques no son una forma visual de representar y editar el contenido de la publicación, tampoco tienen que ser parte de un menú de selección de contenido o arrastrar / soltar. Se pueden usar para esas cosas, por supuesto, y ese es el flujo de trabajo que muchas de las partes visibles de Gutenberg han destacado. Sin embargo, ignore lo que sabe sobre ese paradigma por un momento y, en su lugar, mírelo de esta manera:

Los bloques están destinados a ser una estructura de control fundamental para el sitio, independientemente de la interfaz o el almacenamiento.

• Los widgets están programados para convertirse en bloques. Eso NO significa que existirán en el editor y se guardarán en post_content. Simplemente significa que se controlarán con un sistema construido en un marco de JavaScript, con una única API común.
• El Personalizador está programado para ser reemplazado por bloques. La interfaz probablemente seguirá siendo (aproximadamente) la misma, pero las secciones del Personalizador estarán controladas por la misma API.
• La página de complementos, el editor de temas, el tablero en sí, están todos programados para convertirse eventualmente en bloques. Si la idea de estas secciones, exactamente como es, es imposible de imaginar recreadas con una API común, entonces probablemente tenga algunos conceptos erróneos relacionados con lo que es un bloque, en el lenguaje de WordPress.

El problema no es que los metaboxes no se puedan recrear dentro del paradigma de bloques, de hecho, los bloques que no son de front-end que se agregan programáticamente a un tipo de publicación, se bloquean en su lugar y se almacenan en post-meta en lugar de post_content están programados para la versión de WordPress 5.0 (corrígeme si me equivoco).

En esencia, eso cubre todas las necesidades de metacampos triviales como cuadros de texto y selecciones. Puede duplicar exactamente esa interfaz en bloques, si lo desea, o posiblemente podría simplificar parte de ella, en función del nuevo lenguaje visual que bloquea el suministro ... esa sería totalmente su decisión.

El problema no es que los metaboxes nunca puedan ser bloques. El problema es que ahora mismo, hay interfaces hechas en metaboxes, que aún no son compatibles con bloques (ya sea por WordPress o por terceros), y volver a implementar ese trabajo es una tarea hercúlea para los desarrolladores, especialmente porque estas herramientas no fueron construidas. desde una API común como la API de Fields propuesta, sino más bien de una manera mezcolanza que modifica directamente el DOM de la página y pone en cola los recursos de una manera ad-hoc y no administrada.

Este estado actual también causa problemas a los desarrolladores. Por ejemplo, si usa Visual Composer, junto con Piklist para los campos, Piklist anulará muchos de sus estilos de administración, lo que hará que VC sea muy difícil de navegar.

O si está utilizando WooCommerce junto con cualquier complemento que ponga en cola la nueva versión de la biblioteca Select2, uno u otro romperá su interfaz de administración, con un error crítico de JS.

Lo mismo puede suceder si dos complementos diferentes se basan en diferentes versiones del marco CMB2.

Los bloques intentan resolver estos problemas mediante la introducción de un marco común en torno a las diversas adiciones de página. Parte de este marco se centrará en ofrecer elementos visuales de arrastrar y soltar wiz-bang al editor, pero la mayoría no está realmente vinculada a eso. Solo se trata de asegurarse de que las cosas que aparecen en la administración se gestionen de forma común.

Ahora, hay argumentos válidos de que WordPress ha prosperado con una actitud de desarrollo del Salvaje Oeste, y que este marco común eleva la barrera de entrada para los desarrolladores que no saben reaccionar. Y hay argumentos válidos de que la interfaz Block no alcanzará nada parecido a la adopción generalizada de los desarrolladores antes del lanzamiento. Incluso hay argumentos válidos de que la API de bloque actual es un poco ingenua y no tiene en cuenta muchos flujos de trabajo comunes, lo que hace imposible adaptar los complementos hasta que se creen y documenten esas capacidades.

Pero argumentar que el Metabox gratuito para todos, como está, es la solución definitiva y debe preservarse para la eternidad no ofrece un gran camino a seguir para nadie. Para que WordPress pueda ofrecer mejores opciones para todos los usuarios, incluidos los desarrolladores, debe existir algún tipo de sistema común.

Hubiera sido bueno si este sistema fuera una API de Fields común, hace años, de modo que todos estos cambios en su mayoría solo fueran un reemplazo del paso de renderizado para esa API, pero tal como está, es necesario encontrar un camino a seguir.

Dicho todo esto, todavía estoy firmemente a favor de la solución provisional propuesta por Yoast, ya que es la mejor forma en el mundo real de avanzar hacia una eventual interfaz de usuario común. Sigo siendo crítico, por supuesto, pero quiero asegurarme de que somos críticos con los hechos y no con malentendidos.

Desafortunadamente, eso está completamente en desacuerdo con lo que @youknowriad ha estado comunicando en este hilo, y dado que ambos trabajan en Automattic, les insto a que hablen con él sobre la dirección del producto, porque en este momento estamos recibiendo señales contradictorias.

Yo diría que casi nadie está de acuerdo contigo aquí, y creo que Automattic necesita someter esto a votación para determinar la dirección del producto.

Es obvio que el equipo de Gutenberg asociado con Automattic no se mueve ni un centímetro y está desviando todas las críticas.

Literalmente, no tengo fe en que si tuviera que hacer un PR para reducir a Gutenberg a ser solo el componente de edición, el equipo de Gutenberg lo consideraría, debido a las declaraciones hechas por algunas personas dentro de Automattic.

Solo me gustaría decir lo obvio, pero Gutenberg es un proyecto comunitario de WordPress, no un producto Automattic . Puede que yo mismo sea un Automattician, pero eso no me da más autoridad en este proyecto que cualquier otra persona, ya sea un profesional independiente, un CEO de una agencia o un desarrollador dedicado que cumple con un compromiso del 5% de la empresa, a diferencia de lo que algunas personas han sugerido. Del mismo modo, WordPress en sí es un proyecto comunitario, no un proyecto Automattic.

Automattic no "lanza" ni "construye" WordPress, y Gutenberg no es un producto de Automattic

Además, antes de que esta conversación se vuelva aún más emotiva y la gente pierda de vista el bosque por los árboles, me gustaría tomarme el tiempo para apreciar la dificultad de la tarea que se le ha asignado al equipo de Gutenberg y lo bien que la están manejando. en general. Se les ha encomendado la tarea de crear un paradigma que se convertirá en la base de toda la experiencia de administración de WordPress, dentro de las limitaciones que solo les permiten demostrar su eficacia en un pequeño rincón de la interfaz.

La cantidad de malentendidos causados ​​por la idea de que "el editor se está haciendo cargo" es inmensa y debe ser muy difícil de manejar. Su competencia es crear los bloques de construcción comunes para el administrador de WordPress y probarlos reconstruyendo el editor. Si bien creo que esta tarea sería mucho más aceptable y flexible para el público si simplemente reconstruyeran la interfaz wp_editor() y la expandieran desde allí, es comprensible por qué todos los componentes conectados de la 'experiencia de edición' hacen un ensayo más completo para el nuevo paradigma propuesto.

Entiendo y agradezco el año de esfuerzo que se ha dedicado a este trabajo. Sigo siendo crítico con algunas de las decisiones tomadas, y creo que hay tiempo para hacer algunas modificaciones que mejorarán enormemente la adopción inicial, pero estoy completamente de acuerdo con el objetivo general de eventualmente proporcionar un marco más estructurado para la experiencia de administración de WordPress. , tanto para desarrolladores como para usuarios.

@karmatosed

La razón por la que mencioné a @youknowriad es que él fue el único que participó en la discusión. Una discusión que ha involucrado a cientos de desarrolladores y miles de horas sin avanzar, a pesar de que existe un claro consenso por parte de los desarrolladores. No creo que sea una falta de respeto cuestionar la legitimidad de las decisiones que se toman cuando las toma un pequeño grupo de desarrolladores, incluso si eso implica llamar a personas específicas.

Independientemente, tuve una charla privada con @youknowriad y me explicó la próxima hoja de ruta que, en mi opinión, suena más sensata que lo que se está comunicando al exterior.

@tomjn

Respetuosamente no estoy de acuerdo. Las decisiones importantes las toman los Automatticians, y después de una charla con @youknowriad , he entendido que la dirección del producto ya está establecida durante mucho tiempo, por lo que no hay nada para nosotros, los colaboradores habituales, que hacer más que corregir errores y quizás algunos elementos visuales menores. retoques.

@gschoppe Solo deseo que este "cambio de paradigma" se debata abiertamente y se haga en colaboración con la comunidad de desarrolladores. Quizás esa sea la intención, pero en ese caso el lado de la comunicación no está funcionando muy bien.

¿Por qué alguien no puede reconocer por qué no está considerando este enfoque?

@khromov teníamos ya , y en algunos otros lugares en los chats, etc. editor de este tema en particular era acerca de la implementación de marco flotante.

Literalmente, no tengo fe en que si tuviera que hacer un PR para reducir a Gutenberg a ser solo el componente de edición, el equipo de Gutenberg lo consideraría, debido a las declaraciones hechas por algunas personas dentro de Automattic.

De ningún modo. Lo consideramos nosotros mismos desde el principio, viéndolo demasiado limitante y no apropiado para impulsar la visión que teníamos. Todavía podría ser un compromiso razonable para muchos y podría ser un buen complemento para explorar. Sin embargo, el trabajo necesario para que esto suceda mejoraría a Gutenberg en general al hacerlo más reutilizable, por lo que no me opondría a la gente que trabaja en él. Si alguien trabajó en tal PR, probablemente sugiera agregar una configuración en la sección de Escritura para alternar el comportamiento en lugar de convertirlo en el predeterminado.

Tenemos características importantes relacionadas con bloques anidados, bloques globales, plantillas de bloques de declaración, columnas, etc., que realmente se benefician de que la hoja de contenido sea la página completa y se sentirían bastante pobres de otra manera, limitando lo que los desarrolladores pueden hacer y lo que los usuarios pueden experimentar. También hay buenas herramientas como el esquema del documento que se integran a la perfección y en tiempo real en el editor de pantalla completa que se idearían en un mero reemplazo de TinyMCE.

Dar un paso a la vez no compromete, de ninguna manera, los objetivos del proyecto.

¡Seguro! Hemos propuesto un enfoque por etapas, desde la publicación original de nuevos enfoques de Matt, solo considera los pasos de manera diferente. Generalmente hay tres etapas para el proyecto Gutenberg: desde el editor de publicaciones hasta las plantillas de página y la construcción del sitio. Lo primordial es que el paradigma es aquel en el que el contenido es un área única, con el _bloque_ como concepto principal, y donde el resultado puede representarse visualmente con claridad y sin abstracciones excesivas.

Absolutamente. Pero también hay un número considerablemente mayor de personas que tendrían una experiencia perjudicial con el Gutenberg predeterminado en este momento.

Por supuesto, y es por eso que hay un complemento para volver a la experiencia actual a voluntad, y tendremos mecanismos para manejar las incompatibilidades, permitiendo que se opten más cosas (por ejemplo, si se siente cómodo con sus meta-cajas mostrando en Gutenberg que podría declarar su apoyo, o viceversa).

@gschoppe Sé que hemos tenido una buena cantidad de desacuerdos en el pasado, pero agradezco sus comentarios aquí y su voluntad de participar incluso desde los diferentes puntos de vista. Hace algunos buenos puntos sobre el factor aglutinante del bloque. Quizás algún día nos encontremos en una conferencia de WC y podamos embarcarnos en una divertida discusión filosófica sobre la paradoja del barco de Teseo. Quién sabe. 😉

Usted, de Automattic, no debe quejarse de que no podemos respetar su trabajo y de que lo estamos presionando demasiado.
No por 7000 - 10.000 € de salario mensual que te pagan. Tonto. No es como cuando la gente se queja en WP Trac a los desarrolladores voluntarios.
Si Gutenberg te da dolor de cabeza, habla con tu jefe. Te dio una tarea imposible de hacer.

En segundo lugar, son mejores programadores que la mayoría de las personas que comentaron aquí. ¿Por qué intentó aprobar la solución "Iframes"?
Te lo dije, tratas a las personas como niños. Intentemos con iframes y veamos si la gente gritará demasiado, será demasiado emocional. Si hay mucho ruido nos alejamos de los iframes.

¿Por qué intentó aprobar la solución "Iframes"?
Te lo dije, tratas a las personas como niños. Intentemos con iframes y veamos si la gente gritará demasiado, será demasiado emocional. Si hay mucho ruido nos alejamos de los iframes.

Cuando se implementó por primera vez el soporte de metabox, el nuevo editor existía en una página de administración completamente nueva, no en post.php, el editor se cargaba de manera diferente y, en general, había muchas restricciones, parte de la resolución del problema de metabox usando iframes, iluminado algunas de esas restricciones, que ya no existen, y como resultado, es muy probable que las metacajas ya no necesiten usar iframes.

Este proyecto favorece la mejora incremental en las versiones sobre la perfección en una sola versión. Nadie está tratando de ver si la gente gritará. La realidad es que el enfoque de iframe funcionó bien para la mayoría de las metacajas, a pesar de lo que la gente ha hecho. Ahora se mejorará aún más, y habrá cada vez menos 😱 🙀.

@StaggerLeee , sea respetuoso con todos en este proyecto, sin importar dónde trabajen. Así como le gustaría que alguien lo tratara bien, haga lo mismo con los demás.

Como líder de diseño de este proyecto, no veré declaraciones personales como usted le dijo a nadie. No me importa dónde trabaje alguien o cualquiera de sus antecedentes, esos son detalles personales sobre los que no tiene derecho a llamar. Por favor, deje el personal y vuelva a concentrarse en el producto.

Ahora, sigamos adelante y centrémonos en hacer el mejor producto que podamos. Entiendo absolutamente que sus puntos a menudo provienen de un lugar de pasión. Puedes ser respetuoso y apasionado, vuelve a ser eso.

Usted, de Automattic, no debe quejarse de que no podemos respetar su trabajo y de que lo estamos presionando demasiado.
No por 7000 - 10.000 € de salario mensual que te pagan. Tonto. No es como cuando la gente se queja en WP Trac a los desarrolladores voluntarios.
Si Gutenberg te da dolor de cabeza, habla con tu jefe. Te dio una tarea imposible de hacer.

@StaggerLeee Desearía que me pagaran esa pista, pero Automattic no es Google, y puedo ganar más en otras partes del mundo de WP. Mi propia presencia aquí es puramente de mi propia espalda, no me pagan por estar aquí, y tampoco muchas otras personas que trabajan en esto. ¡De hecho, me pagan por hacer revisiones de código y ayudar a lanzar clientes empresariales!

Así que confía en que el mensaje ha sido recibido, la prueba está en la pestaña Pull Requests en la parte superior, esto no es una conspiración de Automattic para romper tu código y molestar a tus clientes (_no olvides, Automattic tiene clientes que pagan usa metaboxes también_)

Para aquellos que aún están preocupados por los iframes , les sugiero que miren aquí esta solicitud de extracción (https://github.com/WordPress/gutenberg/pull/3345) que intenta deshacer los iframes e implementar mi sugerencia hecha anteriormente.

Como próximas iteraciones de las implementaciones de metaboxes, sería bueno probar e identificar problemas de compatibilidad, arrojar fruta podrida hacia A8C puede sentirse bien, pero no ayuda.