FWIW cuando hablé con los desarrolladores web, todos usan metaboxes para el contenido para que tengan el máximo control. No estoy seguro de que las metaboxes vayan a ser consideradas "legadas" para mucha gente, sino parte del futuro. Podría valer la pena ponerse en contacto con la gente VIP de WordPress para obtener su opinión.

No estoy seguro de que las metaboxes vayan a ser consideradas "legadas" para mucha gente, sino parte del futuro. Podría valer la pena ponerse en contacto con la gente VIP de WordPress para obtener su opinión.

Mis disculpas, esa fraseología fue mala. Los metaboxes llegaron para quedarse. Es por eso que la barra lateral de metabox recibe una actualización en forma de la nueva barra lateral "Configuración de publicación".

Lo que quise decir es que los nuevos metaboxes deben escribirse en JS y aparecerán en la barra lateral de Configuración de publicación junto con los de stock. Los metaboxes escritos en PHP idealmente deberían actualizarse para ser JS, pero deberían continuar funcionando también en su forma PHP. Para eso es el panel "Configuración extendida", y se encuentra en la parte inferior no porque no queramos que formen parte de la barra lateral, sino porque es muy difícil mezclar metaboxes PHP y JS en una barra lateral.

Existen algunos grandes desafíos al enviar metaboxes administrados por PHP a través de JS y Ajax, particularmente en cómo manejar la actualización del renderizado de metabox para reflejar el estado recién guardado: https://core.trac.wordpress.org/ticket/7756

Me pregunto si incrustar un metabox heredado a través de un iframe podría ser una solución aquí, donde el iframe src es algo así como /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings y solo genera ese metabox en el documento.

Lo que quise decir es que los nuevos metaboxes deben escribirse en JS y aparecerán en la barra lateral de Configuración de publicación junto con los de stock.

¿Significa esto que los metaboxes de JavaScript solo pueden ir en la barra lateral y no pueden ser parte de la sección de "configuración extendida"? Solo en la parte superior de mi cabeza puedo pensar en muchos complementos donde la barra lateral realmente no proporcionará suficiente espacio y hará que la barra lateral esté potencialmente desordenada. Solo algunos complementos que pueden tener problemas con este enfoque:

• Yoast SEO: proporciona una gran cantidad de campos, que probablemente no quepan en la barra lateral; tal vez podría tener un metabox de la barra lateral que abriera un modal para más opciones, pero esto se siente como evitar una limitación innecesaria.

• Complementos de campo personalizados / constructores de páginas de arrastrar y soltar: estos reemplazan o reemplazan parcialmente el área de contenido principal y, por lo tanto, necesitan mucho espacio en la pantalla. El potencial de los creadores de páginas completas les garantiza que creen su propia interfaz totalmente personalizada como una vista separada, pero en algunos casos se requieren varios campos estructurados adicionales además del área de contenido principal (y aprecio que Guttenburg debería reducir la necesidad de este tipo de plugin, pero igualmente no puede cubrir todos los casos de uso)

• WooCommerce: agrega metaboxes para los datos de pedidos y artículos de línea, mientras que elimina el editor principal (Woo planea eventualmente construir su propia interfaz personalizada, pero sospecho que esto está muy lejos, y otros complementos estarán en una situación similar)

(Supongo que se planea que Guttenburg eventualmente reemplace las vistas actuales post-new / post-edit.php, en lugar de simplemente ser una alternativa)

Ja, gracias @braders - Yoast UX-er se registró aquí con la misma pregunta :)

Nuestro metabox es bastante grande y ancho en este momento, ya que hace muchas cosas. No nos importaría trabajar más esas funciones en los diferentes metaboxes de la barra lateral para ofrecer una integración más estrecha, pero me preguntaba si eso sería posible. Por ejemplo, ¿podemos agregar puntajes de SEO al cuadro Publicar como lo hacemos actualmente? Y si no es así, ¿podemos conectarnos al cuadro de configuración extendida incluso si nuestro metabox está codificado en JS?

Deberíamos considerar absolutamente hacer que la nueva Configuración de publicación sea conectable, para que pueda agregar metaboxes de JavaScript a la barra lateral. Quizás es hora de abrir un boleto para eso. Este ticket es principalmente para metaboxes escritos en PHP, que necesitan funcionar de manera transitoria.

En la misma línea que los metaboxes en la sección extendida, ¿se ha realizado alguna discusión o maquetas sobre cómo se presentaría un tipo de publicación que no admite la edición de contenido de publicación? En esos casos, se confía en los metaboxes del área central para la experiencia de edición principal. ¿Gutenberg debería presentar un modo "Sólo título"? ¿O debería manejarse el título de la publicación de manera diferente en ausencia del editor?

En la misma línea que los metaboxes en la sección extendida, ¿se ha realizado alguna discusión o maquetas sobre cómo se presentaría un tipo de publicación que no admite la edición de contenido de publicación? En esos casos, se confía en los metaboxes del área central para la experiencia de edición principal. ¿Gutenberg debería presentar un modo "Sólo título"? ¿O debería manejarse el título de la publicación de manera diferente en ausencia del editor?

¡Sería bueno crear un ticket por separado! Con capturas de pantalla del tipo de publicación existente, ¡si las tienes! ✨

También quiero enfatizar que muchos complementos usan tipos de publicaciones personalizadas que se basan en cajas meta sin un editor de contenido. Si el tipo de publicación se registra sin soporte para editor , debería haber un modo de solo título que abra el lienzo completo para que lo utilicen los metaboxes.

+1 para comunicarse con WordPress VIP. Esto también es un problema en el hilo de Calypso: https://github.com/Automattic/wp-calypso/issues/587

¡Característica realmente importante para la cima del mercado!

Me pregunto si incrustar un metabox heredado a través de un iframe podría ser una solución aquí, donde el iframe src es algo así como /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings y solo genera ese metabox en el documento.

Yo también tuve esta misma idea. También es una buena idea por motivos de sandboxing y administración de sesiones. Luego, podemos identificar casos de uso comunes de esta función e implementar una API para manejarlos.

Quería ingresar como desarrollador de complementos y como alguien que usa WordPress principalmente como una herramienta de comercio electrónico. También porque @kevinwhoffman me lo dijo.

Hoy cansé a Gutenberg y literalmente no puedo procesar esto como si fuera WordPress sin ver cómo los metaboxes y los botones del editor (agregados a través de media_buttons hook) son parte de esto.

Tampoco soy un gran admirador del estado actual del editor de WordPress y del metabox-palooza. Acabo de contar y en la descarga (tipo de publicación de producto de Easy Digital Download) vista de publicación única tengo 14 cajas meta personalizadas agregadas por Yoast, Easy Digital Downloads y mi propio código personalizado usando CMB2. Es mucho, pero los necesito. WordPress es bastante inútil sin esa interfaz y lo que expone.

Me preocupa que esto no se haya tenido en cuenta desde el principio, ya que he trabajado en tantos sitios donde la interfaz de campos personalizados agregada con ACF, Pods, CMB2, etc. fue la experiencia de edición completa.

Aquí están mis preocupaciones técnicas:
1) Botones agregados a través de media_buttons. En mi complemento Caldera Forms (más de 80K instalaciones activas), usamos esta acción para agregar un botón de inserción de formulario que muestra un modal para insertar el código corto en el editor de publicaciones. Quizás nos mudaríamos a un bloque personalizado en Gutenberg.
2) ¿Cómo la acción save_post sigue siendo compatible con versiones anteriores? Tantos complementos, temas y códigos personalizados se enganchan en save_action y acceden a $ _POST super global. Ese no es un buen diseño, pero es una deuda técnica que afecta a millones de sitios.
3) Hubo una sugerencia de renderizar metaboxes heredados en un iFrame. Esto me preocupa porque no es posible acceder al contenido de un iFrame a través de JavaScript.

@ Shelob9 ¡hola!

Hubo una sugerencia para renderizar metaboxes heredados en un iFrame. Esto me preocupa porque no es posible acceder al contenido de un iFrame a través de JavaScript.

Acceder al contenido de un iframe a través de JavaScript _es_ posible, siempre que esté en el mismo dominio, como sería en este caso.

¿Cómo la acción save_post sigue siendo compatible con versiones anteriores? Tantos complementos, temas y códigos personalizados se enganchan en save_action y acceden a $ _POST super global. Ese no es un buen diseño, pero es una deuda técnica que afecta a millones de sitios.

Hay mucho que podemos hacer para facilitar la transición de metaboxes heredados a Gutenberg. Hay una diferencia fundamental en cómo se modelan los datos en Gutenberg frente a la pantalla de edición de publicaciones actual. Es decir, los datos ahora se modelan realmente por primera vez. Con el modelado de datos, finalmente podemos usar interfaces JavaScript para manipular el estado de las publicaciones y postmeta de formas que son imposibles usando $_POST y la acción save_post , y mucho menos poder _preview_ cambios en postmeta. Al enrutar los cambios de postmeta a través del modelo, esto permitirá obtener una vista previa de postmeta por primera vez. Entonces, aunque Gutenberg puede incluir metaboxes heredados siempre que sea posible, siempre estarán intrínsecamente limitados en cuanto a cuánto pueden aprovechar la nueva interfaz. Creo que eso es tan real como la realidad de que tenemos deuda técnica.

Creo que es la decisión intencional y consciente de Matt de que la deuda técnica debe cancelarse para que WordPress evolucione de manera que siga siendo relevante en el futuro. Cuanto más podamos actualizar ACF, Pods y CMB2 para usar el modelo de datos que está introduciendo Gutenberg, creo que será más fácil esta transición. ¡Sin duda habrá muchos desafíos y mucho trabajo por delante!

@westonruter gracias por

Sospecho que parte de la discusión aquí también tiene que ver en parte con el espacio disponible en la pantalla.

Parece que los metaboxes de Gutenberg JS pueden acceder a la barra lateral que se puede alternar (lo cual está bien para mí), mientras que los metaboxes de PHP heredados tienen acceso a un área mucho más amplia disponible en la parte inferior de la pantalla (que también está bien para mí).

Desafortunadamente, espero que este deseo de espacio disponible en la pantalla pueda interferir con la discusión prevista sobre cómo manejar eficazmente los metaboxes de PHP heredados.

Estoy de acuerdo en que en lugar de apoyar todas las formas antiguas, los creadores de complementos deberían reconsiderar sus metaboxes y cómo pueden integrarse mejor con el nuevo diseño. Al mismo tiempo, también estoy de acuerdo en que se deberían ofrecer posibilidades similares de integración en el nuevo editor (y confío en que lo harán). Creo que el número 1352 es el lugar principal para discutir eso actualmente. Este número es para discutir la forma en que proporcionaremos compatibilidad con versiones anteriores para metaboxes PHP no actualizados en el lanzamiento.

Me pregunto si incrustar un metabox heredado a través de un iframe podría ser una solución aquí

Acceder a los iframes no es una experiencia muy emocionante para los usuarios de lectores de pantalla. ¿Alguna otra opción?

Solo quería intervenir aquí, la barra lateral simplemente no es lo suficientemente grande para la mayoría de las metacajas que vemos en complementos y temas. Obligarnos a meter cosas en este pequeño espacio es un revés en mi opinión. Creo que este nuevo editor es genial, sin embargo, no si significa sacrificar la forma en que usamos los metaboxes hoy.

Estoy totalmente de acuerdo con

En respuesta a @westonruter, gracias por aclarar la compatibilidad con versiones anteriores. Creo que hay que dejar MUY claro que WordPress 5.0 o donde sea que llegue no es compatible con versiones anteriores, ya que esa ha sido la expectativa del usuario.

También me preocupa cómo se manejarán los metaboxes, especialmente en ciertos tipos de publicaciones personalizadas donde el editor de contenido puede no ser el enfoque principal del CPT. Voy a elegir WooCommerce aquí porque es un complemento muy conocido, pero hay muchos otros complementos y temas que tienen problemas similares.

Por ejemplo, los pedidos de WooCommerce no tienen editor de contenido, simplemente no es necesario. Los detalles sobre el pedido son lo importante, no la edición de contenido, y legítimamente deberían ser el enfoque principal de esa página.

¿Los CPT como este tendrán la capacidad de eliminar el editor si no es necesario? El complemento no parece estar completamente integrado con metaboxes personalizados en CPT, por lo que es difícil saber si esto se ha considerado o no.

Los productos WooCommerce también plantean otro problema en el que hay dos áreas de contenido: una para la descripción del producto y otra para la descripción breve del producto. ¿Será necesario que uno tenga prioridad sobre el otro en el área del editor "principal", mientras que el otro se atasca en la barra lateral? Parece una experiencia de edición menos que óptima para la que está en la barra lateral.

¿Puede haber una opción para registrar intencionalmente estas configuraciones en el área debajo (o arriba?) Del editor en lugar de abarrotarlas todas en la barra lateral? Esto podría ser similar al contexto actual de add_meta_box y los parámetros de prioridad . Quizás, incluso alternar entre varios editores de contenido (u otros metaboxes) que pertenecen a la sección más amplia de la página.

Tal vez me falte algo aquí (corríjame si me equivoco), pero parece que se está haciendo un gran esfuerzo para un mejor editor cuando, en realidad, no todos los usos de WordPress requieren algo diferente de lo que se usa hoy.

PREGUNTE cómo definimos un CPT para que no use Gutenberg (equivalente a ningún editor), y muestre SOLAMENTE los metaboxes de ancho completo en los que confían nuestras empresas.
Confío en los metaboxes. La mayoría de las veces mis CPT se ven así
'supports' => array( 'title' )
Y se extienden desde allí. Considere a aquellos de nosotros que hemos creado herramientas comerciales para clientes que utilizan CPT con metaboxes como entrada de datos de formulario restringida y guiada, en lugar de para la redacción de artículos.
Mi trabajo consiste principalmente en extensiones personalizadas de CMB2 que interactúan con los sistemas cliente. Anuncios inmobiliarios de EG que utilizan sistemas de terceros.

No quiero sonar dramático, pero me quedaré con WP4.9 hasta que esto se resuelva y estoy muy preocupado por el futuro. ¡Entiendo que Gutenberg está "cancelando la deuda con el pasado"! Pero la deuda recae sobre personas como yo.

El tema aquí parece ser que el problema no es con Guttenburg, sino más bien con la falta de compatibilidad con versiones anteriores.

Hay algunos problemas reales de Guttenburg, para los cuales posiblemente se deberían generar tickets separados (permitir que los metaboxes utilicen una maqueta de Guttenburg de ancho completo sin soporte de editor), pero Gutturnberg no puede replicar totalmente las pantallas actuales y tampoco debería intentarlo en mi humilde opinión.

Sin embargo, me pregunto si se debería hacer más para que Guttenburg opte por participar o no. Algunas ideas:

• Supongo que la mayoría de los CPT actuales hacen un uso intensivo de los metaboxes sobre el editor principal. Entonces, tal vez los autores de complementos deberían optar por Gutturnberg con 'supports' => array( 'gutenburg' ) o similar

• Para publicaciones y páginas, Guttenburg debería ser opcional como configuración del sitio. Incluso sería posible preguntar a los usuarios si desean utilizar Guttenburg después de la actualización 5.0 y almacenar esta opción en la base de datos.

• O alternativamente, los temas podrían declarar soporte a través de post_type_supports (), pero esto podría dañar seriamente la aceptación, o los temas podrían optar por no participar que no ayudarían a los usuarios de temas heredados no mantenidos que ya no están actualizados. (¿Quizás un complemento remove-guttenburn sería suficiente para los usuarios de temas heredados?)

Pero, independientemente de la implementación, creo que la vista actual debería permanecer, incluso si está cada vez más oculta para la mayoría de los usuarios ...

Me gusta la idea teórica de que los CPT soliciten explícitamente 'supports' => array( 'gutenberg' ) para mantener la funcionalidad existente en el caso de que la bandera de soporte 'gutenberg' no esté definida. Me ahorraría mucho trabajo arreglando sitios antiguos para clientes enojados que se actualizaron a WP5.

Observo que los 'soportes' => características existentes (título, editor, autor, ...) tienen nombres muy autodescriptivos, Gutenberg se destaca como un nombre de _proyecto_ aquí. Me pregunto si se consideraría un nombre de función más descriptivo para ese uso; tal vez "editor de bloques"? 'supports' => array( 'block-editor' )

Por supuesto, se necesitaría una estrategia para detectar errores como 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . Asumiría que la bandera 'editor de bloques' simplemente anularía el modo 'editor' anterior.

Otro desarrollador de complementos aquí con preocupaciones.

Si el meta de la barra lateral solo es accesible a través de JS, ¿qué significa esto para los metaboxes registrados en PHP con un contexto de side ? Moverlos a la sección de Configuración Extendida propuesta revoca la idea de que esos metaboxes son contextuales.

Como todos sabemos, las barras laterales no solo son una buena decisión de diseño; con frecuencia mantienen contenido relacional de una manera que ayuda al usuario a comprender la prioridad de sus contenidos y la relación con el contenido principal. Asignar un metabox side un contexto diferente debido a una barrera técnica parece un poco equivocado.

Teniendo en cuenta la JS-ificación progresiva del área de administración, estas metaboxes "heredadas" también brindan a los desarrolladores de complementos y temas un punto de montaje natural para React / Vue / otras aplicaciones autónomas para proporcionar funcionalidad adicional a la página de edición.

El editor se ve muy bien, pero no se olvide del resto de la página.

He tenido la oportunidad de pensar en esto un poco más y con un contexto compartido por otros aquí, creo que hay otro problema. Este nuevo editor nos obliga a utilizar un diseño y un flujo de trabajo únicos; ¿Por qué estamos eliminando la personalización? La capacidad de esculpir la entrada de datos por cliente es lo que hace que WordPress y la mayoría de las otras soluciones sean realmente geniales. Cuanto más juego con este editor, más se siente como una versión inflada del Personalizador donde el área de vista previa ha sido reemplazada por un editor y la barra lateral simplemente cambia de lado.

