FB OpenGraph og: obraz nie ciągnie obrazów (być może https?)

Po pierwsze - nie sądzę, że jest to duplikat. Szeroko szukałem takich samych lub podobnych problemów na SO, a ze względu na naturę rozwiązywania problemów przed zapytaniem, uważam, że ten problem jest wyjątkowy.

Facebook nie może uchwycić moich og:imageplików i wypróbowałem każde zwykłe rozwiązanie. Zaczynam myśleć, że to może mieć coś wspólnegohttps://...

• Sprawdziłem http://developers.facebook.com/tools/debug i mam zerowe ostrzeżenia lub błędy.
• Znajduje obrazy, do których linkowaliśmy w „ og:image”, ale są puste. Jednak kiedy klikamy obraz (y), one już istnieją i potrzeba ich prosto do nich.
• Pokazuje jeden obraz - obraz hostowany na serwerze innym niż https.
• Wypróbowaliśmy kwadratowe obrazy, JPEG, PNG, większe rozmiary i mniejsze rozmiary. Umieściliśmy zdjęcia bezpośrednio w public_html. Pojawiają się zero.
• Nie jest to błąd pamięci podręcznej, ponieważ gdy dodamy kolejną og:imagedo meta, linijka FB ją znajdzie i przeczyta. To pokazuje podgląd. Podgląd jest pusty. Jedyny wyjątek jesteśmy coraz jest dla obrazów, które nie znajdują się na tej stronie.
• Pomyśleliśmy, że może jest jakiś cpanelśrodek .htaccesszapobiegający ługowaniu lub ten, który uniemożliwia wyświetlanie obrazów, więc sprawdziliśmy. Nie było. Pośpieszyliśmy nawet < img src="[remote file]" >na zupełnie innym serwerze, a obraz pokazuje się dobrze.
• Pomyśleliśmy, że może to była og:typekolejna osobliwość z innym metatagiem. Usuwaliśmy je wszystkie pojedynczo i sprawdzaliśmy. Bez zmiany. Tylko ostrzeżenia.
• Ten sam kod w innej witrynie pojawia się bez problemu.
• Myśleliśmy, że może nie pobiera zdjęć, ponieważ używamy tej samej strony (stron) produktu dla wielu produktów (zmieniając ją w oparciu o wartość get, tj. „Details.php? Id = xxx”), ale nadal pobiera jedną obraz (z innego adresu URL).
• Pozostawienie dowolnego og:imagelub image_src wyłączone, FB nie znajduje żadnych zdjęć.

Jestem na końcu mojej liny. Gdybym powiedział, ile czasu spędziłem na tym razem z innymi, byłbyś zszokowany. Problem polega na tym, że jest to sklep internetowy. Absolutnie, pozytywnie NIE możemy mieć zdjęć. Musimy. Mamy dziesięć innych witryn ... To jedyna z og:imageproblemami. Jest to również jedyny włączony https, więc pomyśleliśmy, że może to był problem. Ale nie możemy znaleźć w tym miejscu żadnego precedensu.

Oto metatagi:

<meta property="og:title" content="[The product name]" /> 
<meta property="og:description" content="[the product description]" /> 
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-art-black.png" />
<meta property="og:image" content="http://www.[ADIFFERENTwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/ARShopHeader.png" />
<meta property="og:image" content="http://www.[ourwebsite].com/overdriven-blues-music-tshirt-art-black.JPG" />
<meta property="og:type" content="product"/>
<meta property="og:url" content="https://www.[ourwebsite].com/apparel-details.php?i=10047" />
<meta property="og:site_name" content="[our site name]" />      
<meta property="fb:admins" content="[FB-USER-ID-NUMBER]"/>
<meta name="title" content="[The product name]" />
<meta name="description" content="[The product description]" />
<link rel="image_src" href="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta name="keywords" content="[four typical keywords]">
<meta name="robots" content="noarchive">

Jeśli chcesz, oto link do jednej z naszych stron produktów, nad którymi pracowaliśmy. [Skrócono link, aby ograniczyć dostęp do wyników wyszukiwania naszej witryny]: http://rockn.ro/114

