Gutenberg: Espacio gigante sobre todo el video de Youtube en Publicaciones

Gracias por informar del error, convino en que no se ve bien, y me imagino frustrante.

Veo el espacio en blanco cuando visito su sitio, sin embargo, no puedo reproducirlo. Instalé el tema Hueman Free y utilicé el complemento Autooptimize, que noté que es lo que usa en su sitio en: https://www.discerningtheworld.com/

Cuando creo una publicación con una inserción de YouTube, no puedo obtener el gran espacio.

Para ayudar a cualquier otra persona a solucionar problemas:

Noté que en su incrustación hay un nombre de clase adicional wp-embed-aspect-4-3 que, cuando está presente, agrega el relleno en la parte superior. Puedo ver en el código si se especifican el ancho y la altura del marco que agregará, pero no vi cómo se especificaría directamente en Gutenberg.

Código en: packages/block-library/src/embed/index.js

¿Puedes decirme cómo agregaste la inserción y si hay algo que hiciste después de agregar la inserción para ayudar a reproducir y resolver el problema?

Hola mkaz

Sí, vi "wp-embed-aspect-4-3" en el CSS y como no soy programador en absoluto, no tenía idea de si debería estar ahí o no.

Así que lo quitaré y volveré contigo.

Agregué el video incrustado, agregando un bloque, luego haciendo clic en Youtube y solo agregando la URL del video de YouTube, nada más, solo la URL simple del video. Todo funcionaba bien hasta la última actualización de la versión.

Hola mkaz

¡Ahhhhh Ha! "wp-embed-aspect-4-3" es de hecho el culpable, lo eliminé y el espacio gigante desapareció. Pero ahora la gran pregunta, ¿de dónde viene este CSS adicional? Ayer no estaba allí. Todo fue perfecto hasta que actualicé a la nueva versión de Gutenberg anoche.

Veo en otras publicaciones que se agregó CSS ​​adicional "wp-has-aspect-ratio wp-embed-aspect-16-9". Y también está creando un gran espacio en blanco sobre todos mis videos.

¿Qué sugieres que haga? No puedo sentarme y revisar manualmente 600 artículos eliminando este CSS que apareció de la nada. Ayuda.

ok, es bueno ver que pudimos reducirlo.

Tendrá que investigar más para ver qué estaba tratando de abordar y encontrar una solución.

Me tienes pensando.

Desactivé el complemento Autoptimize y taaadaaaa .... problema resuelto.

Jugaré con la configuración y veré si puedo hacer que Autoptimize funcione sin romper mi sitio ...

¿Recomiendas otro complemento similar a Autoptimize?

Me tienes pensando.

Desactivé el complemento Autoptimize y taaadaaaa .... problema resuelto.

Jugaré con la configuración y veré si puedo hacer que Autoptimize funcione sin romper mi sitio ...

¿Recomiendas otro complemento similar a Autoptimize?

Mientras tanto, tiene el complemento desactivado, debe informar ese problema a los desarrolladores de Autoptimize: https://wordpress.org/plugins/autoptimize/#developers

Gracias Marcus.

Me he puesto en contacto con el soporte de Autoptimiae aquí: https://wordpress.org/support/topic/giant-space-above-all-youtube-video-when-viewing-posts-in-gutenberg-v-3-9-0/

Hola a todos;
Soy el desarrollador de Autoptimize :-)

De hecho, todavía veo la brecha incluso con AO deshabilitado, cfr. esta captura de pantalla;

Hay un padding-top:75% y un padding-top:50% (ambos por .wp-block-embed__wrapper::before ) en wp-content/plugins/gutenberg/build/block-library/style.css . ¿Deshabilitar esas reglas en el inspector "soluciona" el problema?

¡Feliz cacería!
franco

Dios mío, el error ha vuelto ... ahora estoy confundido ... Sin embargo ...

Frank, eres una superestrella !!!! 🥇

Gracias por saltar y mirar a @futtta - de acuerdo, no creo que sea un conflicto con Autoptimize.

Para ayudar a solucionar problemas:

@Pikkals ¿qué pasos hiciste al agregar la

Para @notnownikki y @jasmussen que trabajaron en el problema:

Parece una consecuencia involuntaria de este PR # 9770 en 3.9.0 que el ancho / alto del iframe se está detectando correctamente y se agrega la clase de relación de aspecto adicional, sin embargo, cuando se agrega la nueva clase, incluye un gran relleno en la parte superior.

Parece que los estilos en # 9550 son los que están causando el problema aquí, pero no puedo reproducir en mis pruebas cuando agrego un bloque, usando el mismo tema que el usuario.

Hola a todos -

Eché un vistazo a esto y creo que puede ser un conflicto de complementos, aunque no creo que sea Autoptimize en este caso.

Cuando inserto una inserción de YouTube en mi propio sitio, veo este HTML renderizado:

<figure class="wp-block-embed-youtube wp-block-embed is-type-video is-provider-youtube wp-has-aspect-ratio wp-embed-aspect-16-9">
    <div class="wp-block-embed__wrapper">
        <iframe width="660" height="371" src="https://www.youtube.com/embed/GLwz5IJ4AsY?feature=oembed" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen=""></iframe>
    </div>
</figure>

Sin embargo, cuando miro una inserción de YouTube en su sitio, veo lo siguiente:

<figure class="wp-block-embed-youtube wp-block-embed is-type-video is-provider-youtube wp-has-aspect-ratio wp-embed-aspect-4-3">
    <div class="wp-block-embed__wrapper">
        <div class="video-container">
            <span class="embed-youtube" style="text-align:center; display: block;">
                <iframe class="youtube-player" type="text/html" width="640" height="360" src="https://www.youtube.com/embed/Bp00Wh-oaOQ?version=3&amp;rel=1&amp;fs=1&amp;autohide=2&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;start=108&amp;wmode=transparent" allowfullscreen="true" style="border:0;"></iframe>
            </span>
        </div>
    </div>
</figure>

Tenga en cuenta todas las etiquetas y clases CSS adicionales <div> y <span> .

@Pikkals ¿ podría proporcionar una lista de complementos en su sitio? Supongo que otro complemento está intentando manejar el video sensible y está chocando con la forma en que Gutenberg lo maneja.