También se ha mencionado que podríamos usar esto para escribir publicaciones, pero permitir que los CPT agreguen soporte para esto. No creo que eso funcione realmente tampoco. A las organizaciones de noticias les encantaría este tipo de editor, pero también tienen el requisito de flujos de trabajo personalizados en torno a contenido adicional, programación, incrustaciones, infografías y otros datos necesarios.

¿Qué hay de hacer que este editor se comporte como el editor de pantalla completa / sin distracciones? De esta manera podríamos tener lo mejor de ambos mundos sin sacrificar la funcionalidad y el código "heredado". (Por cierto, creo que es ridículo que la forma en que actualmente construimos metaboxes ahora se denomine "heredada ..." en este proyecto).

Gracias por su tiempo chicos, se agradece.

¿Qué hay de hacer que este editor se comporte como el editor de pantalla completa / sin distracciones?

+1

Voy a reiterar mi principal preocupación: los CPT a menudo no requieren el 'editor' porque la publicación se crea a partir de metaboxes grandes y agrupados dinámicamente en un flujo de trabajo de usuario guiado (por ejemplo, datos de productos WooCommerce).

Tales metaboxes no encajarán en el cajón de "configuración extendida" propuesto porque forman elementos de entrada de contenido principal y deben ser prominentes en el editor de publicaciones, de ancho completo y abiertos. Con eso en mente, el número 952 parece una concesión demasiado pequeña, ya que relega la entrada de datos importantes a un cajón cerrado.

Si se espera que los desarrolladores _refactoricemos_ todas nuestras viejas soluciones de metabox en bloques, entonces alguien de Automaticc debe decirlo de manera clara y pública antes de que el martillo caiga en 5.0. No veo ninguna señal de que el equipo haya considerado esta parte del mercado y las implicaciones para los negocios.

Ya se han agregado muchos buenos pensamientos aquí, así que solo incluiré estos simples pensamientos:

En lugar de tener un expansor de "Configuración extendida" en la parte inferior para todas las cosas heredadas, ¿por qué no simplemente hacer un expansor para cada metabox que descanse en la parte inferior exactamente así, cuando el metabox está en los contextos normal y avanzado, y luego usar la configuración lateral para el contexto lateral?

No parece que estemos tan lejos de una solución. Y si el tipo de publicación no es compatible con el editor, oculte el editor pero haga que todo lo demás se muestre de la misma manera. Es un diseño razonable. Simplemente proporcione opciones como configurar el metabox expandido predeterminado.

Ciertamente no me importa la idea de considerar el método actual de renderizar metaboxes heredados y proporcionar un método nuevo, impulsado por js y preferido para construir los campos. Luego podemos cambiar gradualmente sin tener que entrar en pánico por las cosas que se rompen inmediatamente en 5.0.

Espero que estos pensamientos ayuden. Si alguien más ya ha dicho algo en este sentido, tómelo como un acuerdo. 😄

Me gustaría agregar otros dos ganchos valiosos a la discusión: edit_form_after_title y edit_form_after_editor que actualmente brindan un control completo sobre la interfaz de usuario posterior a la edición. Obviamente, Gutenberg no es solo un reemplazo de "wp_editor", es una versión completamente diferente de la interfaz de usuario (y como se ve actualmente, su futura capacidad de expansión modular).

Veo que temas como este están tratando de solucionar el problema, pero siento que no se trata de "qué sucede con nuestros metaboxes", se trata más de la pregunta hacia dónde se dirige WordPress como un "producto".

Es fácil detectar el objetivo a medio plazo de establecer una solución de este tipo: será bastante fácil mover esto a la interfaz (y tal vez acercarse a algunos competidores).

Desde la perspectiva de los desarrolladores / negocios / planificación, sería útil comprender la intención (futura) de 'Gutenberg', ¿o alguien puede señalarme una declaración de misión de este tipo o algo similar?

Algunas opiniones más mías ...

Observo que los 'soportes' => características existentes (título, editor, autor, ...) tienen nombres muy autodescriptivos, Gutenberg se destaca como un nombre de proyecto aquí. Me pregunto si se consideraría un nombre de función más descriptivo para ese uso; tal vez "editor de bloques"? 'supports' => array ('editor de bloques')

Estoy de acuerdo, esto suena como un detalle que se puede ordenar una vez que se acuerda el enfoque 😄

Por supuesto, se necesitaría una estrategia para detectar errores como 'soportes' => matriz ('título', 'editor', miniatura ',' editor de bloques '). Asumiría que la bandera 'editor de bloques' simplemente anularía el modo 'editor' anterior.

Vería a Gutenberg extendiendo los soportes de tipo de publicación actual, por lo que si no hubiera soporte editor , Gutenburg solo mostraría título / barra lateral / opciones extendidas. Entonces, ¿tal vez el soporte de Gutenburg se manejaría mejor como un argumento de registro CPT separado, en lugar de ser parte de la matriz de soportes?

En lugar de tener un expansor de "Configuración extendida" en la parte inferior para todas las cosas heredadas, ¿por qué no simplemente hacer un expansor para cada metabox que descanse en la parte inferior exactamente así, cuando el metabox está en los contextos normal y avanzado, y luego usar la configuración lateral para el contexto lateral?

Personalmente, me gusta esta idea: si estos paneles pudieran reordenarse y ocultarse como sea posible en este momento, esa podría ser una solución ideal ...

Posiblemente, también debería haber una forma de establecer uno (¿o más?) O estos como abiertos al cargar la página, especialmente si el tipo de publicación no es compatible con el editor principal.

También se ha mencionado que podríamos usar esto para escribir publicaciones, pero permitir que los CPT agreguen soporte para esto. No creo que eso funcione realmente tampoco. A las organizaciones de noticias les encantaría este tipo de editor, pero también tienen el requisito de flujos de trabajo personalizados en torno a contenido adicional, programación, incrustaciones, infografías y otros datos necesarios.

Si la nueva pantalla basada en reacciones es tan conectable como las antiguas pantallas de edición, entonces no hay razón por la que estos flujos de trabajo personalizados no se puedan agregar en la parte superior de la página / barra lateral / debajo del editor o en cualquier otro lugar de la página. (Descargo de responsabilidad: no tengo un conocimiento profundo de React, por lo que queda por ver cuánto más complejos serán los ganchos fuera de PHP). También # 1352

Creo que la confusión aquí se debe a que hay una diferencia fundamental en cómo Gutenberg está reimaginando al editor para que sea el bloque primero . En otras palabras, deberíamos dejar de pensar en agregar metaboxes y pensar en agregar bloques. Los campos que antes colocaba en metaboxes, ahora avanzará en lugar de colocarlos en bloques.

Cuando define un tipo de publicación personalizada, esto probablemente incluiría los bloques que se requieren y qué bloques simplemente están permitidos. Para un tipo de publicación personalizada que no tiene editor soporte todavía tendría el "editor" mostrado en Gutenberg, pero esencialmente podría deshabilitar el _inserter_. Los bloques que aparecen en el editor se bloquearían en su lugar de acuerdo con lo que requiera el tipo de publicación. Si los bloques no se hubieran poblado, aparecerían como _ marcadores de posición_. Tenga en cuenta que estos bloques pueden almacenar sus propiedades en postmeta como lo hacen actualmente las metaboxes, pero lo harían de forma normalizada en lugar de ad hoc a través de la acción save_post y $_POST global.

Así que creo que el resultado final aquí será en gran medida el mismo. Los autores de complementos seguirán obteniendo un "cuadro" para colocar campos personalizados. Es solo que aparecerán en bloques en lugar de metaboxes.

Creo que la confusión aquí se debe a que hay una diferencia fundamental en cómo Gutenberg está reimaginando al editor para que sea el bloque primero. En otras palabras, deberíamos dejar de pensar en agregar metaboxes y pensar en agregar bloques. Los campos que antes colocaba en metaboxes, ahora avanzará en lugar de colocarlos en bloques.

@westonruter Esto parece lo suficientemente sensato para los metaboxes que contienen contenido, pero muchos metaboxes sirven para meta de publicaciones específicas que no tendrían sentido en el contenido de las publicaciones.

Gracias @westonruter por la aclaración, pero esto me plantea un par de preguntas nuevas.

Los bloques que almacenan sus datos como post_meta parecen un tipo de bloque fundamentalmente diferente al que he visto hasta ahora en la demostración. ¿Estos datos también se almacenarían de forma redundante en el flujo del contenido de la publicación?

¿Hay algo que impida que un autor agregue más de un número aceptable de bloques a una publicación? (Agregar varios campos post_meta cuando solo uno tiene sentido)

Tiendo a estar de acuerdo con post_content en el front-end. Aquí hay un ejemplo con el complemento The Events Calendar (mi interpretación) de una tribu moderna.

En esta situación, el contenido principal son los detalles del evento, no el área de contenido de forma libre. El complemento usará los metadatos de su tipo de publicación personalizada para ensamblar su propio marcado y post_content es simplemente el texto descriptivo que se imprime en la parte inferior de la página. Debido a esto, el bloque de detalles del evento no debería ser movible, borrable o realmente ser parte de la salida del contenido. Sin embargo, debería aparecer primero, porque representa el contenido principal para este tipo de publicación.

WooCommerce sería otro ejemplo en el que uno o más bloques de información de producto deberían tener prioridad sobre el texto descriptivo en un tipo de publicación de Producto, pero no deberían ser bloques opcionales que se espera que el usuario inserte.

Creo que el concepto fundamental para los bloques debería ser ensamblar la interfaz de usuario adecuada para la publicación y no necesariamente implicar dónde se almacenarán o procesarán esos datos en la interfaz.

... deberíamos dejar de pensar en agregar metaboxes y pensar en agregar bloques.

Eso tiene sentido para el contenido, pero muchos complementos usan tipos de publicaciones personalizadas para no contenido, como formularios o pagos. Estos tipos de publicaciones no se parecen de ninguna manera a una publicación de blog, ni sus metacampos abstractos se beneficiarían de un editor de bloques. Forzar que toda la configuración se realice mediante bloques elimina el lienzo abierto en el que los desarrolladores de complementos han llegado a confiar, el mismo lienzo abierto que ha hecho del ecosistema de complementos lo que es hoy.

El enfoque actual parece ser un bloque primero con metacajas confinadas a un rol de apoyo. Si bien los bloques beneficiarán a muchos complementos centrados en el contenido, la necesidad de definir configuraciones abstractas seguirá beneficiándose de las etiquetas obvias y las entradas familiares que proporcionan los metaboxes. En esos casos, los desarrolladores deben tener la libertad de utilizar todo el lienzo.

@westonruter ¿Puede aclarar que lo que dice es que si mi tipo de publicación personalizada requiriera ciertos campos adicionales, tendría esos datos ingresados ​​en un bloque?

Si es así, tengo algunas preguntas de seguimiento:

1) ¿Podría convertir ese bloque en predeterminado? Es decir, siempre se mostró en ese tipo de publicación y no se pudo eliminar. Por ejemplo, si mi complemento creó eventos y cada evento tenía una fecha de inicio y finalización, ¿se requeriría el bloqueo para la fecha de inicio y finalización y en el contenido de la publicación al editar el tipo de publicación personalizada del evento de forma predeterminada?

2) ¿Cómo se guardarían los datos de ese bloque? Según tengo entendido, en este momento los datos de los bloques se almacenan como comentarios HTML en post_content. ¿Cómo obtendríamos los datos de estos bloques para publicar meta? Por ejemplo, para mi complemento de evento hipotético, ¿cómo obtendría la fecha de inicio y finalización en la meta de la publicación para poder consultarlos?

3) ¿Cuál es la razón de que todo vaya en la dirección del editor de contenido principal y que se aplique a los tipos de publicaciones personalizadas? ¿Hay alguna prueba de usuario que respalde esta dirección de diseño, especialmente con respecto a los tipos de publicaciones personalizadas que no representan una publicación / artículo de blog?

@kevinwhoffman Todavía no veo un conflicto fundamental para los bloques. Las configuraciones abstractas aún pueden considerarse contenido, pero de un tipo diferente: son todos datos. Cada bloque no necesita tener una representación visual en "el contenido". Creo que también podría haber "metabloques", almacenando datos en postmeta en lugar de post_content . Los bloques que se están editando se pueden diseñar para que tengan títulos / etiquetas similares a cómo se presentan hoy las metaboxes.

@ Shelob9 sí, si su tipo de publicación personalizada requiere campos adicionales, creo que se presentarán en un bloque. Si tiene un tipo de publicación personalizada de "producto", entonces podría haber un bloque product-details singular que tenga campos para el precio, variaciones, etc.

1. ¿Podría convertir ese bloque en predeterminado? Es decir, siempre se mostró en ese tipo de publicación y no se pudo eliminar. Por ejemplo, si mi complemento creó eventos y cada evento tenía una fecha de inicio y finalización, ¿se requeriría el bloqueo para la fecha de inicio y finalización y en el contenido de la publicación al editar el tipo de publicación personalizada del evento de forma predeterminada?

Sí exactamente. Los tipos de publicación personalizados, los formatos de publicación y las plantillas de página podrían involucrar simplemente el concepto de bloques requeridos que están "bloqueados", que no se pueden eliminar ni reordenar. Un ejemplo de esto sería un bloque para el extracto de la publicación: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. ¿Cómo se guardarían los datos de ese bloque? Según tengo entendido, en este momento los datos de los bloques se almacenan como comentarios HTML en post_content. ¿Cómo obtendríamos los datos de estos bloques para publicar meta? Por ejemplo, para mi complemento de evento hipotético, ¿cómo obtendría la fecha de inicio y finalización en la meta de la publicación para poder consultarlos?

La mayoría de los bloques almacenan hoy sus datos en HTML dentro de post_content pero no es necesario. Por ejemplo, en https://github.com/WordPress/gutenberg/issues/1288 puede ver la discusión de un bloque Extracto que almacena su contenido en post_excerpt y un bloque de Imagen destacada que almacena su contenido en postmeta. Por lo tanto, definitivamente debería poder tener un bloque event-details que tenga una fecha de inicio y finalización que se almacene en postmeta.

1. ¿Cuál es la razón de que todo vaya en la dirección del editor de contenido principal y que se aplique a los tipos de publicaciones personalizadas? ¿Hay alguna prueba de usuario que respalde esta dirección de diseño, especialmente con respecto a los tipos de publicaciones personalizadas que no representan una publicación / artículo de blog?

Según lo anterior, los datos se pueden obtener y guardar en post_content , postmeta, términos o en cualquier otro lugar. La idea de ser "bloque primero" es tener un _block_ de construcción común que todo use y, al hacerlo, los componentes del bloque se pueden reutilizar al máximo en WordPress. Ese es mi entendimiento.

@westonruter - Gracias por la aclaración. Esto es muy útil ya que no hay mucha información sobre cómo este editor se relaciona con los tipos de publicaciones que no son publicaciones / artículos de blog, etc.

Espero que pronto veamos documentación sobre cómo escribir un "metabloque".

Debemos considerar lo que le estamos enseñando al usuario a través de la experiencia de edición de publicaciones y cómo eso se relaciona con los tipos de publicaciones personalizadas.

Al editar una publicación predeterminada en el editor de bloques, el usuario aprende que cada bloque representa contenido. Las configuraciones asociadas con el contenido están disponibles en un panel / metabox que vive fuera del editor de bloques. El contenido vive en bloques. Los ajustes viven en paneles. Se ha dicho en otra parte que lo que el usuario ve en el editor de bloques debería ser una vista previa de la página cuando se publique.

Luego, combinar la configuración y el contenido en el editor de bloques para tipos de publicaciones personalizados rompe la idea de que el editor de bloques es una vista previa. Creo que deberíamos dejar que el editor de bloques haga lo que mejor hace, que es editar contenido, y permitir a los desarrolladores crear interfaces de configuración que no compartan los mismos requisitos que un bloque de contenido.

He estado trabajando en un extenso complemento que agrega metacajas como lo hacen WooCommerce y EDD. La mayoría de las veces, elimino el editor de contenido de la pantalla porque no es necesario. Me preocupa un poco que no deba ser algo que debamos fusionar con Gutenberg.
De lo contrario, ¿a dónde iría todo esto?

Estoy de acuerdo con @kevinwhoffman en que si los bloques van a representar meta, entonces necesitan una señal visual para el usuario de que son de alguna manera diferentes del contenido de la publicación y no deberían esperarse en la salida. Una forma de abordar eso es un divisor. Básicamente, esto es solo una reinterpretación de la forma en que el contenido se separa de los metaboxes ahora.

Esto no me resuelve todos los problemas, pero creo que es una forma interesante de renovar los metaboxes y probablemente podría ser bastante compatible con los complementos existentes, pero esa no sería una experiencia de primera clase para el usuario.

Aquí hay un intento de informar al usuario cuando un metabloque es el contenido principal, el contenido de la publicación se usa como descripción y hay metabloques adicionales.

@brentjett Gracias por las maquetas. Como señala, la necesidad de separar la configuración del contenido es importante, pero no veo el beneficio de requerir que un cuadro de configuración como Yoast sea un bloque en primer lugar.

• _No_ representa contenido en la página, rompiendo así la idea de que el editor de bloques es una vista previa del contenido en la página.
• _No_ requiere múltiples instancias.
• _No_ se beneficia de ser reposicionado en medio de otros bloques de contenido.
• _Debe_ estar presente en la página de forma predeterminada.