EDYTOWAĆ ----

Za pomocą narzędzia skrobiącego „Zobacz, co Facebook widzi”, mogliśmy zobaczyć:

"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"
      }
   ],

Przetestowaliśmy wszystkie znalezione linki dla jednej strony. Wszystkie były doskonale poprawnymi obrazami.

EDYCJA 2 ----

Wypróbowaliśmy test i dodaliśmy poddomenę do witryny NONSECURE (z której obrazy są faktycznie widoczne przez Facebook). Subdomena to http: // img. [Nonsecuresite] .com. Następnie umieszczamy wszystkie obrazy w głównym folderze poddomeny i odwołujemy się do nich. Nie ściągnie tych obrazów do FB. Jednak nadal pobierałby wszystkie obrazy, do których odwoływano się w niezabezpieczonej głównej domenie.

ROZPOCZĘCIE OBEJŚCIA ----

Dzięki Keegan wiemy już, że jest to błąd na Facebooku. Aby obejść ten problem, umieściliśmy poddomenę w innej witrynie NON-HTTPS i zrzuciliśmy na nią wszystkie obrazy. Odnieśliśmy się do koordynującego http://img.otherdomain.com/[like-image.jpg]obrazu og:imagena każdej stronie produktu. Następnie musieliśmy przejść przez FB Linter i uruchomić KAŻDY link, aby odświeżyć dane OG. To zadziałało, ale rozwiązaniem jest obejście pomocy dla zespołu, a jeśli httpsproblem zostanie rozwiązany i wrócimy do korzystania z naturalnej domeny https, FB zbuforuje obrazy z innej witryny, co komplikuje sprawy. Mam nadzieję, że ta informacja pomaga uratować kogoś przed utratą 32 godzin kodujące ich życia.

Natknąłem się na ten sam problem i zgłosiłem go jako błąd na stronie programisty Facebooka. Wydaje się całkiem jasne, że og:imageidentyfikatory URI korzystające z HTTP działają dobrze, a identyfikatory URI korzystające z HTTPS nie. Teraz przyznali, że „przyglądają się temu”.

Aktualizacja: od 2020 r. Błąd nie jest już widoczny w systemie biletów Facebooka. Nigdy nie odpowiedzieli i nie sądzę, że to zachowanie się zmieniło. Jednak określenie identyfikatora URI HTTPS og:image:securewydaje się działać dobrze.

Niektóre właściwości mogą mieć dołączone dodatkowe metadane. Są one określone w taki sam sposób, jak inne metadane z propertyi content, ale propertybędą miały dodatkowe:

og:imageNieruchomość ma kilka opcjonalnych właściwości strukturyzowanych:

• og:image:url - Identyczne z og: image.
• og:image:secure_url - Alternatywny adres URL do użycia, jeśli strona wymaga HTTPS.
• og:image:type - Typ MIME dla tego obrazu.
• og:image:width - Liczba pikseli szerokości.
• og:image:height - Wysoka liczba pikseli.

Przykład pełnego obrazu:

<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" />

Musisz więc zmienić og:imagewłaściwość adresów URL HTTPS naog:image:secure_url

Dawny:

TAG META HTTPS DO OBRAZU:

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

TAG META HTTP NA OBRAZ:

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

Źródło: http://ogp.me/#structured <- Możesz odwiedzić tę stronę, aby uzyskać więcej informacji.

Mam nadzieję, że to ci pomoże.

EDYCJA: Nie zapomnij pingować serwerów Facebooka po aktualizacji kodów - Linter URL

Nie wiem, czy to tylko u mnie, ale dla mnie og:imagenie działa i wybiera logo mojej witryny, mimo że debuger Facebooka pokazuje prawidłowy obraz.

Ale przejście og:imagedo og:image:urlmnie zadziałało. Mam nadzieję, że pomoże to każdemu, kto boryka się z podobnym problemem.

Dostałem się tutaj z Google, ale to nie była dla mnie duża pomoc. Okazało się, że logo ma minimalny współczynnik kształtu 3: 1. Mój był prawie 4: 1. Użyłem Gimpa, aby przyciąć go dokładnie do 3: 1 i voila - moje logo jest teraz wyświetlane na FB.

