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


301

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.


27
Dobrze udokumentowane pytanie. Oceniłem to za Ciebie!
DMCS

W celu rozwiązania problemów spróbuj zmienić og:type: og_products:producttyp strony internetowej i sprawdź, czy obrazy można odebrać.
DMCS,

2
Soczysty, mamy og: obraz, do którego odwołuje się strona zewnętrzna, która jest http, a nie https i pokazuje się.
Cypr106

1
Cześć, dzięki, świetny post. Tylko niewielka uwaga o tym, że martwisz się o konieczność zaktualizowania pamięci podręcznej, jeśli wrócisz do https-urls, gdy zaczną one działać: nie martwiłbym się tym, ponieważ pamięć podręczna fb zostanie zwolniona po pewnym czasie, więc po prostu zachowaj podwójne dane dla dzień lub dwa, a pamięć podręczna zostanie zwolniona automatycznie przy użyciu nowych adresów URL.
Niclas Lindqvist

1
@NiclasLindqvist Hej, dla przypomnienia, mieliśmy stare zdjęcia w pamięci podręcznej na MIESIĄCE i miesiące wcześniej, więc wziąłbym standardy pamięci podręcznej FB z odrobiną soli.
Cypr106

Odpowiedzi:


93

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.


3
KEEGAN! Dziękuję Ci! To pierwszy raz, kiedy problem HTTPS został udokumentowany jako błąd ..... i patrzyliśmy mocno. Opublikowanie naszego obejścia w komentarzach do pytania.
Cypr106,

2
Od sierpnia 2013 r. Ten adres URL nie wyświetla błędu. Czy były jakieś aktualizacje?
Andreas Andreou,

3
developers.facebook.com/bugs/256470807842897 Ten najnowszy błąd jest również istotny. Chociaż pytanie zostało udzielone, pomyślałem, że dodam tutaj link, więc jeśli ktoś z podobnym problemem znajdzie się tutaj, znajdzie go.
Zoidberg,

4
Mówi, że problem został naprawiony 18 marca 20145 r., Nie dla mnie, myślę.
Mike Flynn

1
@MattBrowne Nie, to nie jest dla mnie naprawione :-(
starbeamrainbowlabs

131

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


1
Sir, wielkie dzięki. Nie wiedziałem, że istnieją dalsze metadane dla zdjęć! Próbowaliśmy zrobić sam image: secure_url, a FB zgłosił błąd. Próbowaliśmy image & secure_url * na wiele sposobów) i linijka nie wykazała żadnych zmian.
Cypr106

Dla mnie ciągle wyświetla obrazy podglądu, a nie obraz metatagu. Zdecydowanie też mam odpowiedni adres URL! :( Pomysły?
jaminroe

1
@jaminroe Czy robiłeś kłaczki? Jeśli nie, to zostaw. To powinno głównie rozwiązać problem. Jeśli nadal nie wybiera, to zobacz, co narzędzie jest w stanie zeskrobać, możesz również zobaczyć, co dokładnie jest zgarnięte, na końcu wyniku See exactly what our scraper sees for your URLkliknij link i sprawdź, czy pokazuje pełne źródło linku lub usuwanie byle co. Jeśli źle charsetsię ustawisz, skrobak nie będzie w stanie zeskrobać z jakiegoś powodu (odpowiedziałem kiedyś na podobne pytanie z tym problemem). Upewnij się więc, że wszystkie te rzeczy są prawidłowe.
Syed IR

3
Na wypadek, gdyby komukolwiek to pomogło - nasz adres og: image nie ma rozszerzenia pliku, ponieważ obrazy są tworzone przez usługę (/ foo / bar). Ta odpowiedź rozwiązała nasze problemy z linterem Facebooka, prawdopodobnie z powodu og: type = "image / png". Dziękuję Ci!!
Dunc

3
@JohnWasham og:imageZnacznikiem może być HTTPS (co robi StackExchange, YouTube, WordPress.com, Amazon itp.). To sprawia, że ​​zastanawiasz się, po co og:image:secure_urltak naprawdę jest?
DocRoot

16

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.


Na zdrowie - działało dla mnie - ale debugger na Facebooku też chce obrazu, więc przesyłam oba. og: image i og: image: url - oba o tej samej wartości / url
pperrin

1
Czy og: image: url rozpoznała składnię, czy jest niepoprawna i dlatego nie jest analizowana? Innymi słowy, czy to to samo, co brak metatagu?
Jonathan Tonge,

@JathanathanTonge Przypisując do ogp.me , „ og:image:urljest identyczny z og:image”.
DocRoot

9

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.


2
To maksymalny współczynnik proporcji 3: 1 ( developers.facebook.com/docs/opengraphprotocol ), przy minimalnym rozmiarze 50px x 50px
rpearce

1
Zgodnie z debugerem Facebooka wymóg rozmiaru wynosi teraz 200px x 200px
braX

8

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


Powodem tego jest współczynnik obrazu. Jeżeli stosunek wymiar obrazu nie jest dokładnie 1,91: 1 i / lub og:image:widthi og:image:heightdane nie ujęte, a następnie Facebook będzie musiał przetwarzać obraz po złomowanie to, aby dopasować swoje wymiary. Obraz zostanie również przycięty, co może być niepożądane. Aby uzyskać szczegółowe informacje, patrz: developers.facebook.com/docs/sharing/best-practices/#images
Slicktrick

1
Określanie og: image: width i og: image: wysokość na obrazach, których nie ma na bardzo krótkiej liście kwalifikowanych rozdzielczości, nie przyspieszaj żadnych rzeczy w moich testach.
Chris Moschini,

5

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

2

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


1
Twoja odpowiedź powinna mieć znacznie więcej głosów! Masz całkowitą rację, jeśli podajesz treści tylko przez https, po prostu użyj og: image: url i gotowe.
marcvangend

1
Nie rozumiem, dlaczego to rozwiązanie. pytanie najwyraźniej nie zawierało Secure_url w pierwszej kolejności, dlaczego uważasz, że to działa, jest zbyt losowe
Decebal

1

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.


1

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.


1

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.


2
Nie zawsze jest to jednak możliwe, ponieważ og: image może być adresem CDN w chmurze. Również w moim przypadku, podczas gdy FB (w 2017 roku!) Nie odbiera obrazu CDN z samej strony, pobiera inny obraz CDN, który jest również Cloudfront, co oznacza, że ​​również nie jest moim og: url. Więc twój punkt widzenia jest błędny.
PKHunter

To prawda. Nie korzystałem z adresu URL CDN. Pomyślałem, że podzielę się tym, co dla mnie zadziałało.
Darren Hall


1

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


1

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.


0

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.


Dzięki Lix! Tak naprawdę mieliśmy mały kwadratowy obraz o wielkości około 200 x 200 jako pierwszy od dłuższego czasu. Zmieniliśmy układ i zeskrobaliśmy wiele razy. Zrobiliśmy też kombinację, aby mniejsze, większe lub alternatywne były jedynymi obrazami i ponownie zapisywały wyniki z zerową skutecznością.
Cypr106

0

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 ()


Uwielbiam to, Google dąży do nadania witrynom WIĘCEJ trafności do witryn z https, a dwa lata po zadaniu tego pytania, FB nadal (być może, ale wciąż grzech) karze witryny, które cenią bezpieczeństwo ich odwiedzających
Cypr106


0

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.


0

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:

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 .


0

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).


0

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.


-1

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.


-1

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

-2

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”


-2

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

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.