Cada uno de estos rasgos va en contra del comportamiento predeterminado de un bloque. Seguro que hay varias discusiones para hacer bloques de un solo uso que se pueden bloquear en su posición y presentar de forma predeterminada. Pero, ¿por qué convertir un bloque en un metabox cuando podríamos centrarnos en mejorar la implementación del metabox que ya sirve para este propósito?

No veo el beneficio de requerir que un cuadro de configuración como Yoast sea un bloque en primer lugar.

Retrocedamos aquí por un minuto. Dos cosas. Uno es el soporte para metaboxes antiguos escritos en PHP, para lo cual tenemos el cajón de "configuraciones extendidas" simulado en esta publicación.

La otra cosa es responder la pregunta: si quisiéramos rediseñar esto desde cero, ¿cómo se vería hoy?

Aquí es donde estamos proponiendo _blocks_, como una nueva interfaz que puede unificar muchos dispares. Ya estamos sugiriendo que los bloques pueden ser superiores a los códigos cortos, HTML personalizado, widgets y una oferta para incrustaciones. Dependiendo de lo que haga el metabox, no hay razón para que no pueda incluir también esta interfaz.

Convenido. Y hablando por Yoast por un segundo, planeamos integrarnos en muchos lugares alrededor del nuevo editor, mejorando la experiencia a la que apunta Gutenberg en lugar de construir un gran bloque para emular nuestro antiguo metabox, pero ha habido otros ejemplos mencionados anteriormente que podrían también creo que funciona como un bloque. Sí, se necesita algo de trabajo, pero si resulta que este editor entusiasmará a los usuarios de wordpress una vez que gane un poco más de tracción, es una oportunidad emocionante para repensar cómo nos integramos con él, y creo que nuestros productos mejorarán como resultado.

Entonces, tenemos dos casos funcionales _legacy_:
MetaBoxes que manejaban metadatos (como Yoast), y tenemos MetaBoxes que se utilizaron para proporcionar una interfaz estructurada para ingresar contenido (como WooCommerce).

Desarrollando para el futuro
Si partimos de una pizarra en blanco ("cancelando nuestra deuda con el pasado"), entonces es cierto que poner metadatos en el cajón "avanzado" propuesto puede funcionar. Además, la entrada de contenido estructurado podría encajar en una interfaz de orden de bloque bloqueada dentro de Gutenberg. Ambos son completamente hipotéticos, pero potencialmente funcionarían como implementaciones para futuros desarrollos de WP CMS.

problemas de CMS empresarial heredado
El 99% de mi trabajo consiste en proporcionar soluciones comerciales a medida directamente a las empresas de mis clientes. Así que mi preocupación no son las grandes cosas que podría construir en el futuro, sino los hechos fríos y duros de la funcionalidad del sitio de mi cliente y las relaciones comerciales. ¿Qué propuestas existen para migrar las empresas existentes basadas en soluciones CMS a Gutenberg? En mi situación, cada cliente tiene una solución CMS a medida diferente construida sobre el marco WP establecido. Para mí la frase "cancelar la deuda con el pasado" = "Tirar al bebé con el agua del baño".

Preocupaciones
Si Gutenberg se envía como núcleo en WP5.0, anticipo que mis clientes tendrán sitios no funcionales. Luego, cada sitio deberá volver a hacerse y cada cliente deberá apaciguarse. Alrededor de 40 clientes pueden querer que repare su CMS en esa semana.

• Los sitios dependientes de metabox de CMS heredados y su base de usuarios parecen no ser esenciales para el equipo central
• la propuesta de sorteo "avanzado" # 952 ha sido despriorizada, lo que indica falta de interés en toda el área.
• no hay un método propuesto para resolver el problema de la "deuda con el pasado" / CMS

Aquí es donde estamos proponiendo bloques, como una nueva interfaz que puede unificar muchos dispares. Ya estamos sugiriendo que los bloques pueden ser superiores a los códigos cortos, HTML personalizado, widgets y una oferta para incrustaciones.

Los bloques tienen sentido para todas esas cosas: códigos cortos, HTML personalizado, widgets, incrustaciones. Son todas las formas de contenido que aparecen en la página. Estoy de acuerdo, bloquearlos a todos.

La configuración no es ninguna de esas cosas. Los ajustes tienen requisitos distintos que no se superponen con el comportamiento fundamental de un bloque. En muchos casos, estos cuadros de configuración almacenan metadatos de publicaciones que no influyen en la presentación frontal de una publicación. Analizar el no contenido junto con el contenido cada vez que se muestra una publicación parece innecesario.

Otra cosa a considerar es lo que sucede cuando el usuario cambia al modo Texto. ¿Verán un montón de comentarios HTML que representan cuadros de configuración junto con el contenido de su publicación? ¿El usuario eliminará estas cosas desconocidas?