tl; dr - bądź cierpliwy

Skończyło się tutaj, ponieważ widziałem puste obrazy wyświetlane z witryny https. Problem był jednak zupełnie inny:

Gdy treść jest udostępniana po raz pierwszy, robot indeksujący Facebook zgarnia i buforuje metadane z udostępnionego adresu URL. Robot indeksujący musi zobaczyć obraz przynajmniej raz, zanim będzie mógł zostać zrenderowany. Oznacza to, że pierwsza osoba, która udostępni część treści, nie zobaczy renderowanego obrazu

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

Podczas testowania zajęło Facebooku około 10 minut, aby w końcu pokazać renderowany obraz. Więc kiedy drapałem się po głowie i rzucałem losowymi tagami og na Facebooku (i podejrzewałem wspomniany tutaj problem https), musiałem tylko czekać.

Ponieważ może to naprawdę uniemożliwić innym udostępnianie twoich linków po raz pierwszy, FB sugeruje dwa sposoby obejścia tego zachowania: a) uruchomienie Debuggera OG na wszystkich twoich linkach: obraz zostanie zapisany w pamięci podręcznej i będzie gotowy do udostępnienia po ~ 10 minutach lub b ), określając og: image: szerokość i og: image: wysokość. (Przeczytaj więcej w powyższym linku)

Nadal zastanawiam się, co zajmuje im tak długo ...

Miałem ten sam błąd i nic z poprzednich nie pomogło, więc próbowałem postępować zgodnie z oryginalną dokumentacją protokołu Open Graph i dodałem atrybut prefiksu do mojego tagu HTML i wszystko stało się niesamowite.

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

Miałem podobne problemy. Usunąłem właściwość = "og: image: secure_url", a teraz będzie szorować za pomocą tylko og: image. Czasami mniej znaczy więcej

Odkryłem inny scenariusz, który może powodować ten problem. Przeszedłem wszystkie etapy opisane w pytaniu i odpowiedziach, ale problem pozostał.

Sprawdziłem moje zdjęcia i stwierdziłem, że niektóre z moich postów miały zbyt duże miniatury og:imagew zakresie kilku tysięcy pikseli i kilku megabajtów.

Stało się tak z powodu niedawnej migracji z WP do Jekyll, zoptymalizowałem swoje zdjęcia za pomocą gulp, ale przez pomyłkę użyłem oryginalnych obrazów w og: image.

Facebook daje nam dzisiaj następujące zalecenia :

Użyj obrazów o wielkości co najmniej 1200 x 630 pikseli, aby uzyskać najlepszy obraz na urządzeniach o wysokiej rozdzielczości. Jako minimum powinieneś używać obrazów o wymiarach 600 x 315 pikseli, aby wyświetlać posty na linkach z większymi obrazami. Obrazy mogą mieć rozmiar do 8 MB.

Jest więc górny limit 8 MB.

Jak przypadkowo znalazłem, przezroczysty pusty obraz pochodzi z nagłówkiem odpowiedzi wskazującym możliwą przyczynę problemu.

1. Przejdź do debuggera na https://developers.facebook.com/tools/debug/og/object/
2. Wpisz swój adres URL
3. Na dole Facebook pokazuje Twój „obraz” (przezroczysty 1x1 GIF)
   1. Obraz jest powiązany z oryginalnym obrazem - nie ma sensu go naciskać
   2. Naciśnij w prawo i wyświetl zdjęcie (dostaniesz coś takiego https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)
4. Włącz kartę Netto w narzędziach firebug / dla programistów, w razie potrzeby odśwież stronę
5. Otrzymasz x-error-detailnagłówek odpowiedzi z wyjaśnieniem

Na przykład w moim przypadku tak było Invalid image extension for URL: https://[mydomain]/[myfilename].jpg

Prawdziwy problem w moim przypadku dotyczył prerender.io .

Jak się okazuje, jeśli obraz jest wymagany przez prerenderowanie, jest konwertowany na HTML. Coś takiego:

<!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>