Hola,

El mismo problema en mi blog con el tema gratuito de Hueman. No uso ningún complemento de editor (¿podrían estar involucrados otros tipos de complementos?).

Vea, por ejemplo, en la parte inferior de esa publicación modificada con Gutenberg 3.9.0 hoy: http://jeanneavelo.fr/2018/02/22/un-carrefour-urbain-ordinaire-aux-pays-bas/

Las publicaciones más antiguas (es decir, no editadas con Gutenbegrg 3.9.0) no se preocupan.

Entonces parece que es un problema con el tema Hueman Free en particular. Quizás valga la pena comunicarse con el desarrollador del tema sobre esto.

También es posible que valga la pena ver si esta debería ser otra función de tema opcional a través de add_theme_support para evitar posibles conflictos. Es posible que ese barco haya navegado ya que esta característica ahora está en Gutenberg, pero al menos podría valer la pena pensar en ello.

Hola chicos

Estoy usando el tema Hueman Pro. Me pondré en contacto con el desarrollador y los enviaré aquí para que le echen un vistazo.

Y sí, tienes razón, las publicaciones de Jeanneavelo que no han sido editadas con Gutenberg están bien.

Ok, he registrado un ticket con el soporte de Hueman.

Hola chrisvanpatten

Aquí hay una lista de todos mis complementos:

TEMA | VERSIÓN: Hueman Pro | v1.1.3
VERSIÓN WP: 4.9.8
- Páginas móviles aceleradas (versión 0.9.97.16)
- Agradable (versión 1.5)
- Akismet Anti-Spam (versión 4.0.8)
- Publicación automática en Instagram (versión 1.4.3)
- Autoptimize (versión 2.3.4)
- Childify Me (versión 1.2.0)
- Comentario aprobado (versión 1.5.2.3)
- Comentarios avanzados (versión 2.0)
- Barra de herramientas de comentarios (versión 1.4.3)
- Orden de taxonomía personalizada (versión 2.9.5)
- Deshabilitar Gutenberg Autosave (versión 1.0.1)
- Mostrar todos los tamaños de imagen (versión 1.1.6)
- Ley de cookies de la UE (versión 3.0.5)
- Forzar miniaturas regeneradas (versión 2.0.6)
- Pegamento para Yoast SEO y AMP (versión 0.4.3)
- Panel de control de Google Analytics para WP (GADWP) (versión 5.3.5)
- Traductor de idiomas de Google (versión 5.0.48)
- Gutenberg (versión 3.9.0)
- Jetpack de WordPress.com (versión 6.5)
- Publicaciones de la categoría de lista (versión 0.78.1)
- MailChimp (versión 1.5.7)
- Desplazamiento de anuncios de noticias (versión 8.8.6)
- Imágenes destacadas rápidas (versión 13.3.2)
- Widget de publicaciones recientes con miniaturas (versión 6.2.1)
- RefTagger (versión 2.1.2)
- Schema (versión 1.7.1)
- Caja de herramientas de imágenes SEO (versión 3.3.1)
- Edición de comentarios simple (versión 2.1.11)
- Etiquetas simples (versión 2.4.7)
- Sucuri Security - Auditoría, escáner de malware y refuerzo (versión 1.8.18)
- Apuntar en blanco en publicaciones y comentarios (versión 3.2)
- Herramientas de gestión de términos (versión 1.1.4)
- VaultPress (versión 1.9.6)
- wp-Monalisa (versión 4.6)
- Redireccionamiento automático de WP 404 a publicaciones similares (versión 0.7.7)
- WP Edit (versión 4.0.3) (HE DESACTIVADO ESTE PLUGIN)
- WP Super Cache (versión 1.6.4)
- Yoast SEO Premium (versión 8.2.2)

Buen boleto, gracias.

Entonces, este problema ocurre porque las incrustaciones creadas en Gutenberg ahora responden desde el primer momento. El problema aquí es que si el tema en sí también proporciona capacidad de respuesta para incrustaciones mediante el filtrado de la salida, terminas con una solución doble, lo que hace que aparezca este espacio adicional.

Hay varias formas de solucionar este problema, @chrisvanpatten. También agradecería sus

Opción 1 : Mueva el CSS sensible de Gutenblock de style.scss a theme.scss . La ventaja es que esto significa que los Gutenblocks solo responden si el autor del tema lo solicita y, por lo tanto, lo sabe. Desventaja: significa que no podemos proporcionar videos receptivos listos para usar.

Opción 2 : lo convertimos en un cambio de usuario, por lo que un usuario puede desactivar la capacidad de respuesta por inserción, si lo activamos de forma predeterminada.

Opción 3 : Aquí hay algo de CSS que parece solucionarlo en el caso de ESTE tema en particular:

.wp-block-embed__wrapper div, .wp-block-embed__wrapper span {
    padding: inherit;
    position: static;
}

Pero esto es un poco engañoso porque supone una forma particular de agregar capacidad de respuesta a los videos.

¿Qué piensas? CC: @mtias

Hmmmm

Veo que tengo un complemento llamado - WP Edit (versión 4.0.3) instalado,

Voy a desactivar esto y ver qué pasa.

Ok, veo que todavía tengo el problema. Mantendré este complemento desactivado ya que no veo la necesidad de hacerlo.

Opción 2: lo convertimos en un cambio de usuario, por lo que un usuario puede desactivar la capacidad de respuesta por inserción, si de forma predeterminada está activado.

También tenía esto en mi lista para sugerir, pensando en temas más amplios y videos más estrechos donde podría no verse tan bien.

Ok, he registrado un ticket con el soporte de Hueman.

Yo también: https://wordpress.org/support/topic/display-issue-with-youtube-embedded-video-in-gutenberg-3-9-0-edited-post/

Registré mi ticket en [email protected] y pedí a los desarrolladores que por favor vinieran a este hilo.

Por mucho que me decepcione, creo que podríamos tener que optar por esta opción. ¿O quizás hacemos que los videos receptivos se opten (¿o no?) A nivel de documento en lugar de a nivel de bloque.

Por mucho que me decepcione, creo que podríamos tener que optar por esta opción. ¿O quizás hacemos que los videos receptivos se opten (¿o no?) A nivel de documento en lugar de a nivel de bloque.