Todo esto podría simplificarse tratando los bloques como contenido y la configuración como un componente de interfaz de usuario independiente. Incluso si no tuviéramos que considerar las metacajas heredadas (que es un gran problema, señaló

La sección de inquietudes de

Esta es una gran discusión de lo que será posible en el futuro y que todo suena muy bien, WordPress realmente necesita esto. Para mí, como desarrollador de complementos, no es gran cosa, haré un bloque o dos y seré bueno. Pero, ¿qué sucede con los clientes de Steve y los millones de sitios web que se vendieron a clientes con la expectativa de compatibilidad con versiones anteriores?

Entiendo estas preocupaciones porque también tengo muchos clientes cuyos sitios web probablemente se rompan con la actualización. Algunos pensamientos míos:

Usamos ampliamente ACF para la gestión de contenido. Por ejemplo, podríamos tener varios editores de tinymce por publicación o en un repetidor. si el objetivo es reemplazar tinymce, ¿cómo haríamos para usar múltiples "contenedores de bloques"? Entiendo correctamente que en este momento solo hay un "contenedor de bloques", ¿verdad?

Otra característica de ACF que no se ajusta al flujo de edición posterior son las páginas de opciones. Realmente no veo cómo funcionaría esto en una página de opciones.

Para aquellos que quieran compatibilidad con versiones anteriores, alguien probablemente creará un complemento para restaurar la experiencia de edición actual, si no hay tiempo / recursos para actualizar a gutenberg (esto es algo que planeo usar). Además, 5.0 sería un salto de versión principal, lo que significa que los cambios importantes están bien (al menos de acuerdo con los estándares de semver ).

WordPress no sigue a semver.

@westonruter creo que esto tiene sentido:

Los campos que antes colocaba en metaboxes, ahora avanzará en lugar de colocarlos en bloques.

Pero, ¿cómo llegamos desde allí (metaboxes) hasta aquí (bloques)? Tanto en términos de backcompat para código (complementos que aún no se han actualizado para Gutenberg) y backcompat para datos (¿cómo mostramos los datos de metabox existentes en un nuevo bloque de contenido, una vez que se actualiza un complemento para él? ¿Es ese un complemento- problema de alcance?).

Pero, ¿cómo llegamos desde allí (metaboxes) hasta aquí (bloques)? Tanto en términos de backcompat para código (complementos que aún no se han actualizado para Gutenberg) y backcompat para datos (¿cómo mostramos los datos de metabox existentes en un nuevo bloque de contenido, una vez que se actualiza un complemento para él? ¿Es ese un complemento- problema de alcance?).

Estas son buenas preguntas. Exploraremos las respuestas a medida que implementemos estas funciones.

Si tuviera que adivinar dónde terminaremos aquí: los metaboxes actuales se moverán a un área "heredada" y proporcionaremos API, documentación y ejemplos para registrar objetos de bloque de metabox de "nuevo estilo".

@nylen ¿qué pasa con el _rendering_ de los metaboxes actuales?

Es una buena noticia que se prioricen las metacajas, pero debemos considerar una solución que vaya más allá de colocar las viejas cajas meta en un cajón o limitarlas a un área "heredada".

En la actualidad, existen innumerables sitios que se construyen principalmente con metaboxes a través de complementos como Advanced Custom Fields. Estamos hablando de interfaces de pantalla completa aquí, no solo una o dos casillas en la parte inferior de una publicación. Estoy seguro de que ACF se actualizará para funcionar con Gutenberg, pero esos sitios no se reconstruirán.

Entonces, la pregunta sigue siendo, ¿qué sucede con una interfaz que no tiene editor y está compuesta completamente por metacajas?

Entonces, la pregunta sigue siendo, ¿qué sucede con una interfaz que no tiene editor y está compuesta completamente por metacajas?

La idea aquí, y corrígeme si me equivoco

¿Qué hay de hacer que este editor se comporte como el editor de pantalla completa / sin distracciones?

+1. Esta es una buena idea, ya que no afecta en absoluto al editor actual con metacajas. Si bien el editor sin distracciones estuvo allí durante mucho tiempo, no se usa mucho. El editor de Gutenberg puede tomar esto y mejorar en lugar de reescribir la pantalla del editor.

Además, sería mejor si registramos soporte para el editor de Gutenberg con el parámetro supports cuando register_post_type .

Finalmente, como desarrollador de metabox, me encantaría ver una nueva API para hacer que las metabox funcionen para el nuevo editor. Como puede ver aquí, muchos desarrolladores usan metaboxes como una forma de proporcionar contenido adicional para las publicaciones. Ese contenido se puede categorizar y buscar más tarde. No son simples bloques de contenido como contenido de publicación. Entonces, si hay un nuevo reemplazo para la función add_meta_box() , estoy feliz de refactorizar mi complemento Meta Box para que funcione con eso.

Estoy de acuerdo con todo lo que se ha dicho sobre: ​​hacer que los metaboxes estándar sigan funcionando / tengan un lugar. Como desarrollador principal de CMB2, puedo garantizar que habrá una protesta bastante significativa si CMB2 se rompe de alguna manera cuando se lance WordPress 5.0. Ciertamente no me refiero a esto como una amenaza, sino simplemente como una realidad.

Cuanto más podamos actualizar ACF, Pods y CMB2 para usar el modelo de datos que está introduciendo Gutenberg, creo que será más fácil esta transición.

Definitivamente buscaré hacer esto a largo plazo, pero no estoy seguro de que sea una expectativa justa que las bibliotecas de metabox tengan esto en su lugar para cuando se publique gutenberg. (De acuerdo, puede que esa no sea la expectativa)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

E incluso si se actualiza, las instalaciones antiguas se romperían.

Tenga en cuenta también que los grupos de campo en ACF no necesitan estar en metaboxes, pero también existe el estilo 'Seamless (sin metabox)' con las opciones 'Side', 'normal - after content' y 'high - between title and editor (!!!) '. El último importante para crear un flujo de edición significativo.

Tenga en cuenta que hay muchos desarrollos individuales críticos que nunca se actualizarán porque nadie pagará por eso. Romper esas implementaciones será el asesino definitivo para WP en entornos empresariales.

@ wsydney76 Tenga en cuenta también que los grupos de campo en ACF no necesitan estar en metaboxes, pero también existe el estilo 'Seamless (sin metabox)' con las opciones 'Side', 'normal - after content' y 'high - between title y editor (!!!) '. El último importante para crear un flujo de edición significativo.

Vale la pena señalar que esto no es algo que "simplemente funcione" en WordPress, sino que requiere un código de complemento personalizado para eliminar la interfaz de usuario de metabox habitual, por lo que es razonable suponer que esto requerirá trabajo adicional de ACF para trabajar con Gutenburg.

Hazlo simple. Cuando el tipo de publicación personalizada no tiene soporte para el editor (Gutenberg) declarado, use su imaginación, habilidades CSS y sus diseñadores centrales más talentosos para convertir el editor completo en otra cosa. Haga que aparezca como algo que el cliente / usuario no ve cuando está en la pantalla de edición posterior (nativa). Se trata solo de apariencia. A los clientes no les importa si Gutenberg funciona en segundo plano o no, no les podría importar menos incluso si los desarrolladores web se lo informan. Son tipos de personas visuales.

Con respecto a la compatibilidad con versiones anteriores, propuse una versión de soporte a largo plazo de WordPress en febrero, mucho antes del anuncio de que Gutenberg llegara a 5.0.

En ese momento parecía una tarea improbable, pero ahora que está sucediendo, es aún más importante discutir cómo hacer 4.9 una versión LTS, cortar el soporte previo a 4.9 y enfocarse en 5.0.

La publicación se puede encontrar aquí:
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 años + desarrollador de WordPress aquí. Como muchos señalaron, este desarrollo es excelente para el contenido. Es una solución estándar realmente necesaria para bloques de contenido dinámico con marcado personalizado. Habiendo dicho eso, esto limita el uso de tipos de publicaciones de manera que se desvíen del contenido y acerquen WordPress a un marco.

Como ejemplo: construí un conjunto de complementos que permiten no solo crear campos para tipos de publicaciones (como muchos otros) sino también crear relaciones entre ellos (es decir, uno a uno, uno a muchos, etc.). Esto (junto con más funciones) convierte los tipos de publicaciones en algo muy parecido a los modelos en marcos como Laravel o Rails, y luego uso un DSL para trabajar con esas publicaciones, sus datos y sus relaciones.

Este tipo de uso está lejos de ser infrecuente, y el propio WordPress fomentó los usos creativos de los tipos de publicaciones al permitir a los desarrolladores declarar los tipos de publicaciones como no públicos. Las banderas como 'public', 'public_queryable' y 'show_ui' están destinadas a permitir que los desarrolladores utilicen tipos de publicaciones para otros fines que no sean una simple relación espejo 1: 1 con una página pública en el sitio web.

¿Cómo encaja Gutenberg con esa visión?

No veo otra solución que mantener este editor como opcional, es decir, debería reemplazar a TinyMCE pero el editor debería seguir siendo opcional al igual que TinyMCE es opcional en este momento.

Si podemos seguir creando tipos de publicaciones que no son compatibles con el editor y podemos seguir usando metaboxes en esos tipos de publicaciones, creo que se podría llegar a un consenso mucho más rápido.

La adopción del nuevo editor por parte de los desarrolladores de temas y complementos podría volverse más lenta con este tipo de enfoque, pero honestamente no veo otra salida que no signifique ir por el camino 4.9 LTS, lo que permitiría iniciar nuevos proyectos. con WP 5.0 y proyectos heredados para quedarse con 4.9 LTS.

ACTUALIZACIÓN: cuando escribí este comentario, el título del hilo era diferente y se estaba discutiendo la posibilidad de desaprobar los metaboxes (es decir, el equipo central aún no había respondido claramente a esta pregunta con un firme "no" como lo hizo en los comentarios a continuación). En tal escenario, Gutenberg simplemente habría admitido bloques dinámicos e ignorado los muchos otros casos de uso de metaboxes, de ahí mi comentario anterior.

Después de haber pasado algún tiempo leyendo los comentarios de todos, me parece que el resultado probable de esta evolución de la pantalla de edición es proporcionar una nueva API de metaboxes que funcione dentro de esta pantalla de edición basada en js. Es decir, en realidad no perdemos la capacidad de usar publicaciones de formas creativas como mencioné anteriormente, sino que simplemente obtenemos una nueva API para hacerlo y la interfaz de usuario estará basada en js.

Estamos planeando usar Pods 2.7 para crear una aplicación con tecnología React utilizando la API REST de WordPress y GatsbyJS .
¿Gutenberg será compatible con Pods?

Veo que este tema vital se ha eliminado de cualquier hito. Se le ha quitado la prioridad _ de nuevo_ mientras que las campanas y los silbatos para la edición de blogs obtienen mucho trabajo y se agregan a las versiones beta. Esto es muy preocupante para el futuro de Wordpress como CMS.

Hice mis propios generadores de código inspirados en GenerateWP. Para mi uso personal y privado en localhost, no público.
De todos modos, me pregunto cómo se vería en el Gutenberg cuando se realiza el cambio. Campos ACF, mucho código PHP personalizado para Preview.

No nos hemos olvidado de este tema. Más bien, es un tema extremadamente complicado que apenas estamos comenzando a analizar, junto con muchas, muchas otras prioridades para que el editor funcione bien.

Algunas de las dificultades que encontraremos al conectar los metaboxes pueden resultar evidentes al leer el número 2251, que también contiene información sobre los próximos pasos desde una perspectiva técnica.

El punto principal que quiero enfatizar en este tema, aquí, es que necesitamos ayuda de la comunidad para planificar y probar esta implementación.

Aquí hay un punto de partida para ver una lista de complementos:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Complementos que no aparecen arriba, probablemente porque no están en el directorio de complementos de WP.org:

• Gerente de campo

Si conoce otros complementos de uso generalizado que realizan una tarea similar, háganoslo saber aquí en este número.

Si usted es el desarrollador de uno de estos complementos y / o puede proporcionar detalles sobre qué enlaces de

Advanced Custom Fields agrega sus metaboxes registrando un gancho contra admin_enqueue_scripts . Este gancho verifica que la carga de la página actual sea post.php o post-new.php , y si es así, agrega una acción admin_head que llama a add_meta_box . WP core hace sus llamadas do_meta_boxes poco después de esa acción, en edit-form-advanced.php .

Finalmente, si usted es un desarrollador familiarizado con la forma en que WordPress actualmente procesa y guarda metaboxes, su entrada aquí y / o en # 2251 es apreciada .

Hola chicos,
Elliot aquí - ACF dev.

ACF usa la acción admin_enqueue_scripts para realizar la "lógica de coincidencia de grupos de campos" y luego la acción admin_head para agregar metaboxes (a través de add_meta_box() ). No utiliza la acción add_meta_boxes .

¿Puedo hacer una pregunta obvia aquí? ¿Por qué estamos discutiendo las 'dificultades' de los metaboxes? Estos son una parte integral de cada sitio web de WP. Seguramente la lógica de metabox puede permanecer como está y convivir con la nueva área de edición de Gutenberg.

Asegúrese de etiquetar en @woocommerce también. Lo más probable es que sean el complemento de metabox más grande.

Gracias
mi

Hola chicos-

Todavía estoy formulando algunos pensamientos e ideas, pero quería incluir una pregunta rápida porque parece que esta discusión se está enfocando un poco demasiado.

¿Por qué solo estamos hablando de agregar campos a las metacajas? El sistema actual nos permite agregar cualquier cosa. Datos, javascript para acceder a API de terceros para usar sus herramientas, una visualización rápida de notas o información de ayuda, e incluso imágenes de lindos gatitos que chocan los cinco con la gente (bueno, tal vez no este, pero quién sabe, ¿no?).

El punto que estoy tratando de hacer aquí es que las metacajas son contenedores universales que pueden contener una variedad de cosas que incluyen, pero no se limitan a, campos. En este momento es bastante fácil con PHP hacer esto, sin embargo, ¿estamos pidiendo a la gente que sepa cómo escribir un componente React solo para agregar, digamos, algo de texto?

Como dije, solo trato de agregar al contexto de la conversación.

Gracias,

Kevin - Desarrollador principal de Piklist

Esta pregunta se ha aludido en muchos comentarios anteriores, pero no ha sido respondida que yo sepa:

¿Es posible reemplazar el editor de publicaciones de TinyMCE existente con Gutenberg y dejar el resto de la interfaz, incluidos los meta boxes y los ganchos existentes, sin cambios?

Este alcance reducido permitiría incluir o excluir a Gutenberg de los tipos de publicaciones personalizadas al definir el soporte de editor al registrar el tipo de publicación.

• Si se registra el soporte de editor , entonces Gutenberg está presente en la pantalla de edición con los metaboxes existentes que continúan funcionando como lo hacen hoy en el editor actual.
• Si el soporte de editor no está registrado, entonces Gutenberg no se carga y el lienzo en blanco está disponible para los metaboxes como está hoy.

Este enfoque parece evitar el desafío masivo de la compatibilidad con versiones anteriores de las implementaciones de metabox existentes al tiempo que libera recursos para hacer el mejor editor posible.

¿Puedo hacer una pregunta obvia aquí? ¿Por qué estamos discutiendo las 'dificultades' de los metaboxes?

@elliotcondon : si un problema de desarrollo es difícil de resolver, la única forma de llegar a una solución es superar las dificultades. Empecé a hacer esto en el n. ° 2251, pero como se explica allí, no será una tarea rápida ni una solución fácil.

Gracias por confirmar la información que recopilé sobre cómo ACF registra sus metaboxes. Para avanzar un poco más en la implementación con respecto a ACF específicamente, estas son las siguientes cosas que sería útil saber:

• Qué scripts y hojas de estilo se ponen en cola para controlar la funcionalidad de las metaboxes de ACF
• Qué acciones se encargan de ponerlos en cola
• Cualquier condición que controle si están en cola o no.

¿Por qué solo estamos hablando de agregar campos a las metacajas?

Me gustaría llegar a un lugar donde el código de Gutenberg no tenga que preocuparse mucho por lo que está haciendo realmente un metabox.

Con ese objetivo, @kevinpmiller ,

• Qué acciones se encargan de llamar a add_meta_box para registrar metaboxes
• Cualquier condición que controle si están registrados o no (por ejemplo, la pantalla actual es post.php o post-new.php )

En este número, mantengamos la conversación centrada en hacer que los metaboxes de PHP existentes funcionen junto con la interfaz de Gutenberg.

En este momento es bastante fácil con PHP hacer esto, sin embargo, ¿estamos pidiendo a la gente que sepa cómo escribir un componente React solo para agregar, digamos, algo de texto?

Sí, necesitamos desarrollar un conjunto de API para crear metaboxes de "nuevo estilo". Esto es lo que tenemos hoy para los bloques: espero que sea bastante similar, con los metaboxes registrados como "bloques" que pueden guardar en otro lugar que no sea post_content : http://gutenberg-devdoc.surge.sh/

La discusión sobre metaboxes de nuevo estilo debería ocurrir en # 1684 o en una edición separada para proponer una API técnica.

Si el soporte de editor no está registrado, entonces Gutenberg no se carga y el lienzo en blanco está disponible para los metaboxes como lo está hoy.

@kevinwhoffman : Gutenberg tal como está escrito hoy está destinado a ser un editor de post_content . Entonces, es lógico que si el soporte de editor no está habilitado, al menos por ahora, lo deshabilitamos. Esta también es una tarea bastante fácil desde la perspectiva del código. ¿Puede crear un nuevo problema para esto y lo etiquetaré con la etiqueta Good First Task ?

Gutenberg, tal como está escrito hoy, pretende ser un editor post_content .

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

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

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

@kevinwhoffman - Muy bien dicho. Esto refleja mis pensamientos exactos, así como muchos otros desarrolladores con los que he hablado.

No deseo sacar este problema del tema, pero no entiendo por qué debe haber dificultades de 'metabox' al presentar un nuevo creador de páginas JS. Esto es lo que quiero decir cuando digo:

¿Por qué estamos discutiendo las 'dificultades' de los metaboxes?

Estoy feliz de leer eso:

Si el soporte del editor no está registrado, entonces Gutenberg no se carga y el lienzo en blanco está disponible para los metaboxes como lo está hoy.

Si lo anterior es cierto, toda la lógica de wp-admin (acciones, funciones, etc.) debería permanecer igual (ish) para la pantalla de edición de una publicación. Por lo tanto, no debería haber ninguna razón por la que el HTML de metabox no se pueda procesar como se ha hecho durante años.

@nylen
ACF pone en cola algunos archivos JS y CSS para diseñar e interactuar con el elemento HTML del metabox de ACF.
ACF usa las acciones 'admin_enqueue_scripts' para agregar estos activos
Muchos otros complementos y temas ponen en cola estilos / scripts: ¿por qué sería esto un problema?
ACF no usa JS para guardar metadatos. Utiliza la acción save_post para guardar cualquier $_POST datos - cosas bastante normales.

Además, la necesidad de una API para traducir metacajas de PHP en metacajas de React es un problema manufacturado.

Esto no es exactamente lo que estamos haciendo. Es más como: dado que ya no usamos el proceso de carga tradicional post.php , entonces tenemos que seleccionar las cosas que necesitamos.

Si el soporte del editor no está registrado, entonces Gutenberg no se carga y el lienzo en blanco está disponible para los metaboxes como lo está hoy.

Para aclarar: este no es el caso actualmente, pero sería algo razonable explorar en un PR. Si está interesado en que esto funcione hoy, por favor ayude, será mucho más rápido.

@kevinwhoffman @elliotcondon @nylen O mejor aún, qué tal:

• Si el soporte de block-editor está registrado, utilice Gutenberg.
• Si editor support está registrado, utilice TinyMCE.
• Si no se registra ningún soporte, entonces no se cargan ni Gutenberg ni TinyMCE.

No estoy a favor de fracturar la experiencia de WP Admin basándose en la presencia o ausencia de Gutenberg.

Si Gutenberg = New React Meta Boxes y No Gutenberg = Old PHP Meta Boxes, entonces un administrador fracturado es la dirección en la que nos dirigimos.

Las metacajas deberían funcionar igual en todas partes, independientemente de si hay un editor presente.

Ejemplo: digamos que tengo un complemento que agrega un metabox para calificar publicaciones con 5 estrellas. El complemento está diseñado para que se pueda calificar cualquier tipo de publicación. ¿Por qué deberían cambiar las partes internas de ese metabox en función de si el tipo de publicación usa un editor o no?

@kevinwhoffman

No estoy a favor de fracturar la experiencia de WP Admin basándose en la presencia o ausencia de Gutenberg.

¿Fue eso en respuesta a mi sugerencia con respecto a block-editor , o algo más?

Por cierto, no veo mi sugerencia como una fractura de la experiencia, lo veo como una construcción de su sugerencia de incluir metaboxes existentes si existen en la configuración de WordPress.

@mikeschinkel La capacidad de habilitar o deshabilitar a Gutenberg es necesaria, pero la idea de que Gutenberg determine el comportamiento de la caja meta es lo que estoy argumentando. Esos son temas separados.

@kevinwhoffman Estoy de acuerdo contigo, por cierto.

Desde Pods, estamos haciendo cosas normales, documentadas y estándar utilizando las mismas acciones que ACF y CMB2. Todos lo estamos haciendo de la manera que se recomienda que se haga en este momento.

+1 en la capacidad de continuar usando metacajas junto con Gutenberg, en última instancia, las personas podrán usar Gutenberg para cosas que pertenecen directamente al contenido, y para todo lo demás, todavía están las metacajas que les encantan por atributos e información adicional sobre una "publicación "(de cualquier tipo).

-1 al tener que reescribir todo en React, al menos admitir ambos durante un largo tiempo hasta que todos tengan tiempo de sentirse cómodos con el método React y admita más / solucione los problemas para las implementaciones de metabox. No creo que haya un momento en el que los metaboxes de PHP deban eliminarse gradualmente, mantenerlos para la retrocompatibilidad y permitir que los complementos migren a medida que la documentación del metabox de React y la habilidad del desarrollador mejoren en esa área.

Después de la discusión en este boleto, así como de las conversaciones públicas y privadas que se derivan de él, creo que hay una pregunta crítica que debe responderse aquí:

¿WordPress tiene la intención de desaprobar formalmente la API de Metabox?

Si la respuesta es No, entonces todo el asunto de “movamos las cosas y paralécelas un poco” no tiene sentido. Si la API sigue siendo compatible con los estándares de compatibilidad con versiones anteriores del núcleo de WordPress, entonces la expectativa total es que cualquier implementación de metabox existente simplemente funcione. Como hacen las cosas en WordPress.

Si la respuesta es Sí, entonces este es un enorme cambio en la política de compatibilidad con versiones anteriores y el fin de la era para el desarrollo de WordPress en su conjunto. No solo requiere "resolver" metaboxes en Gutenberg. Se requeriría una enorme reeducación y aclaración de que el período de muchos años de desarrollo del núcleo de WordPress realizado de cierta manera y que proporciona cierto nivel de expectativas de compatibilidad con versiones anteriores ha terminado.

Desafortunadamente, la respuesta actual parece ser no decir Sí, sino intentar romper las cosas, mientras finge que es un No. Personalmente, me parece un enfoque extremadamente atípico para una característica principal importante y es muy desconcertante que se esté haciendo de esa manera.

La pantalla Publicar edición es _la_ pantalla más personalizada en todos los proyectos que van más allá de un blog básico.

Estas personalizaciones no se limitan a registrar metaboxes. Cualquier gancho que ofrecen las pantallas de administración de edición está en uso en el mismo proyecto. Y para aquellos casos en los que no hay ningún gancho, los desarrolladores usan jQuery para inyectar elementos de la interfaz de usuario en la página.

Entonces, para estas personalizaciones, debe haber un camino a seguir.

Para los metaboxes, Fieldmanager es la herramienta de elección, debido a que está aprobada por VIP. Fieldmanager es poderoso, pero se enfoca en un conjunto limitado de campos. Las bases de código heredado a menudo no se pueden actualizar para usar Fieldmanager u otra biblioteca de utilidades.

Por lo tanto, muchos metaboxes todavía se construyen utilizando código personalizado. El código personalizado significa una combinación de PHP y JavaScript, a menudo con interacciones impulsadas por Ajax.

La sugerencia de colocar todos estos metaboxes cuidadosamente elaborados desde su posición prevista en un área debajo del editor es absurda.

Cualquier regresión de las opciones de personalización en la pantalla Publicar edición disponible en este momento será inaceptable.

Si es necesario actualizar el código existente, puede contar entre 12 y 18 meses desde el momento en que se finalizan todas las API nuevas para que estas actualizaciones se realicen en los proyectos del cliente. Lo que significa que debe haber un período de ejecución dual, en el que coexistan tanto las API heredadas como las nuevas.

No entiendo por qué los Metaboxes tienen que hacer algo con Gutenberg en absoluto. Es solo una página de back-end, pantalla. Puede organizarse de cientos de formas.
Dijiste que la implementación actual rompe React.

Deje que los desarrolladores elijan si unirán su Metabox a Gutenberg o lo mantendrán afuera.
Todo este problema se debe a que asume que todos tendrán que hacer bloques de Gutenberg, de una forma u otra. ¿Y si no lo quieren, no lo necesitan?

Segundo gran problema para mí personalmente. Siempre luché con javascript, soy anti-talento para este idioma.
Ok, no todo gira a mi alrededor, pero solo para decir. No será más fácil agregar Metaboxes que antes.

Creo que @Rarst resumió el tema maravillosamente. La comunidad necesita una respuesta clara y parece que el equipo de desarrollo parece estar inclinado a seguir la dirección de la desaprobación, pero simplemente no puede deletrearlo claramente porque está tratando de encontrar una solución primero, lo que respeto completamente. No necesitamos que una comunidad entre en modo de pánico durante meses, pero al mismo tiempo, esa misma comunidad debe tener suficientes avisos y un camino despejado por delante. Honestamente, este es un compromiso difícil de encontrar.

@ fklein-lu Estoy totalmente en desacuerdo Fieldmanager debería ser la "herramienta de elección". Ni siquiera lo veo en la lista de complementos de los 10 campos principales.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

Como han dicho muchos otros, aunque entiendo el deseo de hacer de los metaboxes y Gutenberg una interfaz coherente y conectada, cambiar la forma en que funcionan los metaboxes introduce complejidades increíbles que pueden terminar como un gran impedimento para las personas. La historia nos ha demostrado que la introducción de importantes incompatibilidades entre versiones puede fragmentar en gran medida una comunidad.

¿Cómo se agregarían Metaboxes a la pantalla de backend del tablero?
No tiene nada que ver con Gutenberg.

@khromov Leer lo que realmente escribí, en lugar de citar mal mis palabras. Además, si leyera la publicación a la que hace referencia, sabrá por qué Fieldmanager no figura en la lista de los diez principales.

@ fklein-lu No estoy seguro de por qué crees que te estoy citando mal, aquí está el contexto completo: "Para los metaboxes, Fieldmanager es la herramienta de elección, debido a que está aprobada por VIP". No conozco a nadie que use Fieldmanager, así que me cuesta entender esa cita.

Soy consciente de que Fieldmanager no está en WPorg. Lo que estoy diciendo es que no tenemos datos de uso de él. Dudo mucho que rivalice con algunos de los mejores complementos, y también tiene muy poco soporte de la comunidad, aparte de los que lo usan para VIP, que es una minoría cada vez más pequeña de la cantidad total de desarrolladores.

En nuestra agencia creemos que en algún lugar de 3.x WordPress dio el paso de Blogging-System a Content Management System. En este momento podemos dar forma al contenido como el proyecto necesita que sea y usamos tipos de publicaciones personalizadas y metacuadros para crear una amplia variedad de contenido diferente, no solo texto.

Si el editor de bloques se vuelve obligatorio en 5.0, creemos firmemente que esto sería un paso atrás ideológico del CMS al sistema de blogs. Hay toneladas de aplicaciones empresariales que ejecutan WordPress como una solución de reserva de hotel, una plataforma de trabajo, un CMS sin cabeza para una aplicación, servicios de ubicación, etc., y muchos de esos casos de uso ni siquiera tienen el editor activado.

La compatibilidad total con versiones anteriores de la implementación actual de metabox es absolutamente imprescindible. Romper eso romperá la confianza con los clientes y usuarios en los próximos años. Mi solución favorita sería algo parecido al ´theme_supports´ y la usabilidad sin distracciones.

TL; DR: No espere que los clientes empresariales actualicen su código en los próximos 12 meses para otras cosas además del mantenimiento. Agregue una política / advertencia de desaprobación con un cronograma adecuado. Espere una gran caída en la confianza en WordPress, cuando fuerce un cambio (incluso para mejor) en términos de backend y usabilidad del código.

De alguna manera se convirtió en política, o votación / elecciones, no codificación. Algunas personas decidieron que las viejas Metaboxes son "viejas", "atrasadas", "limitantes", y no hay más lugar para ellas. Sin argumentos y razones reales en su contra. No los he visto, excepto que React y otros scripts son turbo-modernos.

Todavía te apoyo en la búsqueda de una solución para deshacerte de los viejos Metabox y hacerlo como imaginabas a la manera de Gutenberg. Pero parece que no tienes idea de cómo solucionarlo.

Es difícil discutir todo esto cuando todavía hay mucho agujero negro para mí. Y no soy el único.

Solo para indicar cuánto soy objetivo en este asunto, no intentaré:

• Sigo pensando que TinyMce y la pantalla de publicaciones antiguas (con Metaboxes) es algo más hermoso que he visto en el mundo de CMS. Funciones, filtros, expansiones y hermoso diseño. Sí, pura belleza y placer.
• A pesar de eso, acepté a Gutenberg desde el primer día. Sí, deshazte de todo esto "viejo", cambia y nunca mires atrás.

Sabían algo que yo no sé. Poseen código. Pero ya no estoy seguro.

En segundo lugar, lo olvidé, y es muy importante en este contexto. Ya se menciona aquí pocas veces.
Hago las cosas un poco diferente a los demás. La razón por la que acepté Gutenberg (uno de ellos de todos modos) desde el primer día es que, personalmente, no tendré ningún problema en convencer a las personas para las que hice sitios web para que usen Gutenberg. Es una gran sorpresa cuando les impones algo tan diferente a TinyMce.
Hago todas las actualizaciones de plugins y WP core para todos ellos de forma gratuita. Entonces, en este dilema cuando tienen que elegir entre Gutenberg y detener cualquier actualización por el resto del tiempo. Creo que su elección es obvia

Muchos otros desarrolladores, empresas, cobran por las actualizaciones. Entonces este dilema no será tan fácil.

@khromov Trabajo para Alley, que mantiene Fieldmanager. Estamos monitoreando activamente el hilo mientras se determina la dirección del producto. Sería justo decir que la base de usuarios de WordPress.org generalmente no usa Fieldmanager, pero el complemento tiene una amplia adopción como biblioteca y marco personalizado / empresarial.

También quiero hacer +1 en @Rarst y @kevinwhoffman. Mantener un soporte completo para las metaboxes existentes podría permitir un futuro en el que reemplacemos las metaboxes "heredadas" con equivalentes TBD Gutenberg. Pero la incertidumbre en este momento en torno a la compatibilidad con versiones anteriores debe mitigarse lo antes posible.

El número de instalaciones de complementos de WordPress.org no puede ser la única métrica para la inclusión o exclusión de un complemento o biblioteca. Conozco un sitio _single_ que usa Fieldmanager extensamente y atiende a cerca de 24 millones de visitantes únicos al mes.

Entonces, aunque solo un pequeño número de desarrolladores puede usar un complemento en particular, son responsables de desarrollar y mantener sitios que obtienen una cantidad desproporcionada de tráfico y mucha visibilidad.

Por tanto, no pueden quedar fuera de esta discusión. Considero que el equipo de Gutenberg en Automattic debería colaborar con el equipo VIP para conocer mejor estos casos de uso.

Estos proyectos empresariales se mueven a velocidades más lentas. Hay mucho trabajo para actualizar los metaboxes y otros elementos de la interfaz de usuario que no son un trabajo de codificación real. Ni siquiera hay suficientes desarrolladores empresariales para actualizar todos estos sitios en el plazo de 5.0.

Como señalaron otras personas en este hilo, es necesario que haya una ruta de actualización que tenga en cuenta este ritmo. Así, los cambios pueden ocurrir gradualmente, como parte del trabajo de mantenimiento proactivo.

@ fklein-lu vea arriba, estamos escuchando y siempre puede comunicarse si desea colaborar en el código.

En cuanto a VIP y el mercado empresarial, espero que haya más de unas pocas conversaciones sobre este tema en WordCamp for Publishers la próxima semana en Denver . Dicho esto, nos comunicamos con los desarrolladores de Gutenberg y @m, pero AFAIK ninguno podrá asistir.

Con respecto a la línea de tiempo "5.0", en este punto los ingenieros empresariales que entrevisté están asumiendo que habría una ruta de exclusión lo suficientemente fácil para usar el editor TinyMCE y los metaboxes existentes. Cree que el equipo de Gutenberg también ha dado the a esta suposición.

Y tengo un sitio web que usa Jetpack y solo tengo 2 visitantes únicos por día.
Deja de ofenderte tan fácilmente. Es WordPress, no una discusión sobre la nueva versión de Joomla. :)