Jest to albo błąd w samym prerenderowaniu, albo powinien być skonfigurowany w twoim proxy, aby nie używał prerendera dla *.jpgżądań (nawet jeśli są one wymagane przez bota Facebooka).

Naprawdę trudno to zauważyć, ponieważ wstępnerenderowanie jest używane tylko w niektórych nagłówkach klienta użytkownika.

Natrafiłem na ten sam problem, a potem zauważyłem, że mam inną domenę dla og:url

Kiedyś upewniłem się, że domena jest taka sama og:urli og:imagedziała.

Mam nadzieję że to pomoże.

W moim przypadku problem był nie przewidując certyfikat CA Root . Zrozumiałem to po użyciu: https://www.ssllabs.com/ssltest/analyze.html do analizy konfiguracji SSL.

Podobne objawy (Facebook i in. Niepoprawnie pobierają og: obraz i inne zasoby przez https) mogą wystąpić, gdy certyfikat https witryny nie jest w pełni zgodny.

Certyfikat https witryny może wydawać się prawidłowy (zielony klucz w przeglądarce i nie tylko), ale nie zostanie poprawnie zeskrobany, jeśli brakuje certyfikatu pośredniego lub łańcucha. Może to prowadzić do wielu zmarnowanych godzin sprawdzania i ponownego sprawdzania wszystkich różnych pamięci podręcznych i metatagów.

Być może nie był to twój problem, ale mogą być inne z podobnymi objawami (jak mój). Istnieje wiele sposobów na sprawdzenie certyfikatu - tego, z którego zdarzyło mi się skorzystać: https://www.sslshopper.com/ssl-checker.html

Wyjąłem http://z niego og:imagei zastąpiłem go zwykłym starym, www.a potem zaczął działać dobrze.

Możesz użyć tego narzędzia Facebooka, aby zresetować pamięć podręczną zgarniania obrazu i przetestować, jaki adres URL pobiera dla obrazu demonstracyjnego.

Widzę, że Debugger pobiera 4 og:imagetagi z twojego adresu URL.

Pierwszy obraz jest największy i dlatego trwa najdłużej. Spróbuj zmniejszyć ten pierwszy obraz lub zmień kolejność, aby najpierw wyświetlić mniejszy obraz.

Ponadto ten problem występuje również po dodaniu historii generowanej przez użytkownika (w przypadku gdy nie używasz og: image). Na przykład:

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

Powyższe będzie działać tylko z http, a nie z https. Jeśli użyjesz protokołu https, pojawi się komunikat o błędzie: Nie można przesłać załączonego obrazu ()

Nie zapomnij odświeżyć serwerów poprzez:

Debuger Facebooka

I kliknij „Zbierz nowe informacje”

Miałem dzisiaj podobny problem, który pomógł mi w rozwiązaniu Debugger udostępniania . Wygląda na to, że Facebook nie może (obecnie) zrozumieć obrazów z osadzonymi metadanymi XMP. Kiedy zastąpiłem obrazy w naszych artykułach wersjami bez metadanych XMP i ponownie zeskrobałem stronę (za pomocą Debugera udostępniania), problem zniknął. Edytor szesnastkowy pomoże ci sprawdzić, czy twój obraz zawiera metadane XMP.

W moim przypadku wydaje się, że robot ma tylko błąd. Próbowałem:

• Zmiana linków tylko na http
• Usuwając końcową spację
• Całkowite przełączanie z powrotem na http
• Ponowna instalacja strony internetowej
• Instalowanie kilku wtyczek OG (korzystam z WordPress)
• Podejrzewa się, że serwer ma dziwną błędną konfigurację, która blokuje boty (ponieważ wszystkie kontrolery OG nie są w stanie pobrać tagów, a inne żądania do moich stron są niestabilne)

Żadna z tych prac. Kosztowało mnie to tydzień. I nagle znikąd wydaje się, że znów działa.

Oto moje badania, jeśli ktoś ponownie napotka ten problem:

• Co sprawia, że ​​kontrolery Open Graph nie mogą wykryć danych Open Graph?
• Jak się dowiedzieć, jakie boty strony internetowej, jeśli nie mam dostępu root do hostingu, które przeczytają? t
• 👍 Co sprawia, że ​​kontrolery Open Graph nie są w stanie wykryć danych Open Graph? - Szyfrujmy wsparcie społeczności
• 👍 Robot nie może pobrać zdjęć, ale dodanie zupełnie nowego, unikatowego ciągu zapytania może sprawić, że będzie działać po raz pierwszy - Facebook dla programistów

Ponadto istnieje więcej kontrolerów innych niż obiektowy debugger Facebooka : OpenGraphCheck.com , tester otwartych wykresów Abhinaya Rathore'a , kody osadzania Iframely , weryfikator kart | Twórcy Twittera .

OK ... Zdaję sobie sprawę, że ten wątek jest stary i przepełniony, ale na wypadek, gdyby ktoś wszedł tak, jakbym starał się, aby jego tag og: image działał bezpośrednio na Facebooku, oto sztuczka, która zadziałała dla mnie:

NIE używaj tego linku:

https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.google.com

rozwiązać swój problem. Jeśli tak, natychmiast przewiń w dół i kliknij Scrape VIA API.

https://developers.facebook.com/tools/explorer/?method=POST&path=%3Fscrape%3Dtrue%26id%3Dhttps%3A%2F%2Fwww.google.com&version=v5.0

W narzędziu eksploratora wyświetlane są błędy, które NIE są pokazywane w narzędziu „debugowanie”. Szalony!!! (w moim przypadku spacja w nazwie pliku obrazu niszczyła mój obraz w narzędziu do debugowania, ale pokazywał błąd w narzędziu eksploratora).

Natknąłem się na inny powód, dla którego obrazy nie były wyświetlane na kartach FB. Co więcej, używając narzędzia skrobaka FB do debugowania tagów og , mogłem potwierdzić wszystkie wymagane tagi tam, gdzie są obecne na mojej stronie WordPress, a mimo to dostałbym następujący błąd pobierania pliku,

Pod warunkiem, że nie można pobrać og: image, <https-link-to-jpg-image>. Może się to zdarzyć z kilku różnych powodów, takich jak na przykład używanie przez serwer nieobsługiwanego kodowania treści. Przeszukiwacz akceptuje kodowanie zawartości deflate i gzip.

Miałem niejasne wrażenie, że problem dotyczy formatu obrazu, link do obrazu działał, ale wiadomość wydaje się wskazywać na coś nie tak z kodowaniem treści.

Po wielu poszukiwaniach skończyłem przeglądać rozszerzenia php wymagane dla serwera WordPress i zdałem sobie sprawę, że moduł pho-exif nie został zainstalowany. Moduł exif zapisuje metadane exif do wszystkich przesłanych obrazów. W rezultacie obrazy użyte w znaczniku obrazu FB og nie miały z nimi żadnych metadanych exif.

Po włączeniu modułu exif WordPress umożliwia reset metadanych exif dla obrazu (Biblioteka multimediów -> wybierz i obraz -> Edytuj więcej szczegółów -> Mapuj metadane exif), a obraz pojawił się na karcie FB zgodnie z oczekiwaniami.

Z tego, co zaobserwowałem, widzę, że gdy twoja strona jest publiczna i mimo że URL obrazu to https, to po prostu działa dobrze.

Dla mnie to zadziałało:

<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"/> 

Po kilku godzinach testowania i próbowania rzeczy ...

Rozwiązałem ten problem tak prosto, jak to możliwe. Zauważam, że używają „stron testowych” na stronie programistów Facebooka, która zawiera tylko tagi „og” i trochę tekstu w treści, który odwołuje się do tych tagów og.

Co więc zrobiłem?

W mojej aplikacji utworzyłem drugi widok, zawierający te same rzeczy, których używają.

A skąd mam wiedzieć, że Facebook uzyskuje dostęp do mojej strony, więc mogę zmienić widok? Mają unikalnego agenta użytkownika: „facebookexternalhit / 1.1”

Po zaktualizowaniu metatagu upewnij się, że link do treści (obrazu) jest ścieżką bezwzględną i przejdź tutaj, https://developers.facebook.com/tools/debug/sharing wprowadź link do witryny i kliknij na scrape againnastępnej stronie