facebook - example - FB OpenGraph og: la imagen no extrae imágenes(¿posiblemente https?)

og:image (18)

Además, este problema también se produce cuando agrega una historia generada por el usuario (donde no usa og: image). Por ejemplo:

POST /me/cookbook:eat? recipe=http://www.example.com/recipes/pizza/& image[0][url]=http://www.example.com/recipes/pizza/pizza.jpg& image[0][user_generated]=true& access_token=VALID_ACCESS_TOKEN

Lo anterior solo funcionará con http y no con https. Si usa https, recibirá un error que dice: No se pudo cargar la imagen adjunta ()

Primero, no creo que esto sea un problema duplicado. He buscado problemas iguales o similares en SO ampliamente, y debido a la naturaleza de la solución de problemas antes de preguntar, creo que este problema es único.

Facebook no puede captar mis archivos de og:image y he intentado todas las soluciones habituales. Estoy empezando a pensar que podría tener algo que ver con https://...

He comprobado http://developers.facebook.com/tools/debug y no tengo advertencias ni errores.
Es encontrar las imágenes a las que enlazamos en " og:image ", pero se muestran en blanco. Cuando hacemos clic en la (s) imagen (es), sin embargo, SÍ existen y se lleva directamente a ellas.
Se muestra una imagen: una imagen alojada en un servidor que no es https.
Hemos probado imágenes cuadradas, jpegs, pngs, tamaños más grandes y tamaños más pequeños. Hemos puesto las imágenes directamente en public_html. Cero están apareciendo.
No es un error de almacenamiento en caché, porque cuando agregamos otra og:image a la meta, la guía de FB encuentra y lee eso. Se muestra una vista previa. La vista previa está en blanco. La única excepción que obtenemos es para imágenes que no se encuentran en este sitio web.
Pensamos que tal vez había algo de anti-lixiviación en cpanel o el .htaccess que impedía que las imágenes se mostraran, así que lo comprobamos. No había. Incluso hicimos un < img src="[remote file]" > rápido en un servidor completamente diferente y la imagen se ve bien.
Pensamos que tal vez era la og:type u otra rareza con otra etiqueta meta. Los quitamos todos, uno a la vez, y lo revisamos. Ningún cambio. Sólo advertencias.
El mismo código en un sitio web diferente aparece sin ningún problema.
Pensamos que tal vez no estaba obteniendo imágenes porque estamos usando las mismas páginas de productos para varios productos (cambiándolos en función del valor de obtención, es decir, "details.php? Id = xxx"), pero aún se está procesando una. imagen (de una url diferente).
Al dejar og:image o image_src desactivado, FB no encuentra ninguna imagen.

Estoy al final de mi cuerda. Si dijera cuánto tiempo y otras personas han dedicado a esto, te sorprenderías. El problema es que esta es una tienda en línea. Absolutamente, positivamente no podemos tener imágenes. Tenemos que. Tenemos una decena de otros sitios ... Este es el único con og:image problemas de og:image . También es el único en https , así que pensamos que tal vez ese era el problema. Pero no podemos encontrar ningún precedente en ninguna parte de la web para eso.

Estas son las meta-etiquetas:

En caso de que lo desee, aquí hay un enlace a una de nuestras páginas de productos en las que hemos estado trabajando. [El enlace se acortó para intentar frenar este ingreso en los resultados de búsqueda de nuestro sitio]: http://rockn.ro/114

EDITAR ----

Usando la herramienta de raspado "vea lo que Facebook ve", pudimos ver lo siguiente:

"image": [ { "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-details-safari.png" }, { "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-art-safari.png" }, { "url": "http://www.[theotherNONSECUREwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png" } ],

Probamos todos los enlaces que se encuentran en una sola página. Todas eran imágenes perfectamente válidas.

EDITAR 2 ----

Probamos una prueba y agregamos un subdominio al sitio web de NONSECURE (desde el cual las imágenes son realmente visibles a través de facebook). El subdominio era http: // img. [Nonsecuresite] .com. Luego colocamos todas las imágenes en la carpeta del subdominio principal y las referenciamos. No tiraría esas imágenes en FB. Sin embargo, aún extraerá cualquier imagen a la que se haga referencia en el dominio principal no seguro.

SOLUCIÓN DE TRABAJO PUBLICADA ----