Este PR lo hace optar por los estilos de bloque . Pero estoy de acuerdo, consideraría esa nuestra última opción, porque siento la responsabilidad de que Gutenberg proporcione funciones de respuesta de forma predeterminada, así que asegurémonos de tener una solución en la 4.0, pero sigamos pensando en formas de hacer esto sin haciéndolo opt-in.

Es de suponer que los temas que proporcionan su propia capacidad de respuesta lo hacen con un filtro que agrega clases y elementos de envoltura adicionales, ¿no? ¿Sería posible / factible / no romper cosas si aplicamos un filtro con un nombre diferente para los videos receptivos?

Reflexión adicional sobre por qué sería bueno encontrar una solución que no requiriera participar a través de add_theme_support( 'wp-block-styles' ) : es probable que muchos temas nunca opten, incluso después de la fusión, porque quieren proporcionar sus propios estilos de citas en bloque y no tener que anular los proporcionados por los bloques principales. Estos temas aún deberían poder beneficiarse de lo que yo llamaría CSS estructural, como el necesario para las incrustaciones receptivas.

¿Sería posible / factible / no romper cosas, si generamos un filtro diferente para videos receptivos?

Todo esto pasa por oembed, creo que intentar interceptar qué temas hacen ahí acabará en una lucha prioritaria.

... sería bueno encontrar una solución que no requiriera participar a través de add_theme_support ('wp-block-styles') ..

Uf, también estoy de acuerdo con todo eso. ¿Quizás una opción de nivel de documento es el camino a seguir? ¿O tal vez una opción para todo el sitio, por lo que si cambia su tema, puede alternar la capacidad de respuesta proporcionada por G en todas las publicaciones?

No he tirado la toalla por completo en una corrección de código. https://github.com/WordPress/gutenberg/issues/10109#issuecomment -423898890 lo corrige, pero me encantaría que lo intentáramos con un montón de temas que brindan soporte de inserción receptivo, tal vez incluso complementos, para ver si funciona lo suficientemente bien.

Correo electrónico de soporte sobre el tema Hueman

Hola Deborah,
gracias por informar de esto!

Hemos identificado el problema de compatibilidad, sucede porque tanto el tema como Gutenberg aplican su propio código para hacer que el video responda, pero estos dos códigos entran en conflicto.

https://imgur.com/a/1BzGIu5

Muy pronto se lanzará una nueva versión del tema que contiene una solución.

Mientras tanto, dado que tanto el tema, por defecto, como Gutenberg hacen que el video responda con la misma relación de aspecto (16: 9), puede actuar en las clases adicionales del bloque de Gutenberg y eliminar la clase CSS del complemento que "produce" el conflicto: wp -embed-aspecto-16-9

Espero que esto ayude.

Rocco, equipo de soporte @presscustomizr

Mientras tanto, dado que tanto el tema, por defecto, como Gutenberg hacen que el video responda con la misma relación de aspecto (16: 9), puede actuar en las clases adicionales del bloque de Gutenberg y eliminar la clase CSS del complemento que "produce" el conflicto: wp -embed-aspecto-16-9

Espero que esto ayude.

Gracias por el ajuste: funciona perfectamente bien.

Confirmo. El conflicto entre Gutenberg y Hueman Theme Pro también ocurre desde la versión 3.9.0 de Gutenberg. Gracias por el tweak @Pikkals
Tu salvas mi dia
Au pasaje, sympa le blog

Por cierto, lindo el blog;)

Si el cumplido está dirigido a mí, ¡les doy las gracias! :-)

¡Increíble! Como parece que hay una solución, cerraré este problema, pero si alguien aún tiene problemas, siempre podemos volver a abrir :)

Solo una mención rápida de las relaciones públicas que le permitirían alternar la capacidad de respuesta bloque por bloque :) https://github.com/WordPress/gutenberg/pull/10161