@ fklein-lu Absolutamente de acuerdo contigo. Pero si algo fuera la "herramienta de elección" para los campos de metabox, creo que sería la API de Fields propuesta.

@davisshaver Creo que es lo más sabio. Si WordPress intenta reforzar el enfoque de obsolescencia sin compatibilidad con versiones anteriores, puedo ver fácilmente a alguien transfiriendo fragmentos antiguos del código a un sistema de publicaciones y metaboxes alternativos "paralelo" y basado en el legado y empaquetarlo como un complemento o algo así. Personalmente, eso es lo último que espero que suceda. Una vez más, definitivamente todo esto es un trabajo difícil de lograr, así que deseo buena suerte a todos los involucrados en llevar a la comunidad de WordPress a esta nueva tierra inexplorada.

Gracias a todos por participar aquí y expresar preocupaciones e ideas. Esto se está convirtiendo en un hilo largo, pero intentaré aclarar algunos puntos.

¿WordPress tiene la intención de desaprobar formalmente la API de Metabox?

No.

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

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

Sin embargo, hay varias formas en las que se pueden manejar las metacajas y la extensibilidad:

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

O cualquier combinación de estos.

Definitivamente agradeceríamos cualquier ayuda de la comunidad para construir la mejor solución aquí ya que, nuevamente, la falta de certeza no es una falta de voluntad; sólo que las posibles soluciones deben explorarse en la práctica y las compensaciones (diseño y desarrollo) claramente escritas.

No.

Gracias , creo que mucha gente simplemente exhaló.

La pregunta que aún no está completamente respondida es cómo funcionan las metacajas en el contexto del editor de Gutenberg.

¿Por qué _son_ metacajas en el contexto del editor de Gutenberg?

La respuesta parece ser que Gutenberg tiene como objetivo reemplazar la pantalla completa del editor de publicaciones con una implementación impulsada por JS. No había seguido el desarrollo para estar al tanto de las razones de eso.

Pero sigo pensando que fue un punto muy válido planteado: si el alcance de Gutenberg va a ser un componente de editor, reemplazar el alcance de _screen_ parece demasiado ambicioso. _Si_ el alcance de Gutenberg es (al menos parcial) el reemplazo de WordPress _admin_ como un todo, es _increíblemente_ un alcance más amplio y exigente. No es que reemplazar el editor "solo" sea fácil.

Sin embargo, hay varias formas en las que se pueden manejar las metacajas y la extensibilidad

¿Gutenberg está diseñado para reemplazar el componente principal _editor_ y la interfaz de usuario de administración existente sigue funcionando? ¿Se está considerando esto, si no por qué?

Solo puedo hablar por el complemento de administrador de campo que construí y que actualmente usamos en más de 60 proyectos diferentes en este momento. Mencionaré brevemente lo que este cambio parece significar para él con la esperanza de que pueda ayudar a cualquiera a pensar en su propio escenario.

Debido a que me tomé la molestia de construir una arquitectura altamente desacoplada con clases e interfaces abstractas comunes, todo lo que tendré que hacer es agregar una nueva "ubicación". Aquí están los componentes de la arquitectura que son relevantes para mi punto:

• Ubicación: donde se adjunta el grupo de campo (por ejemplo, publicación, página, término de taxonomía, etc.), con una variante para cada ubicación (por ejemplo, la ubicación de Publicación y Configuración funciona con metacajas). Esta clase instancia todas las partes móviles mencionadas a continuación
• Almacén de datos de ubicación: la capa que es responsable de recuperar y conservar los datos, con una variante para cada ubicación (por ejemplo, la publicación DataStore funciona con la meta de la publicación, la configuración funciona con las opciones, etc.)
• Vista de ubicación: cuando es necesario, como es el caso de la página de configuración, es una clase de vista que contiene la plantilla y las funciones auxiliares

Ahora, en el contexto de Gutenberg, si debo apoyar a este nuevo editor, todo lo que tendré que hacer personalmente es agregar una nueva ubicación, llamada Gutenberg, y esta ubicación tendrá:

• Su propio método de inicialización que lo conectará al editor de Gutenberg. Imagino que esto se basará principalmente en JavaScript, por lo que mi biblioteca se registrará y cargará los scripts comunes necesarios para este propósito.

• Su propia vista / plantilla: tendré que crear un componente de reacción para cada tipo de campo. Esto no es gran cosa, la capa de vista es bastante sencilla de hacer cuando todas las demás piezas están configuradas correctamente. Estos componentes luego se anidarán en el componente de reacción de metabox. Todo esto es muy similar a lo que ya hago para los metaboxes html basados ​​en php, es decir, campos html> grupo de campos html> ubicación (página de configuración html, metabox, etc.)

• Su propia clase de almacén de datos. No imagino que esta clase será muy diferente del almacén de datos de ubicación de la publicación, ya que se basará en la meta de la publicación (me imagino que nadie está pensando en desaprobar la meta de la publicación pronto).

• Pieza nueva: los puntos finales. Estos nuevos componentes basados ​​en reacciones deberán poder comunicarse con el almacén de datos para recuperar y conservar valores. Como estos viven completamente en el lado del cliente, necesitarán puntos finales como un puente para hablar con el almacén de datos de ubicación, con el meta almacén para recuperar los componentes que se cargarán en cualquier contexto, etc.

Si no me falta nada importante (admito que aún no he tenido tiempo de revisar a Gutenberg), esto es más o menos la esencia de lo que creo que tendría que hacer para admitir de forma nativa esta nueva "ubicación". También tengo comprobaciones integradas para cada ubicación y sus filtros para asegurarme de que lo que pregunta el desarrollador sea posible, por ejemplo, si intento agregar un grupo de campo a un tipo de publicación de "proyectos" donde el formato si el tipo de publicación es "video ", pero que CPT no admite formatos de publicación, la biblioteca generará una excepción. Espero poder proporcionar los mismos comentarios con esta nueva ubicación, por ejemplo, si agrego un grupo de campo a una ubicación de Gutenberg donde el tipo de publicación es "reseñas", espero poder saber si ese tipo de publicación se registró para apoyar a Gutenberg.

Esto terminó siendo un poco más largo de lo que había anticipado, mi mal. Me encantaría recibir noticias de cualquier persona involucrada en el desarrollo de Gutenberg o de cualquier autor de bibliotecas con inquietudes similares que tengan comentarios para compartir.

Gracias.

¿Gutenberg está diseñado para reemplazar el componente principal del editor y la interfaz de usuario de administración existente sigue funcionando? ¿Se está considerando esto, si no por qué?

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

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

Aún no hemos terminado y no es fácil, pero estamos trabajando en ello todos los días.

☝️ He actualizado el título y la descripción del ticket para, con suerte, abordar algunos conceptos erróneos.

El nuevo editor de Gutenberg y el futuro de ButterBean

Como se solicitó en el comentario anterior , estoy enumerando el marco de metabox de ButterBean. Puedo crear un nuevo ticket si es necesario.

Repo: https://github.com/justintadlock/butterbean/tree/dev

Para fines de prueba, el marco se incluye en este complemento: https://github.com/justintadlock/custom-content-portfolio

ButterBean es un marco integrado creado con Backbone.js y Underscore.js. Está modelado en gran medida a partir del personalizador en el núcleo de WP.

Es un marco joven, pero he estado planeando implementar varios complementos este año. En este momento, otros y yo dudamos en hacer esto debido a la dirección de Gutenberg. Y, ni siquiera estoy seguro de si no debería comenzar de cero en React o cualquier marco JS que finalmente se decida agregar al núcleo de WP a continuación.

Ganchos utilizados

Los siguientes son los ganchos principales de WP utilizados (bastante estándar para la mayoría de los marcos de metabox, me imagino):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Creado # 2265 para documentar los ganchos relevantes para CMB2.

Se agregó una etiqueta de diseño para alentar a las personas a agregar maquetas adicionales.

En general, creo que los datos que no forman parte del contenido que se muestra no deberían formar parte del área principal del editor. No todo es un bloque.

1) La mayoría de mis metaboxes personalizados están hechos con Fieldmanager . En mi opinión, estos deberían "simplemente funcionar" sin necesidad de trabajo adicional por mi parte además de la actualización. cc / @mboynes y @bcampeau, ya que pueden aportar valor a esta discusión.

2) Algunas de nuestras cajas meta personalizadas son una mezcla de jQuery y PHP. Por ejemplo, tenemos un cuadro meta "Uno o ninguno" que es una radio con un botón "borrar". Suponiendo que esto se rompa, esperaría que hubiera ejemplos de cómo creo esto en Gutenberg y que habría una cantidad significativa de tiempo para actualizar a una versión de WordPress que exija a Gutenberg antes de que mi código se rompa.

3) Tengo otro metabox que combina algo de jQuery y código PHP que deshabilita el botón de publicar hasta que se haya realizado una selección. De manera similar a mi segundo ejemplo, suponiendo que esto se rompa, esperaría que hubiera ejemplos de cómo creo esto en Gutenberg y que habría una cantidad significativa de tiempo para actualizar a una versión de WordPress que exige a Gutenberg antes mi código se rompe.

4) Eliminé el cuadro de meta de categoría en el pasado y lo reemplacé con: 1) una selección de radio 2) Una versión sin la capacidad de agregar nuevas categorías (esto fue tonto).

5) He usado post_submitbox_misc_actions para agregar opciones al metabox de publicación que no necesitan estar en su propio metabox.

En cuanto a lo que quiero decir con una cantidad significativa de tiempo, diría ~ 2 años desde el momento en que la API de Gutenberg está congelada.

Mientras estamos en eso, me gustaría recordarles a todos aquí que no todos usan solo metaboxes para extender la pantalla de publicación. Algunos de nosotros también usamos los siguientes ganchos:

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

Solo quiero respaldar lo que dijo ganchos de edit_form_[POSITION] . Piklist hace un uso intensivo de metacajas, flujos de trabajo y otras cosas.

Gracias de nuevo por su tiempo chicos.

La pregunta de si Gutenberg es un reemplazo de editor o un reemplazo de pantalla es importante para responder lo antes posible, no solo para aquellos preocupados por la compatibilidad con versiones anteriores, sino también para aquellos que desarrollan Gutenberg. La respuesta a esa pregunta afecta muchas de las decisiones que se toman todos los días sobre cómo funciona Gutenberg y dónde se ubican los controles.

Está claro desde la primera versión beta que ya estamos en el camino hacia un reemplazo de pantalla, pero esa decisión de revisar la pantalla también es lo que creó los problemas de compatibilidad con metabox y ganchos faltantes. Si la respuesta a estos problemas es "no reemplace toda la pantalla", entonces me preocupa que ya se haya realizado tanto trabajo bajo el supuesto de reemplazo de pantalla que sería difícil volver atrás.

En primer lugar, es genial ver un progreso real en esto.

Una observación es que las extensiones de la pantalla de edición rara vez funcionan de forma aislada. Por ejemplo, ACF cambia los campos visibles según los eventos de cambio de JS en el cuadro de selección principal de la publicación.

Dado que el DOM será diferente en un contexto de Gutenburg, y que React probablemente sea menos adecuado para los oyentes de eventos externos, ¿cómo continuamos haciendo que estos datos estén disponibles para metaboxes y otros códigos de complementos? Una posibilidad es que la tienda Redux esté disponible para los metaboxes, pero no sé si esto es posible, deseado o da suficiente flexibilidad.

Esto se vuelve aún más problemático cuando los metaboxes se cargan en un iframe o se ajax en la página.

Está claro desde la primera versión beta que ya estamos en el camino hacia un reemplazo de pantalla, pero esa decisión de revisar la pantalla también es lo que creó los problemas de compatibilidad con metabox y ganchos faltantes. Si la respuesta a estos problemas es "no reemplace toda la pantalla", entonces me preocupa que ya se haya realizado tanto trabajo bajo el supuesto de reemplazo de pantalla que sería difícil volver atrás.

Entiendo completamente cuánto trabajo se ha realizado para el enfoque de reemplazo de "pantalla". Pero un proyecto que comenzó con el objetivo de un reemplazo del "editor de contenido de publicaciones", ¿no debería haber regresado a la comunidad antes de decidir unilateralmente que reemplazaría toda la pantalla del editor?

No quiero descartar el enorme trabajo que se ha realizado (el editor realmente se ve increíble), pero demasiado WordPress se basa en metacampos que no son estrictamente "contenido", y muchos de ellos no encajan en absoluto dentro del mismo contenedor de Gutenberg (a menos que esté completamente forzado). Para mí, parece más como "tenemos una solución y necesitamos crearle un problema" que al revés, que fue la declaración original de Gutenberg (el editor de contenido de la publicación es bastante complicado, los códigos cortos son todo menos fáciles de usar - a pesar de enfoques como Shortcake -, etc.).

La maqueta de

@rilwis Creo que debería

Para inspirarse en el diseño, puede consultar los temas de administración de backend gratuitos y comerciales (capturas de pantalla). O cualquier otra plataforma.

Tablero, pero imagina a Gutenberg:

Quizás la API de Fields propuesta resuelva algunos de los problemas relacionados con el soporte de metaboxes en el nuevo editor

El escenario que deberíamos considerar es lo que sucede cuando WordPress se actualiza con Gutenberg y los complementos que implementaron los meta boxes no .

Este es el "peor escenario" que representa la mayor amenaza para romper la experiencia de administración, pero no será infrecuente dada la cantidad de sitios que funcionan con complementos de metabox, incluidos los reproductores de renombre y las soluciones únicas personalizadas.

Confiar en la actualización de estos complementos de metabox no debería ser parte de la ecuación a menos que estemos dispuestos a reconocer cambios importantes a gran escala. La API de Fields es una gran idea, pero no debemos asumir que mejorar la forma en que se manejan los campos personalizados en el futuro tendrá algún impacto en el código que se escribió antes de que existiera dicha API.

Está claro que:

• No vamos a romper la compatibilidad con versiones anteriores a gran escala.
• No vamos a bifurcar la página del editor usando algún mecanismo de detección.
• Tendremos un solo editor y experiencia de edición.
• Hay muchos casos de uso anteriores que la implementación actual de Gutenberg no puede acomodar.

Por lo tanto:

El camino a seguir es repensar la pantalla de edición de publicaciones de una manera que adopte lo nuevo y lo antiguo. Es muy probable que eso signifique retroceder en la implementación actual de Gutenberg de alguna manera. Es un desafío de diseño, no el fin del mundo.

@dmccan No, esas declaraciones tampoco son "claras" como todas las soluciones propuestas hasta ahora:

• Divide la experiencia de administración entre nueva / antigua.
• Depende de las actualizaciones de complementos para bloquear sus metacajas.
• Se basa en una API de Fields inexistente.
• Requiere que se cancele el registro de la nueva interfaz para evitar el problema por completo, lo que nuevamente dividiría la experiencia de administración.

No enfaticé que el peor de los casos es melodramático; Lo hice para definir las limitaciones dentro de las cuales deberíamos abordar el problema.

Por lo tanto, parece que Gutenberg probablemente debería seguir siendo un complemento de funciones durante mucho tiempo, uno que las personas pueden elegir para seleccionar si lo desean o optar por no participar, posiblemente incluso para incluirse como un complemento con núcleo.