Gracias a Keegan, ahora sabemos que esto es un error en Facebook. Para solucionar el problema, colocamos un subdominio en un sitio web diferente que no es HTTPS y volcamos todas las imágenes en él. Hicimos referencia a la imagen de coordinación http://img.otherdomain.com/[like-image.jpg] en og:image en cada página del producto. Luego tuvimos que pasar por FB Linter y ejecutar CADA enlace para actualizar los datos OG. Esto funcionó, pero la solución es una solución alternativa, y si se soluciona el problema de https y volvemos a usar el dominio https natural, FB habrá guardado las imágenes de un sitio web diferente, lo que complica las cosas. Esperemos que esta información ayude a salvar a otra persona de perder 32 horas de codificación de su vida.

Algunas propiedades pueden tener metadatos adicionales adjuntos. Estos se especifican de la misma manera que otros metadatos con property y content , pero la property tendrá extra:

La propiedad og:image tiene algunas propiedades estructuradas opcionales:

og:image:url - Idéntico a og: image.
og:image:secure_url - Una URL alternativa para usar si la página web requiere HTTPS.
og:image:type - Un tipo MIME para esta imagen.
og:image:width : el número de píxeles de ancho.
og:image:height - El número de píxeles de altura.

Un ejemplo de imagen completa:

<meta property="og:image" content="http://example.com/ogp.jpg" /> <meta property="og:image:secure_url" content="https://secure.example.com/ogp.jpg" /> <meta property="og:image:type" content="image/jpeg" /> <meta property="og:image:width" content="400" /> <meta property="og:image:height" content="300" />

Por lo tanto, debe cambiar la propiedad og:image para sus URL de HTTPS a og:image:secure_url

Ex:

TAG META HTTPS PARA IMAGEN:

<meta property="og:image:secure_url" content="https://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

TAG META HTTP PARA IMAGEN:

<meta property="og:image" content="http://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

Fuente: http://ogp.me/#structured <- Puede visitar este sitio para obtener más información.

Espero que esto te ayude.

EDITAR: No olvide hacer ping a los servidores de Facebook después de actualizar sus códigos - URL Linter

Como lo encontré accidentalmente, la imagen en blanco transparente viene con un encabezado de respuesta que indica la posible causa del problema.

Vaya al depurador en https://developers.facebook.com/tools/debug/og/object/
Pon tu URL
En la parte inferior, facebook muestra tu "imagen" (GIF transparente 1x1)
1. La imagen está vinculada a su imagen original, no hay punto que la presione.
2. Presione a la derecha y vea la imagen (obtendrá algo como https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=... )
Active la pestaña Red en las herramientas de firebug / developer, actualice la página si es necesario
Obtendrás el encabezado de respuesta de x-error-detail con una explicación

Por ejemplo, en mi caso era una Invalid image extension for URL: https://[mydomain]/[myfilename].jpg

El problema real en mi caso estaba relacionado con prerender.io .

Resulta que, si la imagen se solicita a través de Prerender, se convierte a HTML. Algo como esto:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <html> <head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head> <body style="margin: 0px;"><img style="-webkit-user-select: none; cursor: -webkit-zoom-in; " src="https://[yourdomain].com/[yourfilename].jpg" width="1078" height="718"></body> </html>

Es un error en el prerender en sí mismo o se supone que está configurado en su proxy para no usar el prerender para las solicitudes *.jpg (incluso si el bot de Facebook las solicita).

Es muy difícil darse cuenta de esto, ya que Prerender se usa solo en ciertos encabezados de agente de usuario.

Descubrí otro escenario que puede causar este problema. Pasé por todos los pasos descritos en la pregunta y en las respuestas, aún quedaba el problema.

Revisé mis imágenes y descubrí que algunas de mis publicaciones tenían imágenes en miniatura demasiado grandes en og:image en el rango de varios miles de píxeles y varios megabytes.

Esto sucedió debido a la reciente migración de WP a Jekyll, optimicé mis imágenes con un trago, pero usé las imágenes originales en og: image por error.

Facebook nos da las siguientes recomendaciones a partir de hoy :

Utilice imágenes que tengan al menos 1200 x 630 píxeles para obtener la mejor visualización en dispositivos de alta resolución. Como mínimo, debe usar imágenes de 600 x 315 píxeles para mostrar publicaciones de páginas de enlace con imágenes más grandes. Las imágenes pueden ser de hasta 8 MB de tamaño.

Así que hay un límite superior de 8MB.

Después de varias horas de probar y probar cosas ...

Resolví este problema lo más simple posible. Observo que usan "páginas de prueba" dentro de la página de desarrolladores de Facebook que contiene solo las etiquetas "og" y un poco de texto en la etiqueta del cuerpo que hace referencia a estas etiquetas og

Entonces, ¿qué he hecho?

Creé una segunda vista en mi aplicación, que contiene las mismas cosas que usan.

¿Y cómo sé que Facebook está accediendo a mi página para que pueda cambiar la vista? Tienen un agente de usuario único: "facebookexternalhit / 1.1"