El mismo problema con el tema Lensacap de Array (https://arraythemes.com/themes/lenscap-wordpress-theme/), no limitado al tema Hueman Pro

No ocurre con publicaciones antiguas con video, solo cuando edito la página y la actualizo (por ejemplo, https://litfl.com/tee-essentials-making-sense-of-the-views/)

Cuando elimino el "wp-embed-aspect-16-9" como se sugiere, todo se ve bien nuevamente. https://litfl.com/tee-essentials-assessment-of-the-left-ventricle/

Darse cuenta de que el hilo está cerrado, solo quería dar comentarios sobre un tema adicional.

El mismo problema se aplica al tema SiteOrigin Vantage. Creé un hilo en su foro .

No entiendo cómo aplicar la solución sugerida anteriormente. ¿Debo editar el archivo CSS del tema instalado? ¿Y cómo puedo hacer eso?

Hola amigos, acabamos de fusionarnos
https://github.com/WordPress/gutenberg/pull/10161, que le permitirá desactivar la capacidad de respuesta por bloque. Eso estará en la versión 4.0.

No entiendo cómo aplicar la solución sugerida anteriormente. ¿Debo editar el archivo CSS del tema instalado? ¿Y cómo puedo hacer eso?

Tienes que editar cada bloque en cuestión en html para eliminar el valor CSS "wp-embed-aspect-16-9".
No es un ajuste global.

Estoy en Divi. Solo tengo el mismo problema. Copie y pegue las URL de video en la publicación y deje que se convierta en un enlace para insertar. Lo redujo al 50% de relleno en wp-block-embed__wrapper :: before

Si entro en la configuración del bloque para avanzar y elimino el código css agregado wp-has-aspect-ratio wp-embed-aspect-16-9, parece que lo soluciono. Pero tengo que hacer eso para cada video.

Solo quiero confirmar con @jasmussen que esto está arreglado para la versión 4.0

Sí, hay una función en el 4.0 que le permite desactivar fácilmente la capacidad de respuesta de los videos:

Esto será en 4.0. Si necesitamos ir más lejos, entonces existe una "opción nuclear" en https://github.com/WordPress/gutenberg/pull/10133 que esperamos no tener que usar.

@jasmussen gracias por la captura de pantalla. ¿Es una configuración global o por bloque de YouTube?

Es por bloque, pero la solución alternativa mencionada en https://github.com/WordPress/gutenberg/issues/10109#issuecomment -424289255 también será 4.0, por lo que desactivar la capacidad de respuesta es un último recurso y _no debería_ ser necesario con 4

Golpeando esto para reconsiderarlo, encontré el problema de estilo en mi tema y las reglas de estilo parecen un poco demasiado inteligentes, afortunadamente el fragmento de arriba fue una buena anulación, pero claramente no es una solución universal. Esto es diferente de los estilos de bloques, como los bloques de colores, porque el estilo de video sensible cambia más drásticamente el flujo de la página. Si bien aprecio la función en principio, ¿cuál es el costo de envío de una experiencia auxiliar que tiene una alta probabilidad demostrada de romper temas de terceros? ¿Podríamos mantener esto para una versión posterior a la 4.0 o hacer que sea más opcional?

Este es el estilo de anulación que terminó funcionando para mí. El fragmento de @jasmussen no se anula para mí.

.wp-block-embed.wp-embed-aspect-16-9 .wp-block-embed__wrapper::before {
padding-top: inherit;
}

me encontré con el problema de estilo en mi tema y las reglas de estilo parecen demasiado inteligentes

¿Puedes dar más detalles?

Preferiría hacer que los estilos de bloques sean sólidos.

@jasmussen Me pregunto si la función podría

@davisshaver ¿Podría compartir el sitio en cuestión? ¡Un poco de contexto adicional sería muy valioso!

Me pregunto si la función podría aplazarse hasta que se pueda desarrollar un CSS más infalible.

Si bien todo es posible, este es el tipo de función que solo tiene sentido si se envía, y dudo que retrasar la función haga algo más que retrasar el dolor.

Eso no quiere decir que tengamos que forzarlo, me gustaría hacer que el CSS sea más "a prueba de balas", pero la única forma de hacerlo es ver qué temas realmente hacen, por eso pregunté sobre el método que estás usando. .

Si el método utilizado es el mismo que se utilizó para los temas mencionados anteriormente, tal vez pueda hacer una solicitud de extracción que aproveche esto para proporcionar la capacidad de respuesta de una manera que anule un tema.

En este punto, creo que es muy importante recordar que esta capacidad de respuesta se aplica _sólo_ a las incrustaciones creadas en Gutenberg, no a las incrustaciones creadas en el editor clásico.

En la tangente, dependiendo de cómo se desarrolle esto, los temas pueden proporcionar una capacidad de respuesta compatible con el alcance del CSS incorporado sensible a :not(.wp-has-aspect-ratio) ... { } .

@jasmussen Me complace ayudar. El parche se aplica en este sitio, pero puede eliminar la anulación con herramientas de desarrollo. https://leb.town/2018/09/19/lebanon-teen-bringing-lego-based-stem-education-to-the-region/

En este caso, más que en otros estilos, creo que la brecha en realidad se debe al comportamiento de la versión AMP de YouTube embed. Estoy usando el complemento AMP v1.xy probando el modo nativo de AMP.

Si quisiéramos parchear esto específicamente, supongo que algo como :not(:has(amp-youtube)) {...} podría funcionar, o alternativamente incluir el parche en la hoja de estilo de bloques con :has(amp-youtube) {...} .

Muchas gracias por el contexto adicional. Aquí está el marcado del complemento AMP de YouTube:

Parece que el complemento de YouTube de AMP está utilizando básicamente la misma técnica, un elemento de relleno del 56.something%.

Entonces, para resumir dónde estamos: muchos temas y complementos de WordPress brindan un soporte de inserción de video receptivo. Cuando Gutenberg también proporciona esto, hay un conflicto como se muestra en este hilo.

Aparte de simplemente revertir esta función o desactivarla de forma predeterminada, aquí hay algunas ideas:

1. hágalo participar a través de la opción de estilos de bloque, es decir, https://github.com/WordPress/gutenberg/pull/10133
2. habilítelo a través de una nueva llamada de función, como add_theme_support('responsive-embeds')
3. cambie la palanca para que las incrustaciones _no_ respondan de forma predeterminada fuera de Gutenberg
4. encontrar una manera de hacer una configuración global de cara al usuario para elegir el valor predeterminado de Gutenberg
5. intente hacer un truco de CSS que, con suerte, capture más métodos que hacer que los temas sean receptivos que el fragmento compartido aquí https://github.com/WordPress/gutenberg/issues/10109#issuecomment -423898890

Me encantaría recibir opiniones adicionales sobre esto. Por un lado, creo firmemente que el hecho de que tanto los temas como los complementos agreguen este soporte después del hecho, es una fuerte indicación de que _ se ha hecho mal todos estos años_ y deberíamos arreglarlo en la fuente.

Por otro lado, entiendo profundamente que a los usuarios no les importará eso, solo verán un espacio gigante encima de las incrustaciones y pensarán que hicieron algo mal.

Me encantaría que encontráramos un término medio que nos permitiera enviar esto de forma predeterminada, pero aún así dar más poder a las manos tanto de los usuarios como de los usuarios.

Explorando 5, me pregunto si lo siguiente podría funcionar mejor que el fragmento compartido anteriormente.

.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive),
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive)::before,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive)::after,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) *,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) *::before,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) *::after {
    padding-top: inherit !important;
    padding-bottom: inherit !important;
    position: static !important;
}
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) iframe {
    position: absolute !important;
}

Sería:

• ser solo Gutenberg, es decir, no tocar las publicaciones del editor clásico
• con alcance a videos (con una relación de aspecto)
• vea el marcado en http://jeanneavelo.fr/2018/02/22/un-carrefour-urbain-ordinaire-aux-pays-bas/.
• omite AMP por completo, que parece tener sus propias cosas, aunque afortunadamente de una manera estandarizada

Por otro lado, ese CSS es un poco loco y torpe.

Me encantaría tu opinión, @pento @mtias

Otra cosa a considerar son los temas que agrupan FitVids . Ahí es donde encontré el problema. Probablemente podría detectar si jQuery.fn.fitVids es accesible y deshabilitado condicionalmente en función de eso, pero parece un truco.