Resolver todos los problemas que necesita resolver para tener la experiencia de un solo editor llevará mucho tiempo. Solo mire el ASP.NET original de Microsoft y cuán mal resolvió el problema general de la web. Finalmente, surgió AJAX y el resto es historia.

Forzar un cambio demasiado rápido podría hacer que WordPress se convierta en una verdadera plataforma heredada.

PD: El requisito de "editor único" parece poco realista. Si los usuarios tuvieran la opción de usar lo antiguo o lo nuevo, entonces se podría permitir que lo nuevo evolucionara con el tiempo hasta que ya no hubiera ningún beneficio de usar lo antiguo. Pero mientras haya instalaciones que utilicen los ganchos existentes _ (creo) _ es irresponsable optar por una única solución de editor. #jmtcw

@kevinwhoffman - Creo que estamos de acuerdo, pero tal vez no fui lo suficientemente detallado.

Creo que mis puntos son claros y la solución final los abarcará. Por ejemplo, no creo que WordPress rompa la compatibilidad con versiones anteriores a gran escala, a pesar de lo que las personas que buscan soluciones puedan proponer en este momento.

Faltan las soluciones propuestas hasta ahora, de ahí mi conclusión, que tenemos que repensar la implementación actual de Gutenberg para abarcar tanto lo nuevo como lo antiguo. Creo que hacerlo es realmente la única forma de avanzar.

@mikeschinkel - No imagino que Gutenberg será la única opción de editor en Core en 2017. Bien podría ser que comience como una elección del usuario y evolucione hasta el punto de cubrir todas las bases esenciales, o que tome la es hora de hacerlo bien.

En cualquier caso, lo que estoy sugiriendo es un retroceso para incorporar a Gutenberg en alguna versión mejorada de la pantalla del editor actual, en lugar de descartar todo y luego preguntarnos cómo podríamos manejar todas las funciones esenciales. Creo que es factible y posiblemente no sea un gran retroceso, una vez que la gente lo acepte. Es probable que dicho curso sea más rápido y proporcione una mejor experiencia al usuario final.

Quizás ellos (codificadores centrales) deberían hablar con Matt. Él comenzó todo esto y ahora no tienen respuestas.

@dmccan Una cosa que creo que será de vital importancia es que todo lo que se implemente tiene un modelo de fácil extensibilidad. WordPress es conocido por su modelo de fácil extensibilidad con acción de complemento y ganchos de filtro y sin eso, Gutenberg será tan malo para WordPress como el sistema de administración de medios actual que es muy difícil de extender.

Como nota al margen, aunque nunca he usado React o Vue _ (soy un desarrollador de PHP) _ la discusión sobre React requiere un sistema de compilación y que muchas personas encontraron Vue mucho más fácil de usar que React me ha hecho sentir muy ansioso por si Gutenburg tendrá un modelo de extensibilidad fácil de aprender y usar o no, y si significará o no que podemos continuar usando WordPress para proyectos de clientes.

Solo mis comentarios para señalar mi inquietud, no es necesario responder directamente a esto.

Creo que sé de qué se trata todo esto.
Nunca se trató de un editor de contenido, nunca de "escribir fluir", "romper con lo antiguo ... retroceder", etc.

Se trata de un editor de temas visuales de front-end de pura sangre.

Perdón por enviarles correos electrónicos a todos ustedes. Mi último comentario sobre este tema en particular.

@Rarst @kevinwhoffman : Estoy totalmente de acuerdo contigo sobre si Gutenberg es o no un reemplazo de editor o reemplazo de pantalla . Es un punto bien pensado. Y espero que el equipo de desarrollo pueda volver al punto de partida y la naturaleza de Gutenberg, un editor, y mantener todo lo demás como está ahora. Son 2 partes diferentes y se pueden usar juntas o sin la otra. Así que es mejor mantenerlos separados.

Además, creé # 2308 para enumerar los ganchos relevantes del complemento Meta Box.

@ahmadawais Gracias por la mención.

@nylen Valdría la pena agregar Publicaciones 2 Publicaciones a la lista de complementos a considerar. Aunque ya no es compatible, espero que todavía se use bastante.

@nylen Mantengo los campos personalizados de mi , pero ya no está desarrollado activamente (uso CMB2 en estos días). Solo más de 1000 instalaciones activas, pero tal vez valga la pena agregarlas a la lista.

Estoy de acuerdo con los comentarios acerca de que Gutenberg Editor es solo eso, la parte de edición de contenido. No estoy seguro de por qué o cómo se desvió para convertirse en un reemplazo de pantalla completo. Todos los creadores de páginas populares lo hacen bien, simplemente reemplace TinyMCE con algo más que facilite la composición de contenido.

Además, las metacajas normalmente no forman parte del contenido, e incluso si están relacionadas con el contenido, por lo general no tienen sentido ser un bloqueo.

Tome un directorio de personal, por ejemplo. ¿Por qué querría que los campos para la información de las personas fueran un bloque? No es como si quisiera que agreguen otros bloques cuando se supone que deben ingresar el nombre, apellido, etc.

tldr; Gutenberg solo debería reemplazar el editor TinyMCE para los tipos de publicaciones que necesitan composición de contenido.

Solo agrego mis dos centavos aquí.

¿Por qué no dejarlo como está ahora? Lo que quiero decir es esto.

• Mantenga las dos opciones de edición al pasar el mouse sobre el título de la publicación como está ahora, pero cámbielo para que, de manera predeterminada, haga clic en el título para acceder a Gutenberg. Luego haga que el enlace Edit vaya a Gutenberg y tenga un enlace adicional para ir a la pantalla de edición de clases. Tal vez lo llame algo como Classic Edit .
• Agregue algún tipo de indicador de soporte para el tipo de publicación Publicación y página, de modo que Gutenberg pueda deshabilitarse si un desarrollador quiere hacer eso. Si Gutenberg no está habilitado, haga que el enlace del título vaya a la página de edición "clásica", elimine el enlace Edit a Gutenberg y el texto del enlace Classic Edit cambiará a Edit
• Luego, con los tipos de publicaciones personalizados, tenga soporte para Gutenberg como para el Editor, Imagen destacada, etc. De esa manera, un CPT no tiene que ser compatible con Gutenberg.
• Luego actualice el estilo de las páginas de edición clásicas. Se actualizaron las meta cajas y los estilos de la barra lateral para que coincidan con el estilo de Gutenberg Incluso mueva los meta recuadros de extractos y comentarios a las barras laterales como en Gutenberg.

Creo que esto haría felices a todos. Gutenberg estaría activado de forma predeterminada para los tipos de publicaciones Publicación y Página. Si los desarrolladores necesitan usar metaboxes en lugar de Gutengerg, pueden hacerlo. Les daría tiempo a los desarrolladores de complementos y temas para convertirse a Gutenberg y les daría a los usuarios finales la capacidad de adaptarse a Gutenberg sin interferir con su flujo de trabajo por el cambio de editor.

Y dará tiempo a los desarrolladores para comenzar a vender la idea de usar Gutenberg a los usuarios finales. A la gente no le gusta el cambio. Dejar que se acostumbren al nuevo editor sería mucho mejor que un cambio duro.

Esto también separaría los dos lo que permitiría los dos métodos de ahorro diferentes. Gutenberg puede usar JS y el clásico puede seguir usando PHP.

Agregaría algún tipo de advertencia, como si un usuario guardara una publicación con Gutenberg y luego intentara editarla con Classic para hacerles saber que si guardan la publicación, anulará el guardado anterior de la publicación desde el otro editor. Podría haber algo como un meta de publicación para indicar qué editor se usó por última vez.

Es una idea. Puede ser una idea estúpida, pero creo que aliviaría todas las preocupaciones que tienen muchos desarrolladores.

Estoy totalmente de acuerdo con los puntos que muchas personas han planteado sobre el alcance de Gutenberg hoy. Este proyecto comenzó como una mejora (muy necesaria) para el editor de contenido. Al leer este hilo, no puedo evitar sentir que estamos creando problemas que no necesitan existir . Si nos atenemos al plan original de agregar Gutenberg al editor (sin reemplazar la pantalla completa), esto resuelve muchos problemas, no solo con respecto a las Meta Box.

Al renovar completamente la pantalla, me temo que esto causará muchos problemas a los editores de contenido que no son expertos en tecnología. El blogger / autor promedio verá una pantalla completamente diferente y entrará en pánico. Si la actualización simplemente se dirige al editor, la experiencia de incorporación puede controlarse mucho más.

Otra forma de abordar esto podría ser utilizar el mismo flujo de trabajo que Beaver Builder . Es decir, mantenga la página de edición de publicaciones normal (con las secciones habituales de Meta Box, etc.), luego Gutenberg podría iniciarse mediante un botón. Esto puede llevarlo a una nueva pantalla. Al igual que los comentarios sobre el objetivo del modo de escritura sin distracciones.

También estoy de acuerdo con las personas que sugieren mantener la interfaz de usuario del metabox existente y cambiar solo el editor de contenido.

Creo que la mayoría de nosotros reconocemos que el factor principal para impulsar una plataforma es innovar. Es evidente que WordPress está tratando de avanzar lentamente hacia un enfoque basado en JS para experiencias más ricas que puedan igualar (¡y superar!) Lo que todos los demás están haciendo. Si somos honestos, todo el sistema de metaboxes y la interfaz de usuario de la pantalla de edición actual pueden parecer algo anticuados, pero como desarrolladores estamos tan acostumbrados que es algo natural para nosotros y no tomamos en cuenta la curva de aprendizaje que hay. es a eso.

Leer todo este hilo me aclara dos cosas:

• Es obvio que el equipo central quiere impulsar una pantalla de edición totalmente basada en js, y en mi humilde opinión, está bien
• Quizás si todos podemos aceptar el punto anterior, podemos mover la conversación hacia el soporte heredado y las estrategias de migración a seguir.

Tan pronto como entendamos cómo funcionará la versión js de las metaboxes (¿hay una API propuesta?), Podremos empezar a pensar en cómo crear un puente que haga que nuestra tecnología existente (complementos, administradores de campos, etc.) trabajar con este nuevo enfoque.

Si ya está ocurriendo una discusión centrada en la API, ¿podría alguien señalarme a mí y a cualquier otra persona que no sepa dónde está sucediendo en la dirección correcta? ¡Gracias!

¿Hay alguna razón para no dividir el editor en dos pantallas navegadas a través de pestañas?

Mi opinión es que Gutenberg es,

• Un intento de ordenar la pantalla del editor.
• Un intento de agregar la funcionalidad de creación / diseño de páginas al núcleo
• Un intento de minimizar la necesidad de metaboxes facilitando a los desarrolladores la creación de nuevos bloques de contenido.

El problema, como se destacó anteriormente y como la mayoría de los desarrolladores y usuarios finales podemos sentir y prever, es que Gutenberg,

• Elimina las opciones de formato de estilo del editor de los autores
• Obliga a los autores a utilizar un flujo de trabajo no intuitivo que requiere muchos clics del mouse para agregar bloques
• Rompe muchos complementos antiguos, algunos de los cuales se mantienen y otros no.
• Convierte WordPress en lo que se siente como una plataforma de Tweet.

Usar Guttenberg para crear contenido tiene la misma incomodidad que diseñar una plantilla de correo electrónico en Mautic o MailChimp. La interfaz de usuario de Guttenberg funcionaría bien para el diseño de plantillas, pero no para la creación de publicaciones de formato largo.

Deberíamos concentrarnos en aumentar la fluidez del flujo de trabajo, no en la introducción de una interfaz de usuario de creación de contenido de inicio y fin.

La interfaz de usuario de Guttenberg se ve muy bien, pero no es realista esperar que los usuarios finales estén contentos con ella mientras está cerca de su forma actual. Se interpone en el camino de la creación de contenido.

El bloque de texto es casi inútil. Un widget de texto no debe limitar a los autores al uso de unos pocos formatos de fuente. Esto molestará a muchos autores.

Aquí están mis sugerencias:

• Introduzca Tabify Edit Screens en el editor de páginas.
• Mueva los metaboxes a su propia pestaña de página dentro de la pantalla del editor.
• Use una página no basada en React para los metaboxes (página oculta detrás de una pestaña del editor)
• Use un lienzo basado en TinyMCE predeterminado (o un editor rico en funciones similares) que funcione bien para formato largo y que no insista en que los autores usen bloques.
• Introduzca Guttenberg Blocks como un complemento de TinyMCE o el aspecto de TinyMCE.
• Presente Shortcake al editor basado en TinyMCE de manera que los autores puedan ver visualmente el contenido de los bloques y que los autores puedan editar el contenido directamente en el flujo de la página sin necesidad de hacer clic en un botón de edición para cada bloque.
• Facilite a los desarrolladores la adición de nuevos bloques a Guttenberg vinculando add_shortcode () en la creación de bloques, por ejemplo, add_shortcode ('etiqueta', 'función', 'guttenberg verdadero / falso'). Adapte add_shortcode para que automáticamente haga que el shortcode sea compatible con Guttenberg; esto permitirá a los desarrolladores convertir fácilmente algunos / muchos de sus metaboxes en códigos cortos que funcionan dentro de Guttenberg.

Lo que realmente estoy diciendo es que Guttenberg debe dividirse en 3 tareas:

• Limpieza de la pantalla del editor
• Interfaz de usuario mejorada del editor
• Marco de extensión de editor mejorado.

Yo diría que la mayoría de la gente usa WordPress para crear contenido de formato largo y no desea verse obligada a usar bloques para crear su contenido. Los bloques son excelentes para la creación de diseños de página, pero son molestos cuando se usan cada vez que se escribe una publicación.

Tengo una clienta que tiene más de 80 años. Ella solo quiere crear contenido. No quiere verse obligada a volver a aprender a utilizar la pantalla del editor. Le ha llevado más de un año acostumbrarse a Visual Composer y es un creador de páginas fácil de usar.

Me he apartado del tema del hilo original, pero hay que decir esto: Guttenberg matará a WordPress.

Si se introduce Guttenberg en su forma actual, WordPress se bifurcará y la versión de Guttenberg morirá.

Quizás el nuevo editor tenga más sentido si usa WordPress para un sitio de blogs y crea un tema PHP para él, pero hoy en día mucha gente usa WordPress como un CMS para construir aplicaciones web usando React, PODS / ACF y la API REST de WordPress. De ahí la necesidad de admitir metaboxes y campos de relación para enlaces avanzados entre CPT.

En primer lugar, creo que Gutenberg va a ser increíble.

Dicho esto, creo que todos podemos estar de acuerdo en que romper sitios web / funcionalidad rompe la confianza, y eso no está bien. Todos queremos poder confiar unos en otros, y nuestros clientes / clientes quieren / necesitan confiar en nosotros.

Creo que lo mejor que podemos hacer es incluir un filtro que los desarrolladores puedan usar para volver a la pantalla del editor "heredado".

De esta manera, podemos aplicar nuestra propia lógica para determinar si estamos listos para Gutenberg o no. Si un usuario está utilizando un metabox que se romperá por completo en Gutenberg, podemos optar por volver al modo heredado.

Luego, podemos trabajar a nuestro propio ritmo para migrar nuestras metacajas o ideas para que encajen con Gutenberg, mientras mantenemos las publicaciones antiguas que dependen de nuestras metacajas "heredadas" funcionando como deberían.

¿Por qué las metaboxes heredadas no se pueden renderizar en las ubicaciones (contexto) para las que están registradas y seguir funcionando como lo hacen actualmente?

Por lo tanto, primero renderice la sección del editor de Gutenberg (opcional), seguida de cualquier cuadro meta de contexto normal / avanzado registrado (heredado) (con su título registrado), luego la barra lateral con la nueva columna Configuración de publicación y debajo de ese lado registrado (heredado) cuadro de meta de contexto (con su título registrado).

Por supuesto, el metabox heredado tendría el mismo estilo que el nuevo cuadro de Configuración de publicación, todo se vería bien integrado.

Tal vez requiera un script legacy-meta-box.php que se cargaría cuando fuera necesario, por ejemplo, cuando se llama a add_meta_box.

Si solo pensamos en las soluciones de metabox actuales como "heredadas" y les pedimos que utilicen el editor anterior sin pensar en las razones para usarlas en primer lugar y luego trabajar en mejores formas de proporcionar esa funcionalidad en el nuevo editor, entonces los sitios actuales simplemente permanecerán heredados y nunca se actualizarán. Este será un gran problema para los usuarios que administran los sitios de los clientes.

La razón por la que usamos los campos ACF en casi todos nuestros proyectos es para controlar los datos para que se muestren de manera consistente en el sitio web. Aquí hay dos ejemplos en los que estamos trabajando actualmente; Un gran sitio de eventos y un festival con obras / instalaciones que deben estar vinculadas a los artistas, pero que se muestran por separado. En ambos casos, el "contenido", la pieza que Gutenberg está reemplazando es sólo alrededor del 10% del contenido en la pantalla de edición y es en realidad la pieza menos importante. Para el sitio de eventos, los datos importantes son Tipo de evento, Categoría de evento, fecha, hora, ubicación, organizador, etc. Puede publicar una entrada de evento significativa sin ingresar ningún contenido en el editor. Para el sitio del festival, necesitamos poder seleccionar un artista y vincularlo a una obra, seleccionar la ubicación de las obras en el sitio del festival y cargar una imagen destacada, nuevamente el contenido es un extra, no una necesidad. Para todo el contenido de la página "normal" en estos sitios, Gutenberg no es lo suficientemente flexible (y no debería serlo por defecto, no creo) y continuaríamos usando un creador de páginas con más funciones (Beaver Builder) para mejorar opciones de diseño.