En mi caso, el problema estaba en no proporcionar el certificado raíz de CA. Lo descubrí después de usar: https://www.ssllabs.com/ssltest/analyze.html para analizar la configuración SSL.

Llegué aquí desde Google, pero esto no fue de mucha ayuda para mí. Resultó que hay una relación de aspecto mínima de 3: 1 requerida para el logotipo. El mío era casi 4: 1. Usé Gimp para recortarlo exactamente a 3: 1 y listo, mi logotipo ahora se muestra en FB.

Me encontré con el mismo problema y lo reporté como un error en el sitio de desarrolladores de Facebook. Parece bastante claro que los URI og: image que usan HTTP funcionan bien y los URI que usan HTTPS no. Ahora han reconocido que están "investigando esto".

El error se puede ver aquí: https://developers.facebook.com/bugs/260628274003812

Me encontré con el mismo problema y luego noté que tenía un dominio diferente para el og:url

Una vez me aseguré de que el dominio fuera el mismo para og:url y og:image , funcionó.

Espero que esto ayude.

No olvides actualizar los servidores a través de:

Depurador de facebook

Y haga clic en "Recopilar nueva información"

No sé, si es solo conmigo, pero para mí og:image no funciona y elige el logotipo de mi sitio, aunque el depurador de Facebook muestre la imagen correcta.

Pero cambiando og:image por og:image:url funcionó para mí. Espero que esto ayude a alguien más a enfrentar un problema similar.

Para mí esto funcionó:

<meta property="og:url" content="http://yoursiteurl" /> <meta property="og:image" content="link_to_first_image_if_you_want" /> <meta property="og:image" content="link_to_second_image_if_you_want" /> <meta property="og:image:type" content="image/jpeg" /> <meta property="og:image:width" content="400" /> <meta property="og:image:height" content="300" /> <meta property="og:title" content="your title" /> <meta property="og:description" content="your text about homepage"/>

Por lo que observé, veo que cuando su sitio web es público y aunque la URL de la imagen es https, funciona bien.

Puedo ver que el depurador está recuperando 4 og:image etiquetas de og:image de su URL.

La primera imagen es la más grande y, por lo tanto, tarda más en cargarse. Intente reducir la primera imagen hacia abajo o cambie el orden para mostrar primero una imagen más pequeña.

Síntomas similares (Facebook y otros no obtienen correctamente og: image y otros activos a través de https) pueden ocurrir cuando el certificado https del sitio no cumple con todos los requisitos.

El certificado https de su sitio puede parecer válido (clave verde en el navegador y todo), pero no se raspará correctamente si falta un certificado intermedio o de cadena. Esto puede llevar a muchas horas desperdiciadas comprobando y volviendo a comprobar todos los distintos cachés y etiquetas meta.

Podría no haber sido su problema, pero podría ser otro con síntomas similares (como el mío). Hay muchas formas de verificar su certificado: la que yo usé: https://www.sslshopper.com/ssl-checker.html

Tuve el mismo error y nada de lo anterior me ayudó, así que intenté seguir la documentación original del ogp.me y agregué el atributo de prefijo a mi etiqueta html y todo se volvió increíble.

<html prefix="og: http://ogp.me/ns#">

Tuve problemas similares. Eliminé la propiedad = "og: image: secure_url" y ahora se limpiará con solo og: image. A veces menos es más

tl; dr - se paciente

Terminé aquí porque estaba viendo imágenes en blanco servidas desde un sitio https. El problema era bastante diferente aunque:

Cuando el contenido se comparte por primera vez, el rastreador de Facebook raspará y almacenará en caché los metadatos de la URL compartida. El rastreador debe ver una imagen al menos una vez antes de poder renderizarla. Esto significa que la primera persona que comparte una parte del contenido no verá una imagen renderizada

[ https://developers.facebook.com/docs/sharing/best-practices/#precaching]

Durante la prueba, Facebook tardó unos 10 minutos en mostrar finalmente la imagen renderizada. Así que mientras me rascaba la cabeza y lanzaba etiquetas og al azar en Facebook (y sospechaba el problema de https mencionado aquí), todo lo que tenía que hacer era esperar.

Como esto podría realmente evitar que las personas compartan sus enlaces por primera vez, FB sugiere dos formas de evitar este comportamiento: a) ejecutar el Depurador OG en todos sus enlaces: la imagen se almacenará en caché y estará lista para compartir después de unos 10 minutos o b ) especificando og: imagen: ancho y og: imagen: altura. (Leer más en el enlace de arriba)

Aún me pregunto qué les tomará tanto tiempo ...