Creo que una opción add_theme_support es la mejor opción, aunque lamentablemente significa que muchos sitios no la sacarán de la caja. Sin embargo, es la opción más segura y permite que los temas con necesidades específicas proporcionen su propia solución de respuesta sin necesidad de pedir a los editores de contenido que recuerden deshabilitar la opción de inserción de respuesta.

@jasmussen Estoy totalmente de acuerdo con usted, esto debería haberse hecho mejor antes, pero mantener los sitios heredados en funcionamiento es el duro equilibrio de WordPress ... Creo que pasar a add_theme_support podría ser un buen equilibrio para crear un canónico solución y minimizar el riesgo para los usuarios heredados.

Como referencia, algunos otros ejemplos de inserción receptiva que he visto en la naturaleza incluyen la implementación .shortcake-bakery-responsive y Pym.js.

Con
https://github.com/WordPress/gutenberg/issues/10109#issuecomment -428177248 Creo que esto debe volver a abrirse o se debe presentar otro problema.

Poner esto detrás de una opción de soporte de tema parece la mejor manera de no romper las cosas.

+1 para la opción add_theme_support. También experimentando esto con 3.9.0 y FoundationPress debido a la siguiente implementación: https://github.com/olefredrik/FoundationPress/blob/3eafe78872e8d7cf0974632fd7b7aefb500e7b43/library/foundation.php#L103

Soy +1 por add_theme_support también. Empezaré con esto ahora. Mi plan es seguir asignando las clases en el editor, pero solo cargar los estilos para los temas que se inscriben. De esa manera, no romperán nada al estar allí, los temas pueden optar y usar nuestros estilos, o los temas pueden usarlos para aplicar lo suyo, o ignorarlos totalmente si así lo desean.

Encontré este hilo después de tratar este problema en varios sitios. Simplemente eliminar las clases de CSS adicionales agregadas automáticamente solucionó el problema, al igual que forzar el bloque "incrustado" a no convertirse automáticamente en un bloque de YouTube o Vimeo, ya que esas clases no están en el bloque incrustado estándar.

Estoy usando un tema personalizado basado en veinte catorce.
La solución funciona para el problema del espacio, pero rompió el CSS global.
Así que todavía necesito eliminar la clase adicional css para videos de youtube.
:-)

PR está en revisión que agrega una opción de tema responsive-embeds , https://github.com/WordPress/gutenberg/pull/10477

Hola, ¿el PR # 10477 se convertirá en un lanzamiento completo? Encontré este problema con las páginas de WordPress incrustadas (como incrustar las URL del directorio de un complemento de WordPress en una página como en mi página aquí: https://suburbia.org.uk/projects), tuve que deshabilitar manualmente la capacidad de respuesta en todas las incrustaciones de esta página para evitar que aparezca un espacio debajo de ellas. Pero parece que esta configuración de respuesta predeterminada es incorrecta al menos para este tipo de página incrustada, al menos en el tema estándar de 2017 de todos modos, por lo que sería bueno deshabilitar esto globalmente si es posible.

@rickcurran sí, esto será parte de la versión 4.1 próximamente.

Este error no está arreglado:

Tengo el mismo problema incluso cuando vuelvo a Twenty Nineteen y agrego un bloque YT.

¿Por qué WordPress insiste en insertar wp-embed-aspect-4-3-cada vez que actualizo una publicación que contiene un video de YouTube? Sigo teniendo que hackearlo manualmente todo el tiempo. Muy molesto. Quiero wp-embed-aspect-16-9 y nunca 4-3

¿Podrías publicar los enlaces de los videos de YouTube que estás incorporando y los temas que estás usando? Puedo investigar.

He visto que esto sucede con cada video de youtube con cada tema. Por lo tanto, no puede ser un video o un tema específico.

@scottwyden No

¿Qué versión de WordPress estás usando? ¿Está instalando el complemento de Gutenberg o está utilizando la versión incluida con WordPress?

Pruébelo con cualquier cosa que no sea un tema Automático / predeterminado.

@scottwyden Probé con el tema Flat Responsive, no veo el problema.

¿Qué versión de WordPress estás usando? ¿Está instalando el complemento de Gutenberg o está utilizando la versión incluida con WordPress?

Creo que el problema podría haberse solucionado en WP 5.2.1 Alpha. Puedo replicarlo con todos los temas usando 5.2 pero se ha ido en 5.2.1.

Parece que me he encontrado con el mismo problema.
Ejecutando WordPress 5.2.1 con el tema Cookd Pro Theme. Usando Génesis 2.10.1. Usando el editor de "bloques" de Gutenberg.
No soy un codificador, pero por lo que veo, el iframe parece estar configurando la relación 472x745. No sé si es algún tema o complemento el que lo está configurando.
No tuve este problema al actualizar a Gutenberg. ¿Algún consejo sobre cómo puedo solucionarlo?

Hola, yo también estoy enfrentando este problema y estoy usando el tema OceanWP. Este es el HTML cuando inserto un video de YouTube:

<figure class="wp-block-embed-youtube wp-block-embed is-type-video is-provider-youtube wp-has-aspect-ratio wp-embed-aspect-16-9"><div class="wp-block-embed__wrapper">
https://www.youtube.com/watch?v=HAzNm6lxNV8
</div></figure>

El espacio desaparece si elimino wp-embed-aspect-16-9 . Cada vez que actualizo, esto se vuelve a agregar y el espacio aparece nuevamente. ¿Existe alguna solución permanente para esto?

Las clases de relación de aspecto solo se aplican si el tema dice que admite incrustaciones receptivas, por lo que me parecería que es un problema de tema, pero citando a @jasmussen en esto porque él sabe más sobre CSS que yo sobre este y es más probable que detecte lo que está sucediendo.

El complemento Jetpack también tiene algo de magia para hacer que los videos respondan. Pero creo que el error que los hacía "responder doblemente" se solucionó hace un tiempo. ¿Podría ser que esté ejecutando una versión anterior del complemento Jetpack?

No estoy usando el complemento Jetpack

Pasé una cantidad significativa de tiempo depurando esto en el lado del tema y el complemento, solo para descubrir que el propio proveedor oEmbed era el que proporcionaba el código de respuesta que luego fue duplicado por Gutenberg. Aquí hay dos respuestas de Vimeo para diferentes videos (editados hasta solo la propiedad html ):