El otro factor clave en todo esto es el orden del contenido en la pantalla de edición. Para un evento, debe establecer un título, pero luego, en un flujo de edición ideal, desea que se ingrese parte de la información clave como fecha, hora, etc. ANTES de ingresar cualquier "contenido" en el "editor". Tenemos que tener la capacidad de controlar en qué parte de la página de edición está el contenido, antes o después del "contenido".

La idea de simplemente crear otra pestaña con todas las metacajas "heredadas" sería horrible. Rompería el flujo de edición por completo para muchos usos de los CPT, ocultando el contenido a los usuarios de una manera que creo que les resultaría muy difícil de descubrir.

El proyecto debe ser MUCHO más inteligente al respecto. Un proceso con pestañas podría funcionar muy bien si pudiera elegir (en algún tipo de plantilla de página) qué bits estaban en qué pestaña. También necesitaría un mecanismo para guiar al usuario a través de cada pestaña. Sin embargo, también creo que para elementos CPT más cortos TIENE que tener la capacidad de mantenerlo todo en una página con ciertos elementos clave sobre el contenido del editor (bloques obligatorios si lo desea).

En general, la mayoría de las soluciones de las que habla la gente no parecen tener la flexibilidad de la pantalla de edición actual.

Es por eso que estoy asustado por la línea de tiempo de 5.0 para esto, parece que podría ser genial con el tiempo, pero si se apresura, la fragmentación destruirá toda la buena voluntad tanto de los desarrolladores como de los clientes. WordPress se basa en su flexibilidad, compatibilidad con versiones anteriores y facilidad de uso general. No podemos sacrificar eso por el nuevo juguete brillante. Mire los requisitos de PHP para WordPress, estamos hablando literalmente años antes de que PHP 5.6 o 7 sea un requisito. La comunidad ha reconocido que no importa cuán frustrante sea ese largo período de tiempo, es necesario no romper los sitios web. ¿No es este EXACTAMENTE el mismo tipo de problema?

Cambios como este, aunque en última instancia serán excelentes para la plataforma, deben estar bien pensados ​​y administrados o ponen en riesgo la base misma sobre la que se basa WordPress.

@avocadesign - Algunos buenos puntos. Podremos registrar metacajas de JavaScript en el futuro, aunque parece que el pensamiento actual es tener dos ubicaciones ... lo cual no es tan flexible como ha mencionado.

@avocadesign - bien explicado. El post_content no siempre es el foco de una publicación y sus 'eventos y artistas' son un buen ejemplo. Sería genial ver algunas capturas de pantalla que muestran el back-end y el front-end de estos tipos de publicaciones para que podamos ayudar a los desarrolladores a visualizar cómo se usa WP como CMS y cómo funciona un cliente típico a través de una pantalla de edición posterior.

@avocadesign

Si solo pensamos en las soluciones actuales de metabox como "heredadas" y les pedimos que utilicen el editor anterior

En lo que sugerí (arriba de su comentario), las metacajas 'heredadas' se colocan debajo del editor de Gutenberg (si el tipo de publicación lo necesita) o debajo del bloque Configuración de publicación (según el contexto para el que están registrados). No veo ningún requisito para mantener al antiguo editor.

Estoy de acuerdo en que una interfaz con pestañas no funcionaría. ¿Qué opinas de mi sugerencia? A mi modo de ver, le daría toda la flexibilidad a la que está acostumbrado y le permitiría pasar al nuevo sistema cuando esté listo.

Si Gutenberg se convirtiera en parte del núcleo, podría crear una interfaz de usuario aún mejor para las muestras que menciona. En parte, consistiría en un bloque de Festival personalizado (una especie de formulario WYSIWYG) y configuraciones relacionadas en una o más secciones de Configuración de publicación (basadas en JS). El usuario se beneficiaría de una interfaz más rápida con comentarios directos.

WordPress se basa en su flexibilidad, compatibilidad con versiones anteriores y facilidad de uso general. No podemos sacrificar eso por el nuevo juguete brillante.

Estoy en desacuerdo. Creo que deberías darle un poco más de crédito al Gutenberg. Están trabajando arduamente en una solución que funcione para todos. Están escuchando y buscando casos de uso (como el que mencionaste) Todavía no hay nada escrito en piedra, ni el lanzamiento del que Gutenberg 'podría' ser parte.
Si Gutenberg no aborda todos los problemas que se están debatiendo actualmente, puede confiar en que no formará parte de la versión 5.0. Hemos visto que eso sucedió en el pasado en numerosas ocasiones con otras características también.

A continuación, se muestra un ejemplo de una interfaz que construí con Campos personalizados avanzados para un cliente que administra propiedades de hotel.

• El tipo de publicación personalizada Propiedad utiliza 18 campos personalizados en 10 pestañas.
• Las pestañas mantienen toda la información pertinente en una pantalla y el editor puede acceder a ella con solo hacer clic en un botón.
• Los tipos de campo incluyen campos de texto y números simples, además de galerías ACF y campos de relación.
• La compatibilidad con editor no se declaró en el registro del tipo de publicación personalizada, lo que significa que toda la interfaz de usuario se basa en metacajas personalizadas.

Este tipo de interfaz de usuario es representativo de muchos sitios personalizados de WordPress donde una serie de campos personalizados contienen una combinación de contenido en la página y metadatos "invisibles" que se utilizan para organizar publicaciones.

La comunidad necesita saber qué sucede con este tipo de interfaz una vez que se introduce Gutenberg, y no creo que pedirle a @elliotcondon que migre todo a React a tiempo para el lanzamiento sea una expectativa realista.

@kevinwhoffman

La comunidad necesita saber qué sucede con este tipo de interfaz una vez que se introduce Gutenberg

Tiene razón, pero el objetivo de este número 952 es _encontrar_ esa respuesta discutiendo y sugiriendo alternativas. Qué funcionaría qué no. En algún momento en el futuro, cuando todos piensen que todos llegamos a algo que funcionaría en todos los casos heredados y futuros, solo entonces se puede implementar y se puede explicar a la comunidad (de usuarios) cómo funcionará. Actualmente, es demasiado pronto para esperar una respuesta del equipo a esa pregunta en mi humilde opinión.

Creo que el caso de uso que proporcionas y el que proporciona @avocadesign ayudarán mucho al equipo.

Con respecto a su ejemplo, mi sugerencia (vea algunas reacciones arriba) simplemente mostraría todos los cuadros como se muestra en la captura de pantalla (con el nuevo estilo de Gutenberg, por supuesto).

@kevinwhoffman

Lo más probable es que Gutenberg opte por los CPT, al igual que su CPT no declara ser compatible con el editor actual. No veo por qué nunca optaría por los CPT, ya que la mayoría de las cosas en WordPress son extremadamente flexibles, Gutenberg no será diferente. Actualmente solo funciona para publicaciones.

Dudo mucho que Gutenberg cambie algo en absoluto para una interfaz como esta, ni es la intención. Dicho esto, podría ser interesante explorar lo que ofrece Gutenberg y ver si puede crear una experiencia de edición más atractiva para su cliente usándolo.

Por ejemplo, podría crear un bloque de propiedad / propiedades, que podría usarse para permitir que su cliente incruste información de propiedad en otras publicaciones, etc. de manera rápida y fácil. Luego, mientras editan en Gutenberg, podrían cambiar la misma información que ve en ACF mientras miran la información de propiedad que se muestra dentro de Gutenberg. Gutenberg no está superando la interfaz de administración de WordPress, está reemplazando la funcionalidad del editor y probablemente conducirá a plantillas de contenido basadas en bloques.

¡Vienen cosas buenas de Gutenberg, no dolores de cabeza!

Aquí está la pantalla de edición de Eventos para el sitio mencionado anteriormente con los campos ACF arriba de post_content y luego el cuadro meta estándar del Calendario de Eventos debajo de post_content.

El sitio se abrirá a muchos usuarios no técnicos, no estamos hablando de un equipo editorial capacitado, estamos hablando de un promedio de Joe que nunca antes ha usado WordPress o ha recibido capacitación más que la ayuda que brindamos en el sitio.

Lo hemos establecido de esta manera para asegurarnos de que los usuarios encuentren e ingresen el tipo de evento y la categoría y el encabezado y las imágenes destacadas de cada evento. También podemos utilizar las posiciones de los metabox existentes para proporcionar documentación de ayuda relevante en la pantalla para ayudarlos a editar el evento y brindar soporte a los nuevos usuarios de una manera no intrusiva.

También tenga en cuenta que hemos iniciado sesión como administrador, los usuarios que no son administradores han ocultado varios metaboxes de la barra lateral para reducir aún más el desorden visual que ven.

El "contenido" no es tan relevante como las distintas metacajas para ingresar con éxito a un evento. Un evento no se mostrará en el sitio si una fecha no se ingresa correctamente o no se selecciona una categoría. Lo que me preocupa de toda esta discusión son las maquetas como en el número 1352, donde las metacajas están relegadas a la parte inferior de la pantalla en una sección plegable. Puedo garantizarle, por nuestra experiencia, que tendríamos usuarios no capacitados que nunca verían los meta recuadros, solo ingresaron la fecha y la ubicación directamente en el área de contenido como texto sin formato y luego se quejarían de que su evento no aparecía en el sistema. Simplemente, no es lo suficientemente visible para usuarios no capacitados en tipos de publicaciones que requieren información estructurada.

También tenemos campos obligatorios en esta interfaz y si el cuadro de meta está colapsado, el usuario recibirá una advertencia pero no podrá encontrar fácilmente la causa del problema.

Los metaboxes o la próxima iteración de su tipo de funcionalidad deben ser ciudadanos de primera clase y necesitamos la capacidad de colocarlos encima del contenido, al lado del contenido o debajo del contenido para hacer interfaces utilizables para nuestros clientes.

Lo más probable es que Gutenberg opte por los CPT, al igual que su CPT no declara ser compatible con el editor actual.

No se ha confirmado el registro de soporte para Gutenberg en CPT, y honestamente, se siente más como evitar el problema de las metacajas en lugar de resolverlo. Si la única forma de que los sitios existentes accedan a Gutenberg es registrar su soporte por código, entonces limitaría severamente la audiencia potencial.

Tampoco debemos pretender que los metaboxes personalizados solo se utilicen en tipos de publicaciones personalizadas. Es igualmente probable que existan en publicaciones y páginas regulares.

Gutenberg no está superando la interfaz de administración de WordPress, está reemplazando la funcionalidad del editor ...

Esto es inexacto. Tal como existe hoy, Gutenberg _es_ un reemplazo de pantalla completa para la pantalla de edición posterior.

@ BE-Webdesign y @kevinwhoffman

Además, ¿por qué los CPT deberían perderse los aspectos de Gutenberg que son claramente mejores que la pantalla de edición actual?

Los controles de publicación se mueven a la parte superior para que no se confundan con el contenido y una estética general más limpia son definitivamente puntos fuertes de hacia dónde se dirige este proyecto.

Al no tener un plan decente sobre cómo crear una funcionalidad equivalente a la que existe actualmente para los CPT con necesidades complejas (a través de metacajas), estamos ignorando una gran parte de la base de usuarios y relegándolos a una segunda clase, en última instancia, una experiencia sin soporte.

En mi humilde opinión, eso simplemente apesta.

Ni siquiera estoy argumentando que los metaboxes deban funcionar de manera inmediata como existen actualmente. Podría haber una forma nueva y mejor de implementar este tipo de flexibilidad de interfaz.

Lo que me preocupa es que el equipo de desarrollo realmente no parece comprender los problemas de muchos desarrolladores para hacer cumplir un primer enfoque "post_content" aquí. Usamos Beaver Builder en TODOS nuestros sitios, excepto para CPT's donde necesitamos salida de datos estructurados. Una herramienta de creación de páginas, que es Gutenberg, es excelente para publicaciones y páginas con necesidades de contenido individuales. Es terrible para los datos estructurados. Para los datos estructurados, la coherencia de la interfaz, los campos obligatorios y otras prioridades de diseño prevalecen sobre el contenido de forma libre en todo momento.

@kevinwhoffman

Tampoco debemos pretender que los metaboxes personalizados solo se utilicen en tipos de publicaciones personalizadas. Es igualmente probable que existan en publicaciones y páginas regulares. Esto es inexacto. Tal como existe hoy, Gutenberg es un reemplazo de pantalla completa para la pantalla de edición posterior.

Sí, pero no reemplaza toda la interfaz de administración, que es a lo que me refería. Estás comparando un proyecto incompleto con la experiencia actual. # 2251, cuando esté completo, volverá a introducir las omnipotentes cajas meta, por lo que no será tan diferente y será mucho mejor. Probablemente habrá algunas cosas que ciertos autores de complementos tendrán que modificar, pero en su mayor parte estoy seguro de que todo irá bien.

@avocadesign

Además, ¿por qué los CPT deberían perderse los aspectos de Gutenberg que son claramente mejores que la pantalla de edición actual?

¿Nadie dijo que son de mi conocimiento? No hay mucha diferencia entre agregar soporte de editor para un CPT y agregar soporte para el editor de bloques.

Al no tener un plan decente sobre cómo crear una funcionalidad equivalente a la que existe actualmente para los CPT con necesidades complejas (a través de metacajas), estamos ignorando una gran parte de la base de usuarios y relegándolos a una segunda clase, en última instancia, una experiencia sin soporte.

Creo que existe un plan decente, tal vez no esté claro, pero estoy muy seguro de que Gutenberg satisfará las necesidades de la gran mayoría de todos los tipos de usuarios, incluso las superará, cuando todo esté dicho y hecho.

¿Nadie dijo que son de mi conocimiento? No hay mucha diferencia entre agregar soporte de editor para un CPT y agregar soporte para el editor de bloques.

Me preocupa que el paso del que hablaron muchos en este hilo de hacer que Gutenberg opte por los CPT dará como resultado que muchos de los casos de uso complejos actuales sean ignorados en Gutenberg a corto y mediano plazo y forzar efectivamente casos de uso como los eventos. uno ilustrado arriba para usar el sistema existente porque Gutenberg no es lo suficientemente flexible. Eso está obligando efectivamente a esos casos de uso complejos actuales a perderse las otras ventajas del proyecto.

Nos dicen mucho "no te preocupes, estará bien", pero tienes razón @ BE-Webdesign cuando sugieres que el plan no se presenta claramente para algunos de nosotros, simplemente no puedo ver en todo esto se va a resolver satisfactoriamente a corto plazo, si es así, no dude en señalar la discusión o el tema para aclararme.

Editar:
Lo que quiero decir con "corto plazo" es el lanzamiento de 5.0 al público, principios de 2018 parece ser el objetivo aquí. A largo plazo, en 2 o 3 años, puedo ver que esto se resolverá con mucho más éxito.

@BennyVL & @dmccan La flexibilidad es un problema clave aquí. Corrígeme si me equivoco, pero nada de lo que veo sugerido por los desarrolladores que trabajan en esto es tan flexible como lo que tenemos actualmente.

Con ACF y otros complementos, puedo registrar fácilmente metaboxes encima del contenido (debajo del título), debajo del contenido y en la barra lateral. El diseño de la interfaz depende de mí. No exige que el editor sea el primero, no exige que el editor esté presente. Puedo registrar nuevos metaboxes, puedo dar de baja o mover otros.

Lo que quiero es una solución que siga siendo así de flexible a largo plazo. No me molesta si los metaboxes deben actualizarse a un nuevo formato JS brillante, convertirse en bloques adecuados o si se necesita algún otro cambio para que esto sea posible. Quiero que la flexibilidad que disfrutamos actualmente se incluya en Gutenberg independientemente del método utilizado para llegar allí.

Lo que quiero es una solución que siga siendo así de flexible a largo plazo. No me molesta si los metaboxes deben actualizarse a un nuevo formato JS brillante, convertirse en bloques adecuados o si se necesita algún otro cambio para que esto sea posible. Quiero que la flexibilidad que disfrutamos actualmente se incluya en Gutenberg independientemente del método utilizado para llegar allí.

Ese es el objetivo y lo que la mayoría de la gente quiere.

He escuchado muchas charlas sobre el problema del metabox y lo que les sucederá con este nuevo editor. Mi opinión personal es que Gutenberg debería centrarse solo en el editor y no en toda la pantalla de edición de la página. Pero parece que ya se tomó la decisión.

Hola chicos,

Soy el desarrollador principal de Carbon Fields y quería agregar la lista de acciones / filtros que usamos que pueden verse afectados:

Filtros:

• postbox_classes_{$page}_{$id}

Comportamiento:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (posicionamiento del azúcar - no crítico)

Mis preguntas:

• Si vamos a mantener los metaboxes heredados, ¿cómo interactuarían con los cambios de datos?
• ¿Qué tipo de eventos (jQuery? ¿Alguna implementación expuesta de un emisor?) Y qué eventos exactamente podemos esperar del nuevo editor (por ejemplo, sobre el éxito del envío, el error, etc.)
• ¿Estos eventos estarán disponibles para metaboxes heredados o solo para implementaciones de React?

PD:
Solo quiero agradecer al equipo de Gutenberg por todo el arduo trabajo y esfuerzo y me emociona que WordPress esté avanzando hacia herramientas y soluciones modernas (¡incluso si el viaje parece aterrador)!

Apoyar las cajas meta es muy importante ...

... para miles de desarrolladores y usuarios de wordpress.

WordPress no puede ignorar el gran reproductor de complementos ...

... como Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce o Yoast SEO.

Soy responsable del proyecto Toolset , que utiliza en gran medida tipos, campos y taxonomía personalizados.

Queremos que nuestros complementos sean compatibles con Gutenberg.

Esto es lo que entiendo:

• Necesitaremos usar una nueva API para mostrar los campos personalizados y la taxonomía en páginas y publicaciones, cuando usen Gutenberg.
• No necesitamos hacer nada con Gutenberg para los CPT, porque usarán el editor normal de WordPress y no Gutenberg.

