Ambos sitios definitivamente tienen etiquetas OG válidas. Las fuentes de las imágenes son cuadradas. No especificamos las dimensiones de la imagen en las etiquetas OG.
El ejemplo anterior funciona bien en el depurador de compartir de Facebook y en iFramely. Haz clic en el enlace a continuación para verlo en iFramely.
He revisado toda la configuración de onebox e imágenes, pero no veo nada que parezca relevante.
He revisado las guías de solución de problemas y configuración de onebox aquí, pero nada ayudó.
Creo que tiene que ser algo en nuestra configuración de Discourse, o en Discourse mismo.
Veamos cómo se ve ese enlace en esta instancia de Discourse:
Cuando pegué eso, el onebox en la vista previa mostró brevemente la imagen con la relación de aspecto correcta. Uno o dos segundos después, se aplastó.
Por lo tanto, lo que sea que esté sucediendo no se limita a nuestra instancia de Discourse. Supongo que podríamos necesitar especificar las dimensiones de la imagen en las etiquetas OG, pero no pensé que eso fuera necesario.
Informe de estado: esto sigue ocurriendo. Cuando pego un enlace en un nuevo tema, inicialmente la imagen asociada se ve bien en la vista previa. Pero tan pronto como presiono Enter o la barra espaciadora, la imagen se aplasta. Revisé nuevamente los pasos de solución de problemas de onebox y volví a revisar todas las configuraciones anuladas, sin éxito. Esto es una locura.
Ese CSS podría considerarse subóptimo o ser algún tipo de compromiso. Estoy deprisa, pero quizás actualmente esté forzando 16:9. No es genial para logotipos cuadrados
Me pregunto si la altura podría establecerse en automático (aunque eso podría presentar desafíos para imágenes en formato vertical)
¿A qué CSS te refieres? Quiero decir, puede que tengas razón, pero estoy intentando determinar si es algo que puedo arreglar en nuestra instancia de Discourse, o si es algo en el código fuente de Discourse.
Creo que el error aquí es que si el tipo es “rich” y no estamos capturando toda la presentación del payload html de oembed, deberíamos omitir la adición de dimensiones, ya que no nos interesa esta información.
Esto lo soluciona:
diff --git a/lib/onebox/engine/standard_embed.rb b/lib/onebox/engine/standard_embed.rb
index e3175d6247..fc8c300d81 100644
--- a/lib/onebox/engine/standard_embed.rb
+++ b/lib/onebox/engine/standard_embed.rb
@@ -159,8 +159,9 @@ module Onebox
@json_ld ||= Onebox::JsonLd.new(html_doc)
end
- def set_from_normalizer_data(normalizer)
+ def set_from_normalizer_data(normalizer, skip_dimensions: false)
normalizer.data.each do |k, _|
+ next if skip_dimensions && k.in?(%i[width height])
v = normalizer.public_send(k)
@raw[k] ||= v unless v.nil?
end
@@ -179,7 +180,8 @@ module Onebox
def set_oembed_data_on_raw
oembed = get_oembed
- set_from_normalizer_data(oembed)
+ skip_dimensions = oembed.data[:type] == "rich"
+ set_from_normalizer_data(oembed, skip_dimensions:)
end
def set_json_ld_data_on_raw
Sin embargo, no estoy seguro de qué otros efectos secundarios tendría esto, informando al equipo de experiencia de miembro que lo revisará durante el próximo mes.
Soy reacio a simplemente agregar mi parche porque hay muchas capas aquí y complejidad, alguien necesita asegurarse de que podamos agregar el parche de una manera muy segura y probada.
Esto es pri-medium porque el impacto de este error es bastante amplio dado que wp-json lo expone.
¡Genial! Esos datos oembed parecen ser la clave. Curiosamente, la documentación de Wordpress (software) solo habla de oembed en términos de que los sitios de Wordpress incrustan contenido de otros sitios, no al revés. Sin embargo, la documentación de wordpress.com (servicio) dice “Cada publicación, página, adjunto y video de VideoPress alojado en WordPress.com admite el formato oEmbed a través de nuestra API pública de oEmbed”. Por lo tanto, es seguro asumir que el software de Wordpress hace esto por defecto.
Revisé todas las configuraciones de Wordpress y no pude encontrar nada relacionado con oembed, por lo que parece que cualquier suposición hecha por Wordpress está integrada en el código.
La API de oembed de Wordpress también explica por qué no hay ninguna referencia a las dimensiones 600/338 en ninguna parte del código fuente de la página, lo cual me pareció desconcertante anteriormente.
Estoy de acuerdo en que cualquier posible solución para esto en Discourse puede tener muchos efectos secundarios (posiblemente no deseados) y debe probarse antes de ser lanzada.
Además, ni siquiera estoy seguro de que este sea un problema de Discourse. La dimensión errónea ‘338’ proviene de Wordpress. Me parece que debería haber una manera en Wordpress de anular los valores predeterminados relacionados con oembed como este. Planeo buscar un plugin de Wordpress que permita un mayor control sobre oembed.