{
  "html": "<div style=\"padding:56.25% 0 0 0;position:relative;\"><iframe src=\"https://player.vimeo.com/video/123?app_id=789\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" frameborder=\"0\" allow=\"autoplay; fullscreen\" allowfullscreen></iframe></div><script src=\"https://player.vimeo.com/api/player.js\"></script>",
}

{
  "html": "<iframe src=\"https://player.vimeo.com/video/456?app_id=789\" width=\"640\" height=\"360\" frameborder=\"0\" allow=\"autoplay; fullscreen\" allowfullscreen></iframe>",
}

(He anonimizado los videos de mi cliente).

El primero agrega sus propios estilos receptivos como atributos y el segundo no lo hace. Yo diría que los estilos se agregan para alrededor del 20% de los videos de mis clientes.

Siendo ese el caso, creo que la única solución es una versión del CSS publicado por @jasmussen . Terminé usando esto:

.wp-block-embed__wrapper > div {
    padding: inherit !important;
    position: static !important;
}

No me entusiasma usar !important , pero no estoy seguro de que haya otra forma. Obviamente, podría entrenar a mi cliente para que elimine las clases de relación de aspecto dentro de Gutenberg en los videos que se cargan con una gran brecha arriba, pero también me preocupa la posibilidad de que el contenido de la respuesta oEmbed pueda cambiar con el tiempo, en cuyo caso una brecha podría aparecer más tarde.

el propio proveedor oEmbed fue el que proporcionó el código de respuesta que luego fue duplicado por Gutenberg