¿Es esto correcto? Si es así, ¿podría referirme amablemente a la documentación de la API para mostrar cuadros personalizados en Gutenberg?

Creo que los documentos todavía están evolucionando. Hay algunos documentos en https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

Estoy escuchando lo que @ BE-Webdesign y otros dicen sobre la intención de minimizar las interrupciones, gracias, eso es reconfortante, pero solo quería agregar el valor de mis 5 peniques (vale, vale, mis 105 peniques habituales).

Cualquiera que haya estado desarrollando durante un tiempo recordará el dolor de crear manualmente interfaces web para bases de datos personalizadas: aburrido, lento, propenso a errores y muy costoso en términos de tiempo de desarrollador.

WordPress más Advanced Custom Fields (Pro) es una gran herramienta para crear de manera eficiente sitios web basados ​​en bases de datos a medida (e incluso herramientas de administración de datos de intranet) con interfaces atractivas, control de entrada de datos riguroso, interfaces de usuario intuitivas y consistentes, etc. ser escalable para enormes volúmenes de datos relacionales, pero en muchos casos no es necesario; estos son sistemas simples que pueden crearse de manera rentable para los clientes. Esto es lo que hace de WordPress un CMS realmente útil (y, de hecho, un RDBMS ligero), no solo una plataforma de blogs.

Yo (y estoy seguro de que muchas otras) pequeñas empresas utilizamos WP + ACF (o complementos de datos personalizados similares) para crear sitios y sistemas personalizados para organizaciones clientes y personas que no tienen grandes presupuestos de TI. Si la introducción de Gutenberg se realiza sin la debida consideración para admitir los flujos de edición / entrada de datos existentes, metaboxes, etc., tengo dos problemas "no técnicos" pero no obstante importantes:

1 / Mis usuarios finales necesitarán volver a capacitarse (es fácil para nosotros, como técnicos, olvidar lo confundidos que pueden llegar los usuarios no técnicos con los cambios en la interfaz: escribí el complemento Clarify Password Reset porque estaba perdiendo mucho tiempo resolviendo usuarios que estaban totalmente bloqueados por el nuevo proceso de restablecimiento de contraseña introducido en 4.3).

2 / Además de actualizar mis propios complementos para un enfoque de metabox diferente, tendré que dedicar tiempo a actualizar y probar todos los sitios de mis clientes con un nivel profesional de diligencia, asegurándome de que todos y cada uno de los complementos de terceros que soy utilizando también han logrado actualizar su código base correctamente. (Y esto en una situación en la que no tengo control sobre la rapidez con la que se actualizan los complementos de terceros, ya sea antes o (peor aún) en algún momento después de la versión 5.0, por lo que la planificación de la carga de trabajo se vuelve realmente difícil).

En ninguno de los casos anteriores, creo que es correcto cobrar a mis clientes honorarios adicionales por ese trabajo adicional; después de todo, elegí la plataforma en la que construir sus sitios y sistemas, y no es que hayan solicitado cambios o mejoras. Quizás soy "demasiado agradable" o ingenuo en ese frente, pero como la gente ha mencionado anteriormente, es un problema de confianza; confiamos en que WordPress no nos dejará en el caca rompiendo la compatibilidad con versiones anteriores, de modo que nuestros clientes puedan confiar en que no los picaremos por tarifas adicionales inesperadas. El resultado neto es que de repente tengo una enorme cantidad de trabajo extra no remunerado para encajar de alguna manera, posiblemente con urgencia, si los sitios se rompen activamente por la actualización de inmediato, mientras continúo haciendo suficiente trabajo remunerado para mantenerme a flote.

Realmente me gusta usar WordPress, y he invertido mucho tiempo aprendiendo las cuerdas, desarrollando mis propios marcos de proyectos útiles, etc., hasta el punto en que ahora gano la mayor parte de mi vida (y alimento a mi familia, etc.) a través de proyectos de desarrollo basados ​​en WordPress. También he tratado de devolver algo tomándome el tiempo para lanzar formalmente pequeños complementos útiles que he desarrollado en WordPress.com, porque valoro el OSS, el desarrollo basado en la comunidad, etc. Supongo que esto es principalmente una súplica para tomar los problemas. mencionado en este número hilo de rosca a corazón tanto como sea posible; de lo contrario, estoy de acuerdo en que existe un peligro real de que el código base se bifurque. Como fan de WordPress y colaborador de complementos, creo que este es un resultado REALMENTE malo; sin embargo, como desarrollador en solitario que depende de WP para ganarme la vida, es posible que deba optar por la versión bifurcada (es decir, compatible con versiones anteriores) por necesidad económica. ¡No dejes que esto suceda!

@konamac hace algunos puntos importantes, algunos de los cuales he publicado en otro hilo.

Para aprovechar esto, es totalmente inaceptable no darnos una respuesta tranquilizadora sobre el futuro de los metaboxes.

1. No hay una respuesta sencilla al soporte futuro de los metaboxes existentes. Este es un movimiento extremadamente frustrante y de mano dura contra las agencias de desarrollo y los autores de temas / complementos. "Gutenberg es de código abierto, así que descúbrelo tú mismo" es una irresponsabilidad.

2. Gutenberg es asombroso. Me encanta la interfaz, el diseño visual y creo que este es el camino del futuro en términos de edición de contenido. Pero está muy por detrás de donde debe estar para considerarlo para una versión 4.9 o 5.0.

3. Todo lo que debería poder hacer en Legacy es todo lo que debería poder hacer en Gutenberg.

4. Opciones de pantalla
5. Cajas meta (ACF, Yoast, etc.)
6. ¿Permalinks? Ni siquiera puedo comenzar a entender por qué esto aún no se puede editar en 1.0
7. El bloque de contenido clásico NO se carga correctamente en entornos de host local
8. La documentación DEBE ser clave para crear diferentes bloques de estilo. Dé varios ejemplos, varios casos de uso. No todos los desarrolladores de temas son backend, así que no asumas. Sea claro como el cristal
9. La configuración del bloque necesita trabajo. Es muy difícil saber qué configuraciones están disponibles por bloque. Parece aleatorio. ¿Cuándo necesito editar la configuración del bloque y cuándo no?
10. Todas las etiquetas de comentarios alrededor del editor de texto de Gutenberg son ... triste de ver.

Algunos de nosotros nos sentimos extremadamente frustrados con este proceso. Debería ser una respuesta muy simple.

¿Gutenberg protegerá el uso actual de metaboxes / ACF, y existen planes para garantizar dicho soporte de forma indefinida?

No necesitamos saber cuál es la solución en este momento, sabemos que la está descubriendo. Pero todavía no tenemos una respuesta CLARA sobre esto. ACF, en particular, debe funcionar exactamente de la misma manera que siempre tiene que respaldar a los clientes más antiguos que NO aceptarán que se les cobre para actualizar, especialmente cuando se habla de eliminar el editor heredado en algún momento (¿cómo puede comenzar a tener esa conversación ahora? )

Amo a Gutenberg. Pero tengo que unirme al coro, esto se está volviendo ridículo. La forma en que el equipo del proyecto ha comunicado esta expectativa no ha sido sencilla. Sí o no es todo lo que buscamos.

@ BE-Webdesign

cuando esté completo, volverá a introducir las todopoderosas cajas meta en

Por lo tanto, ¿puedo sugerirle que escriba una publicación completa sobre este mismo tema, que de hecho ha indicado, que las metacajas, como están ahora, se quedarán por favor? Esto evitaría que muchos desarrolladores de la comunidad estén preocupados por sus negocios.

Además, animo al equipo a hacer de esto una prioridad para agregarlos ahora. Esto evitaría mucha negatividad en torno al proyecto, estoy seguro.

Como se indica en el n. ° 2308, copié los ganchos que usa el complemento Meta Box al crear / guardar campos personalizados:

• Los scripts y los estilos se ponen en cola usando admin_enqueue_scripts . Verificamos la pantalla actual (a través de get_current_screen ) para asegurarnos de que los scripts y estilos estén en cola solo para esas páginas. Para el complemento principal, verifica por tipos de publicación. Para las extensiones (meta de término, meta de usuario, página de configuración), busca más taxonomías, página de perfil de usuario o páginas de configuración.
• También usamos print_media_templates para imprimir plantillas de subrayado.
• Los scripts que usamos en el complemento incluyen: selector de color, guión bajo, columna vertebral, scripts de medios, tinymce (para el campo del editor)
• Usamos init para inicializar todos los ganchos del complemento.
• Las metacajas se registran usando ganchos add_meta_boxes .
• Las metacajas ocultas usan default_hidden_meta_boxes .
• También enlazamos a post_edit_form_tag para permitir la carga de archivos.
• Usamos save_post_{$post_type} y edit_attachment , add_attachment para guardar valores meta para publicaciones y archivos adjuntos.

¿Qué hay de malo en construir ganchos para mostrar metaboxes arriba / abajo / barra lateral de Gutenberg?

Pensé que también podría hacer lo que los desarrolladores de terceros hacen mejor y lanzar otra llave enorme en las obras.

Mattias nos dice que los metaboxes se pueden reinventar como bloques que se almacenan en post_meta. Si ese es un objetivo para la fusión, entonces hay algunos problemas que resolver:

Muchas metaboxes registran the_editor($custom_id); para que esto sea compatible en el contexto de Gutenberg, o una interfaz y una api para crear bloques anidados son necesarias desde el primer día, o estamos diciendo que las metaboxes solo pueden tener la interfaz de editor de segunda clase , sin ninguno de los beneficios de los bloques. Esto será particularmente problemático para la gran cantidad de agencias que actualmente diseñan con diseños flexibles ACF, ya que necesitarán una forma de crear bloques Gutenberg separados para varios contextos y áreas. Incluso "pensando en bloques", no veo una buena manera de resolver el problema del "área de contenido seguida de la parte de la plantilla seguida del área de contenido" sin admitir la anidación en "metabloques" desde el primer día.

De ahí surge la preocupación técnica de anidar con respecto a los bloques que no se almacenan en post_content. Mattias dice que los bloques se podrán almacenar en postmeta, pero si un bloque puede definir dónde se almacena, cómo funcionará el anidamiento, cuándo un bloque padre se almacena en postmeta y el usuario agrega un hijo que almacena en un post_meta diferente ... (O en el caso patológico, un bloque anidado que Tha almacena en postmeta contiene un bloque que se almacena en el mismo campo postmeta.

Esto conduce a una tercera preocupación de metabox. Si Gutenberg es un reemplazo de página de edición completa, en lugar de un reemplazo de the_editor() , ¿cómo podrán las personas poner en cola y usar bloques en otras páginas y en otros contextos, como metaboxes o paneles de administración personalizados que usan the_editor() . A primera vista, parece que la respuesta será "no pueden". Lo que genera serias preocupaciones sobre si Gutenberg agrega flexibilidad a las implementaciones de CMS personalizadas o la elimina.

Si a los usuarios se les da la opción de Gutenberg, y es tan revolucionario para ellos como se afirma, no poder proporcionar esa nueva interfaz en estos casos podría resultar desastroso para las agencias.

No hay una respuesta sencilla al soporte futuro de los metaboxes existentes.

He dicho repetidamente que vamos a tener en cuenta las metacajas. La única incertidumbre es qué es técnicamente viable y cómo se mostrará en la nueva interfaz de usuario.

No estamos intentando romper nada (códigos cortos, campos personalizados, etc.), todo debería funcionar. La interfaz de usuario para interactuar con ellos puede cambiar (a menos que desactive Gutenberg por completo), y ciertos casos de uso de metacajas se adaptarán mejor a los bloques que avanzan.

Gutenberg es asombroso. Me encanta la interfaz, el diseño visual y creo que este es el camino del futuro en términos de edición de contenido.

¡Me alegro de oir!

¿Permalinks? Ni siquiera puedo comenzar a entender por qué esto aún no se puede editar en 1.0

Porque la API REST aún no admite esto. Cualquier ayuda es bienvenida: https://github.com/WordPress/gutenberg/issues/1285

He dicho repetidamente que vamos a tener en cuenta las metacajas.

@mtias Creo que la confusión con respecto a la compatibilidad con los metaboxes se debe a que

He dicho repetidamente que vamos a tener en cuenta las metacajas.

@mtias mis disculpas, debo haber perdido tu aclaración en otro lugar. ¡Contento de escuchar! Haga que la iteración actual sea visualmente más atractiva y decidida y será un gran éxito.

Entiendo lo que está diciendo sobre la compatibilidad con la API REST, estaré pendiente de las actualizaciones en el hilo.

Gracias por la aclaración. Ahora que tengo esta idea, estoy a toda velocidad por delante de Gutenberg: todos mis miedos se han dejado de lado.

@kevinwhoffman correcto, creo que el meollo del problema es que la "funcionalidad existente" también incluye la presentación, y dado que Gutenberg cambia significativamente la interfaz de usuario, volver a la anterior requeriría que el complemento se desactive. Cómo encajan las metacajas en la nueva interfaz de usuario y cómo se pueden admitir las antiguas cajas meta sin la intervención del desarrollador son las cosas en las que se está trabajando. No sé exactamente cómo funcionará eso, así que no he podido prometer un resultado específico. También creo que esto podría terminar en una presentación más clara de las características de las metacajas.

@brograhamer no se necesitan disculpas, ¡es un hilo

Actualmente estoy creando una aplicación web usando ACF con 10 tipos de publicaciones personalizadas que no usan el editor tinymce. Estoy usando la función Título y alrededor de 15 campos ACF en promedio para cada CPT.
Actualmente, puede declarar qué características (es decir, editor, miniatura, extracto, etc.) admite un CPT.
¿Será posible ocultar / eliminar el bloque de párrafo "Escribe tu historia" así como el icono "Insertar bloque" de la pantalla de edición?

@ cr101 Creo que si

Por otro lado, con la v1 de metaboxes, los paneles de metaboxes se pueden expandir desde la parte inferior, si mantenemos esto, debemos asegurarnos de que siempre esté "abierto" para CPTs sin soportes de "editor". Puede que no sea necesario si los metaboxes siempre se muestran debajo del editor (como algunas de las sugerencias de diseño anteriores)

No estoy seguro de si este es el lugar adecuado para esto, pero ¿qué pasa con los metacampos personalizados principales? Se ha hablado mucho sobre complementos de terceros, pero ¿qué pasa con los metacampos personalizados principales? Sé que esos no son realmente tan populares, pero puedo pensar en algunos sitios en los que he trabajado que los usan.

¿Existe algún plan para integrar los metacampos personalizados centrales en Gutenberg?

Hola @jawittdesigns ,

¡Estoy bastante seguro de que los metaboxes principales (al menos la mayoría de ellos) ya se han vuelto a implementar en Gutenberg! Presentan algunos flujos de trabajo más agradables en torno al manejo de taxonomías, etc.

No todo el mundo usa WordPress para blogs. Muchos de nosotros usamos WordPress como CMS. Actualmente estamos creando una aplicación web utilizando la API REST de WordPress y ACF. Tenemos 10 tipos de publicaciones personalizadas y cada CPT tiene 20 campos personalizados y todos los CPT están vinculados entre sí a través de relaciones bidireccionales utilizando los campos Relación de ACF y Objeto de publicación y el complemento ACF Post-2-Post.

Gutenberg no nos sirve en su forma actual, ya que ni siquiera usamos el editor actual. Solo estamos usando el cuadro de texto Título para nuestros CPT y el resto son campos personalizados que se almacenan en la tabla post_meta.

Creo firmemente que el editor de Gutenberg no debería convertirse en parte del núcleo en su estado actual. Reconozco que WordPress como proyecto necesita jugar algo para aquellos creadores de sitios que no trabajan con sus propios temas personalizados ... sin embargo, el editor de Gutenberg parece ser un ataque directo contra aquellos de nosotros que usamos Campos personalizados avanzados para realizar entradas complejas de contenido. bastante "a prueba de idiotas" para los propietarios de sitios al proporcionarles una forma muy específica de ingresar su contenido. El editor de Gutenberg en su estado actual parece ser un ataque directo contra aquellos de nosotros que usamos ACF.
Con el complemento de Gutenberg, el enlace de edición en el encabezado envía al usuario directamente a la interfaz de Gutenberg que no muestra NINGUNA de las meta-cajas de ACF y no tiene una pestaña de opciones de pantalla en la parte superior de la pantalla para activarlas. Sí, el usuario puede volver a la matriz de página / publicación y elegir la opción “editor clásico” y luego ver los meta-cuadros, pero esto significa que el editor del sitio debe dar un paso adicional para llegar a los campos ACF. No es exactamente lo óptimo considerando que el objetivo de usar ACF en muchos casos era hacer que la edición de diseños complejos fuera más fluida y sencilla para un editor no técnico.

¡Qué problema de larga duración ha sido este!

Con la fusión de # 3345 y # 3554, el soporte de metabox está en un estado que estamos felices de llamar _feature complete_. Tenga en cuenta que esto es diferente de _complete_, ya que obviamente todavía hay trabajo por hacer para pulir la experiencia del metabox, particularmente en lo que respecta al estilo, el manejo de JavaScript más complejo y la determinación de reglas para volver al editor clásico.

Gracias a todos los que han participado de manera constructiva en este tema, entiendo que ha sido un proceso difícil y, en ocasiones, controvertido. Para obtener una documentación sobre cómo Gutenberg maneja las metacajas y cómo usted (si lo prefiere) puede marcar las metacajas como incompatibles con Gutenberg, consulte el manual .

Si se encuentra con errores asociados con complementos particulares o metacajas, abra un nuevo problema, para que se pueda rastrear correctamente y corregir.

Con respeto, esto debería estar lejos de estar completo.

@coffeeneed Si desea ser constructivo, abra un nuevo número con suficientes detalles para que podamos ayudarlo. Gracias