Oh ... maravilloso :( así que si los proveedores están _a veces_ haciendo su propia respuesta, entonces necesitamos detectar cuándo está sucediendo y desactivar los estilos de respuesta de Gutenberg _ para esa inserción_. Supongo que podríamos analizar el html y ver si alguno de los los elementos tienen una posición relativa aplicada ...?

@gregsullivan ¡ gracias por ver esto!

¡De nada, @notnownikki! Se me ocurrió que esto podría estar sucediendo en tres niveles en el lado de oEmbed:

• CSS en línea que se agrega directamente al HTML, como se muestra arriba
• CSS en línea que se agrega mediante un archivo JavaScript incluido en la respuesta oEmbed
• Una clase HTML que responde mediante un archivo CSS incluido en la respuesta oEmbed

Comencé a preguntarme si tendría sentido usar JavaScript para verificar y eliminar el estilo receptivo en elementos que descienden de .wp-block-embed__wrapper , pero no estoy seguro de cuán factible es, y probablemente introduciría destellos de espacio vacío en el momento antes de que se eliminen los estilos.

¡Definitivamente no es un problema fácil de resolver!

¡Definitivamente no es un problema fácil de resolver!

¡En efecto!

Entonces, la forma en que probablemente abordaría esto es cuando recibamos un nuevo grupo de HTML de vista previa, el estado establecido que dice que lo estamos verificando para la capacidad de respuesta proporcionada por el proveedor, y no renderizamos la vista previa hasta que se complete la verificación. Luego analizamos el HTML y recorremos el DOM buscando la capacidad de respuesta proporcionada por el proveedor (o tal vez lo renderizamos en un iframe y observamos los cambios del DOM para ver qué está pasando ... tal vez para la primera iteración simplemente analizamos el HTML y recorremos el DOM). Una vez que hayamos hecho eso, sabemos si necesitamos deshabilitar la capacidad de respuesta para ese bloque de inserción o no, configuramos el estado para que diga "respuesta comprobada" y luego la vista previa se mostraría sin parpadear.

¡Eso tiene sentido para mí!

¿Ve un enfoque que evitaría problemas en el front-end si los proveedores de oEmbed cambiaran el HTML que proporcionan (ya sea comenzando como no receptivo y volviéndose receptivo, o viceversa)?

Oh cielos.

luego debemos detectar cuándo está sucediendo y desactivar los estilos de respuesta de Gutenberg para esa inserción

Entonces, los proveedores de inserción a veces también cambian sus íconos, y dado que incluimos íconos, eso significa que también necesitamos actualizarlos. Este es uno de los desafíos que más o menos asumimos cuando decidimos tener proveedores de inserción separados explícitos en una lista blanca, en lugar de ser más genéricos en el enfoque.

En ese sentido, si pudiéramos _detectar automáticamente_ estas cosas, sería genial. Pero si eso no es posible, ¿tendría sentido simplemente crear una lista en lugar de incorporar proveedores que brinden su propia capacidad de respuesta y omitir aquellos del tratamiento del editor de bloques?

¿Ve un enfoque que evitaría problemas en el front-end si los proveedores de oEmbed cambiaran el HTML que proporcionan (ya sea comenzando como no receptivo y volviéndose receptivo, o viceversa)?

Tendríamos que incluir la misma detección en el front-end que hacemos en el backend. No estoy seguro de que queramos hacer eso, o incluso si es una buena idea. Podríamos terminar con condiciones de carrera y scripts peleando entre sí, lo que en el _editor_ es un poco ... asqueroso no romper el sitio. Sin embargo, en la parte delantera, inaceptable.

En ese sentido, si pudiéramos detectar automáticamente estas cosas, sería genial. Pero si eso no es posible, ¿tendría sentido simplemente crear una lista en lugar de incorporar proveedores que brinden su propia capacidad de respuesta y omitir aquellos del tratamiento del editor de bloques?

_Podría haber alguna forma inteligente de CSS en la que podamos anular el relleno de respuesta del proveedor y solo hacer que _nuestro_ surta efecto. Esa es una pregunta para ti realmente @jasmussen, pero mi sensación es que podríamos terminar rompiendo más cosas sin darnos cuenta si seguimos ese camino.

Si los proveedores están comenzando a incluir su propia capacidad de respuesta, entonces sí, este parece el camino a seguir. No estoy seguro de por qué algunos videos lo obtienen y otros no cuando los videos provienen del mismo proveedor; ¿podría ser algún tipo de prueba A / B? Pero si esa es la forma en que se mueven, entonces sí, simplemente registre los bloques con responsive: false y deje que los proveedores hagan lo suyo.

¿Podría haber alguna forma inteligente de CSS en la que podamos anular el relleno de respuesta del proveedor y solo haga que el nuestro tenga efecto? Esa es una pregunta para ti realmente @jasmussen, pero mi sensación es que podríamos terminar rompiendo más cosas sin darnos cuenta si seguimos ese camino.

Tuve el mismo pensamiento cuando esperábamos poder implementar esto sin optar por participar. Y lo hice funcionar, para uno de esos métodos. Pero el problema es que hay varias formas diferentes de construir la capacidad de respuesta y, desafortunadamente, si tuviera que apuntar a todas ellas, muy probablemente tocaría selectores y elementos que no debería. Desafortunadamente, ya no tengo tanta confianza en ese enfoque.

Creo que puede tener razón, podría ser una prueba A / B, o incluso podría ser algo que suceda solo para nuevas incorporaciones o algo por el estilo. ¿Quizás una solución provisional es actualizar el texto de ayuda aquí para explicar los casos en los que es posible que desee desactivarlo?

Una nota más aquí: Vimeo parece estar rompiendo la especificación de oEmbed con estos estilos. Esto es lo que html en 2.3.4.2 (el tipo video ):

El HTML necesario para insertar un reproductor de video. El HTML no debe tener relleno ni márgenes. Los consumidores pueden querer cargar el HTML en un iframe fuera del dominio para evitar vulnerabilidades XSS.

(El énfasis es mío.)

Le pedí a mi cliente acceso a su cuenta de Vimeo; tal vez pueda tener una idea de qué está activando los estilos receptivos en algunos videos y no en otros. Sé que no es nuevo contra viejo, como sucedió en videos muy recientes, así como en videos de más de tres años.

Entre la documentación de Vimeo y el acceso a la cuenta de mi cliente, creo que tengo un control decente sobre la causa de la variación entre videos.

La documentación del código de inserción de Vimeo tiene una sección "Inserciones receptivas" que dice lo siguiente:

Es posible que el código de respuesta no se adapte bien a ciertos temas y diseños de páginas web. Si tiene problemas con el código de inserción receptivo, le recomendamos que cambie de nuevo al código de inserción de tamaño fijo.

Entonces, si obtiene el código de inserción manualmente, el código de respuesta se activa al elegir entre "Responsive" y "Fixed Size" en la superposición "Share this Video".

La documentación también dice que el uso de Vimeo Cards hace que la inserción siempre responda. Este no es un problema con el que me encontré, pero pude ver que es un problema para otros.

La documentación de oEmbed de Vimeo dice que el valor predeterminado es para una

No puede anular la configuración predeterminada del video cuando el nivel de membresía del propietario del video es superior a Vimeo Basic. (Consulte el campo account_type en la respuesta de oEmbed para determinar esta información).

Mi cliente tiene una cuenta de Vimeo Pro. En su cuenta, los videos configurados como "Sin ajuste preestablecido" tenían los estilos de respuesta agregados, mientras que su ajuste preestablecido personalizado establece un tamaño de 640 × 360. Ocasionalmente se olvidan de seleccionar el ajuste preestablecido, y son esos videos los que tenían los estilos de respuesta y el correspondiente vacío espacio encima de ellos.

En conclusión: los videos alojados en cuentas de Vimeo Pro sin tamaños fijos establecidos para su inserción (y los videos que usan tarjetas de Vimeo) siempre enviarán estilos receptivos cuando se soliciten a través de oEmbed.

No estoy seguro de cuán factible es esto, pero tal vez tener WP_Embed crear un código de inserción simplificado para Vimeo usando las propiedades width , height y video_id sea ​​la solución más limpia. Algo como:

<iframe src="https://player.vimeo.com/video/${video_id}" width="${width}" height="${height}" frameborder="0" allow="autoplay; fullscreen" allowfullscreen></iframe>

Gracias por la excelente investigación, esto es excepcionalmente útil.

No estoy seguro de cuán factible sea esto, pero quizás hacer que WP_Embed cree un código de inserción simplificado para Vimeo usando las propiedades width, height y video_id sería la solución más limpia.

Quizás haya una pregunta más importante en torno a la UX para las incrustaciones receptivas, dado que técnicamente cualquier proveedor de Oembed podría cambiar su marcado a voluntad. El hecho de que las incrustaciones receptivas en el editor de bloques sean opcionales y usted pueda optar por no participar en cada incrustación es un buen comienzo. Pero me pregunto cuáles son los mejores pasos siguientes.

• Una lista blanca de incrustaciones de buena respuesta conocidas está en la línea de lo que sugirió, con una excepción para Vimeo. Suena como si fuera un juego de golpear un topo intentar detectar estas cosas de una manera genérica.
• Mejores descripciones e información en la barra lateral de configuración del bloque. Quizás incluso considere mover el botón "Cambiar tamaño para dispositivos más pequeños" en el bloque de video seleccionado en lugar de tenerlo en la barra lateral.

Pregunta de @gregsullivan : ¿la

@jasmussen La

Por un lado, estoy 100% de acuerdo con la caracterización de whack-a-mole. Por otro lado, tengo curiosidad por saber si los servicios que implementan oEmbed tenderían a ver que el cambio de relleno que causa el problema rompe las especificaciones, lo que hace que el problema sea más raro.

Otra posibilidad: ¿Existe la voluntad de reescribir el CSS responsable de las inserciones receptivas? Lo probé e hice una versión que funciona para ambos estilos de salida de Vimeo. Si cree que vale la pena seguir esto, podría probarlo en más incrustaciones para garantizar la compatibilidad y luego compartirlo con usted.

Requiere algún uso de !important avíseme si eso es un factor decisivo.

Un mejor CSS es absolutamente una opción, y sugeriría que se creó! Important para casos de uso como este. Dependiendo de la solución que tenga en mente, no puedo estar seguro de si funcionará, ¡pero estaría emocionado de ver su solución! Gracias de nuevo.

¡Suena bien! Los actualizaré cuando tenga algo más adelante para mostrarles.

Una pregunta relacionada: ¿Las incrustaciones están diseñadas para admitir 9:16, 9: 6 o ambos?

Si es 9: 6, creo que hay un error tipográfico aquí:

https://github.com/WordPress/gutenberg/blob/429558ad320c55e3e8b5236dfb6ce139fa3a7d25/packages/block-library/src/embed/style.scss#L25

Si es 9:16, creo que esto debería cambiarse:

https://github.com/WordPress/gutenberg/blob/429558ad320c55e3e8b5236dfb6ce139fa3a7d25/packages/block-library/src/embed/style.scss#L66 -L68

Según el orden, parece que las líneas 66 a 68 deberían ser:

&.wp-embed-aspect-9-16 .wp-block-embed__wrapper::before {
    padding-top: 177.77%; // 16 / 9 * 100
}

(Todos los valores padding-top están ascendiendo hasta ese, y potencialmente tendría sentido admitir 16: 9 en orientación vertical, así que esa es mi suposición de lo que se supone que debe suceder).

Lo siento si esto debería ser un problema aparte. Avísame si crees que tiene sentido hacer una solicitud de extracción solo para esto.

Es muy posible que haya un error tipográfico. Y sí, siéntase libre de abrir un ticket si lo desea, puede hacer referencia a este y enviarme un CC (@jasmussen) y lo seguiré. Sin embargo, ahora me voy de vacaciones, por lo que es posible que no pueda probar su código, pero ciertamente podré hacer ping a alguien que pueda hacerlo.

¡Muchas gracias! Seguí adelante e hice una solicitud de extracción para el error tipográfico de relación de aspecto: # 16573

¡Disfruta tus vacaciones!

Hola @jasmussen @gregsullivan, lamentablemente mi sitio web también parece tener problemas con espacios en blanco.

Estoy usando el tema Sydney junto con Visual composer. Todo está actualizado, pero después del cambio de Gutenberg, parece que no puedo eliminarlo.

El código CSS que proporcionaste no parece funcionar para mí. Espero que me puedan ayudar:
https://www.jessejoeyjames.com/portfolio/

@jessejoeyjames El CSS anterior es específico del editor de bloques integrado de WordPress. Parece estar encontrando un conflicto entre Visual Composer y FitVids.js . Tendría que averiguar qué complemento o tema incluye este último para resolver el conflicto.

@gregsullivan Gracias por responder tan rápido. No tengo idea de cómo lo descubriste tan rápido, pero busqué Fitvids en combinación con mi SydneyTheme. Y el tema de hecho parece estar usando Fitvids.js

¿Se supone que debo ponerme en contacto con el tema de Sydney o simplemente puedo eliminar los fitvids yo mismo?

EDITAR:
Bien, lo arreglé agregando este código a la parte de personalizar CSS en wordpress

.vce-yt-video-player-inner :: before {
padding-top: 0! important;
}

Por favor, avíseme si esto está bien, supongo que debería haber una solución adecuada. Solo soy un programador muy promedio con conocimientos básicos de php, css, html. Pero acabo de probar esto como una combinación del código de

@jessejoeyjames Te sugiero que te

@jasmussen @notnownikki Tengo otra actualización (potencialmente final) sobre esto, ya que mi sensación es que este es un caso aún más extremo de lo que pensé inicialmente.

Para probar posibles correcciones de CSS, agregué un gancho a oembed_fetch_url para obligar a Vimeo a enviar incrustaciones receptivas si ?responsive se agregó como una cadena de consulta a la URL de Vimeo.

Al hacerlo, descubrí que las comprobaciones preexistentes a continuación evitan con éxito que la inserción se marque como receptiva:

https://github.com/WordPress/gutenberg/blob/62439f083c5710ccc5a87187fa5c66a83c70b41f/packages/block-library/src/embed/util.js#L152 -L168

(La inserción receptiva de Vimeo elimina el ancho y la altura de su iframe y, en su lugar, le da un padding-top al contenedor div para crear la relación de aspecto deseada).

Entonces, para que ocurra el problema de doble respuesta en este caso, la inserción debe cambiar con el tiempo, generando la versión receptiva después de generar inicialmente la versión no receptiva.

Descubrí que una revisión menor del CSS incrustado resolvería el problema y funcionaría tanto para incrustaciones existentes como para la incrustación de Vimeo receptiva, pero no sé si justifica una solicitud de extracción dado que es relativamente difícil desencadenar el problema. Supongo que un argumento a favor del cambio sería que alguien podría agregar las clases receptivas a un incrustado de Vimeo receptivo que inicialmente se cargó sin ellos, y funcionarían sin activar la doble respuesta.

¡Hola!
Tengo este problema con Vimeo. Con Youtube parece que no agrega el espacio, pero la vista previa aparece recortada de manera extraña, y cuando reproduzco el video, se muestra en sus proporciones originales, pero en la forma que tenía la vista previa. Entonces, en mi computadora, tal vez veo un cuadrado y luego un video de 16: 9. Pero en mi móvil hay una vista previa de 9:16, y luego un pequeño video de 16: 9 en el medio.

¿Hay alguna novedad sobre esto? También le informé a mi tema (DIVI) el problema para ver si debían hacer algo.

Añado algunas instantáneas como ejemplo.

Este problema aún existe, tengo un WP actualizado y hoy 07.11.19 tengo este problema en mi sitio.
Esta es mi primera incrustación de YouTube, así que no sé cómo funcionaba antes.
De todos modos, la eliminación del wp-embed-aspect-4-3 del código también funcionó aquí.

Tuve el mismo problema, desde el complemento gratuito de Youtube. Configuración de YouTube> valores predeterminados> Al anular la selección de "tamaño de video adaptable" se solucionó el problema. Parece que agrega una envoltura de video de ancho fluido con una gran cantidad de relleno cuando se marca. (Puede entrar en conflicto con algunos estilos de temas o complementos aplicados en otros lugares).

Fitvids tiene una opción para excluir ciertas clases de CSS.
Si puede editar el js sin piratear nada (o el tema / complemento que usa fitvids le permite agregar opciones), entonces puede usar las opciones para excluir las incrustaciones de Gutenberg.
El mío se ve así ahora:

jQuery(".container").fitVids({
        ignore: '.wp-block-embed'
    });

Si lo elimina por completo, es posible que los videos incrustados en otro lugar ya no respondan.