We are using the og:image property to supply facebook with the correct image, but in some instances it get's more images which it parses from the DOM. eg:
http://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Ffunda.nl%2Fkoop%2Futrecht%2Fappartement-48611144-breedstraat-122%2F&t=Woning+te+koop%3A+Breedstraat+122%2C+Utrecht
Only the first image should be shown there. If you look in the debugger it looks fine:
http://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.funda.nl%2Fkoop%2Futrecht%2Fappartement-48611144-breedstraat-122%2F
Anyone knows whats going on here?
I've just encountered this issue in a site I maintain.
It appears that bloody Facebook changed again things without notifying anything to developers..
Image for og:image must be now at least 200x200px.
If it is smaller, than facebook will take other images that it parses from the same URL, even if these images have nothing to do as leading image for that URL.
Just take care that og:image is big enough and it will be ok.
* Notice that even after you change it, it may appear wrong for some time, if the URL is already cached in FB. To solve it immediately, just pass again the URL to the FB debugger.
Related
Backstory to the below issue:
I'm using the jQuery plugin Cropit to produce an image which I get in data URL form (the user uploads an image and Cropit allows them to manipulate it, when the user is happy, Cropit exports the final image).
This data URL is attached to the product (this is a Shopify website) via Shopify properties (in a similar way you would attach text for an engraved product) and then when the order is created, I have an app listening for new orders and I pull the data URL from the order.
From testing, I can confirm that the data URL is wrong / corrupted / broken at the time the order is placed and not being broken in transit.
Original Question
I have a bit of a weird situation and I can't find any similar situations online.
I'm being sent an image in data URL format (from Shopify if it's relevant, I have written a private app and their webhook is sending me an image)
The image is in a data URL format that starts with, as an example,
data:image/png;base64,iVBORw0KGgoAAAANSU.....
The problem I am having is sometimes (and it's maybe less than 10% of the time) when I get the image and try to print it, it's missing the bottom chunk of the image. In a PDF, it considers the image corrupt, and in a web browser, it just sees the bottom of the image as transparent, however much is missing.
This is what it looks like in Inspect Element on Google Chrome when you hover over the image URL (image has been purpled out for anonymity)
My question is, does anyone know why?
We can't find a correlation with browser or device type. And I'm not sure if it's because part of the data URL is somehow missing (maybe a character limit, because it's a really long string!) or if it's the type of image. Might possibly be something going wrong in the upload process?
Is anyone able to shed any light? It's such a weird issue I'm not even sure what to google!
And just to confirm, the image absolutely has to be sent in this format for a whole series of reasons, mainly Shopify restrictions so I can't send the image in file format.
I was copying image links from google and I'm seeing more and more urls like this. What exactly is going on here and why are developers doing this? Heres a example.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAO0AAADVCAMAAACMuod9AAAAXVBMVEX///9Twd5Kv91AvNxNv91Fvtyi2uvq9vr6/f7L6vPP6/Tk9Pk8vNvE5/Lw+fz1+/1ox+FexOCQ1Oh/zuV1y+Pa8Pey4O664/Cc2Oqq3e2W1ul7zeSH0eav3+7e8fh0dubVAAATFElEQVR4nO1d6baqOgzellZlUEFFnN//Ma+gTdIBOoi4zl1+/87ZAh3SzEn//n744Ycffvjhhx9++OGHH0bBMq+zrM43Y75zU68Ot9OhqddjvvVtpNtZIjokbD9Px5hyfriyxztZC5HMjvcR3jkGNkch+AzAmSjKw+KtV+bzWcHIOx9vTcpspPG+hUPCZjo4S8om+o1NVZivfMx3txxx2FFY7oU5sG5wQhxjjtuDUtRdpWuYjz7+sLHNekbWghXbUIJen23bCtMt6o/MwhPL/pG9hrcN2d/lsRhYvBbJN3e3dAyune/c+20HMbCvr9fx753dozI6zhjn5vQZW3m97F6ZHODxylYI0f/Zf3hO/eNLcBBCXI6n0/FaJSaTEaXH8d3qRMxZwa+nJs1Wp32CfxN+azc+kI5Zlcr/XNbzypBJxcnxqoxpj7Bi3+Aabba4sOxT0xlGCpQnjupfFnMu1J0S1eD2bgt1W8XspnG3FKbLXCv3GVRyQsLCiNJSm0Bx6H1RPlPPf1Km5o9SeN9XNreWn+cX+9/paWvXZN/DThvlxHLRoyICSxTxWlo8tnKMSZ8RUJcKl+XcqtnvlB+xmWVfn5CKDC9HGX8Y5EFiAwJ1xRUatVDzulLkS3EbeJlcluQ9kyMGGXx7UN7PFTIVV/0tCrUXu0FbEfZ/YEk+hPNrmEyfgIaFQs6sUuZzoKyMs14ifuLGvkbKsF1Os/OmbC+1Y84J+YNwGnRr+fNiavURv+z+7UI5mwUsz4XsOk88OK1UZ9wrPDLg2NrFj4YzpdjkxatKsgZsWPt4Yf56YnIF4xT24YzqVknLxTd0wxPH4Ye3vAhh98bIY3BlYUSlSBqx/VsrvNhTX9jAOY8feBTkEUq8rfUrOaXiSnweXHh7JORDHsxiVIC09X/kRA4v9VFW/u6NvVytaV0Yy0QONeChVDUUXgc/xDw/f4cpL+QJ8mLJErnpTTS0q0FI/cLTHTIW7pI7boMeW+suyuQc9HwjZ9tvPn4CIAuO7t9SLCtlukmg4JQOhCFL5AOAzwbL+T2ZLgu1VOvIRX4Tq+jZUqds8NORB+hdwGxDD5DqgfZRjinyf2u2e821WDiMPA0w2yBO/jZgtmGG9dYIBhRBcdkvzTaOS50s8UAREij6EiVnMaJghboURlD4LMA0/xKXihEFNU5WHFHuhvhd4LNhSsm7iFjkNZIxu/6t8QQz/3dEkdT7iNCTyW62hkCOPqnEm7HHi/m3IO1qfzK84GSfdlOGhJ34GrigJ08cLgDfuefvj0DHEHBucHd9GbP0D00d1oRt8fs5MW3R009WwNNMltEYf2/HOJDKvV+UYoHbSBNFLsCqXD54+YCkhYnTL8JWGc1aVTOuev6/D5X89cTu81MIv9hhEF+VNkQqFT7bJUlERI05His5Ww/Jd8DzqbNw1Di4h9d0HSwJRkLt78i+44zM/B+yEu43yY96nvLxEODIRovWRq1X4FTumHvzrcjInxykk2HgobWHBJBTOY/uUbLGybOIwJHtYMoNkGqPPrz2P7pS7InJk5Xnfkx5gXNB1rLsIP+VudYD4JcO8AlIpuywgohHtSwrJpIiQRSFYLNqD7+YJYOOG9BRQgIU4yAfZFPLPGtO20ulBAfsKaBKaiSb7a/HQ3q35l+svsWS/whZKSNb3lenbfmsCOBDyct94G0dgSiK8jpf1eqk59+JFHQANiUjUPlqfmmLKZglkTVi1m3+asL2x+YuT2n5JZugxYloU/fmXBbCnV4cM2smimrbtBP8WpLJH2Gl1b4YaT97Z/yYclJKQyQoijoWlkROTgFYz4mDQE/k0aNGRL1g+lS4dMt6KmNs82NdFViRdOK1Ksty/8BD/FYzLlqx2/5ZT8cemq64hgVU3sJql4iAbeG7ZpXV+XrTw1yW68U9SxsaSHDt+mORdpPoytm1GJ5qy1GK2ZX8h+eb57C7/FK2alZfFdRrwsX1w9kXiznrFzMd52wFZLZA97rqiBoGaJmtNrquV/PdLBni9o+xzD+XvJvu+wqxniLi3KDyA4w6IBKQA5dP5K4t781xSMCxYv+ZI3yY9fIlXp0b1TYlVBnwiWPPU/nq2F9nJfhhbG1jeRpSlIz0pYW5S15AijDcXfv+Q8zEfMwi5+XcWiIKQsMwSkr4TZi5gk65QjuQYPNzG+9iyXG0/b1Z9vXBEncraePqHk+oAJiJwEFAacZMcytKlxSv0qtN/rGAesEhaJUQT9IR245C5aw0Ug5wrGlY4qOqPJXntnPAZQ/dxpgwGyEUppYFdKvLUNBdrQ4MZDbhfl8kCyWeBoScvFxSNrEvqjf9VXM9EZMrJeJQ3EaDX4vew+cD8NswqvwfYAHx/1Zlos2XF+/E7NWCgHYEyVmVNHJigkg9HG/MUbKvFRCy8sr8qHMUxqMt/YNaJMrFzHCRACmjox/rC0NELQJENSm1Bf+bUVvdzDSCLiLtQbXkjIvKooenptMTZOawA7Ef6E0H3je3ELLEqlLny8oI4auWnD30KLvNIWcLDBEDO/1p1ot6qOsJMCp0UsBMrCGRVKvKDvdb5cqC9XN3mQ0ufeNLtAbsLOo+L4uu70nCrz1GGxx8KcCwiq6H7a3UmtYk0BqsaRUWHzgLNQzkeaJA+jDrM6uK9Ch5WKlH2w7neqktcId+iXZSCwKD3Bs1FTzDZe8wsG5268Ga4Huly0hmzcc+c+Wl4AEb0h82F7pBIWnepPz/IWCHfdUn2Mz2XxCftGlRc1s3C1Ga+TTkOLR/BGE7HP9ZKRVW3rtL8gPcJWcgH1tVD2jQ5gXt6/FiSRkBVtdZFdLKd5kYSheZwvfskkhV4rbFJU9pxSPwF4uhp6cmk30wFT4QY0WOrMHNa2nJkVciB42We5WckZJn5G2m9NkN2ccGMadEjl3l1npkZtRIzT4/b8udcbJepjjoPnOwuM0c68OgQ9ake/BVCFhNr2DXAn06XqFAQsZ+UhqEDnrzjYSRta3Mi2yuwUKRTIAm/GLUpCuSh/8PeKznzlI9Hp40ONvOwo2VJwy5e9Gf8E0O3uCiuwNGQHH+9Rx757jy4a21pVcba+hdgYBphs5slKbX19SPVDuT5kZtHVtrI1PtmYCMMLDCnM8Adwgx19SBW3TGZOaCuQ3aUQ/JGsLGI8NSCKggKCXpoOrkxtZm7giZRXM4q91rAsYDupgjjWw1YEgOvJ3unWVr5wOyFh4zntoobw0rxfHrjCGzzQJjpGeqoZpmjYsjd4+Z6jJtTRaWIuXZnwLSncO8d4SB2iy9ymO2FrVwSeqHAt1r8ovFYAo/FP8Her1JMqPFYvUJRNuKw/EEhHovZQnd8K7JNQko/u+QKUaLDp8wvm22C3gwNLEECuwH1Sm5t7YdGgIKR2ahCp9Avm22yA5CXU3SkhguQJAUGdh0gLBPG/N0t3200hxlyoGNDeVjw+045EkJ5ApUxFhy/q8eB9fCKSin97RWX8j9ypXg/IXVKSgtpMzNPfiwKeOpjdJ8KqgqEzyhw4V36PAKiWo0ChsyF+ru1hwtxHRW6D+Ek4C4dYX9wNDyb0Cjy1PL5rp31mQUmp4csvzoVXBMAu0Zf5uj1rbOPIInJymbarBuN/m3cQRScxDyH0198A4fXfVxGU8uXaRsemEM+9Y78o0VOW7nyyrYnN8YprqpKrvsAnNrDd3aN3UVVRIfsYXC0dMlezL9UiYDHU50NR2ydzND1s9NtkY3nI+6SbwqftOFYW1hoczvDLJlSwYZvqqG9/t4U0ibIz++RtIrB1rFAkBEF3k2wB6a/ularNCMeKaBdjyEEHEP++rWJBHLI1YgD1h7rmBHLFR36puu7UCCTHvoUKBAui16GivwrddekkPmjHRvaACuHvJ/9eyusPCSRjGpkOc7xk3jQN61+ErYS0kgsQADcO2/MNBsOfK1mXnV0wUe7dp2g+DMD9sqKU3o9g56/SntGdpmi0OmPQTgOpo3As0qjloGIS9Km7aPIe+z+o0BPrW80jH79kx8Iqehbj7Qhi3X0rZAA7JzxE2b4Pz8CeeiuFjJDXXGV+Jg4w7gNkocPGyyesM6se8zuOQ2SFaDNmmfol2fdlWRJKw8r3pYAujq0he4dGn5tZpnEtjH6a/NqVFNkK19aEwbGNE1gtoBEhApIv8LSoGsynuu9hyPu47koqwXT+YWMkJhCzuJuk9k2j9IBOSPmMtiqkf5TjOWYvKl/lTpNeuSgPsDPChGMN0prlvqDYiDbCSMQRe5ei/56Fy4VmSob2LJViMSCEEQPgYqRlR5O9oY1DlzsscwVpUmwzl/p47kqr8tUaoWkJAJlZNiiIgLgiBjQTEtMNERnXVtAYsWByzerMzNdI2ACzaHRQfuoQTjgbwjrkBBFqWmretJrMumNO73YLP3S1XNO3tYUh6euwbZUYpAxnSn0BQ8yqJUYaMmKKe7xCgv4KGNP+1Y6Iygyz9vLyoDVqkFl0gfhMBvYbquZiqAxiFqa2Ed7xOR4ciMjL12wkm1txLyH415h7WrI6nYujMdk2wsRSO82I1Z9JVa5ou+CkOzREYVdhPXwCo1/b6ex1zH7sCUGln8CLbSmS8JvQZ8A0+AVlmzyU691U8Rd6X5oL703qfGEr47ZfSj6C/xj7GgqCUsap3drjPLhVKvbRXsNOpllgQL9VZF9btMJKLc3tK82xZgYAG0vFclV54dzqUoeq/n64TDZ6twV2UxUBbb1mqKgu+3pxSPoC8to2+Xn8/7WeHoJcEF/2A9qsTiNLPcJalPmiwJ297zRV9hdYdndTWjLxj+QHtr2naqrhd341JP19Bk0XxXMr974tLVzj/I8VU57/2+hxDaTtvUPr/5hKCNeXd9EKAhQmRbhHcL2KLgyl38GEKTQsYAuso/0rFFw4Pjy/aGX+lTA0kLx/p0Ya4WBtFo2XwhLvNsjddNfaMHkZKQ0ioBVdKrBcTO87Gj11P6EjRSRE3cB7wD2NdEl8nTw3nPi0TYLxD1m+TzrtCE7VtVhX4RbIa4csh3AC3ILVGcRb06nXclTxyNQEywRFQP3aTJcpt8Brfy5HeUe/WFWy+on1YUXS+4ArrCFV1ruFmFkx12oUVmc40AyHYddsuj7fdUfpebNeKlYCERO4KQ0MBrcjYFTMohDrA0ps8agnYRzvbEMgVm4pb2f+hbdbYtQ8PU7qVCU9iZRyI9j5N3nZV+InfuBzZ1sO4dds32aDsLciBqzPGo/WUfTRgx/kj7+rtzov2SrMdHSLtbTOQwHcyk56yHPnj1ZBZjQ+qNXrUlWLclNE5F+gn7eIODvjoiYJW9rK++vuc3ZNheYYUv3euFSepeJ4jmYBEiJBc0mF2zbYi9TuxdKLklbqxsNzGs8T89i/S+dD8QmvKevz8jp5JX5JBEJeFJmSD3wsNp7yD8s6hksJdugK4e/wrJmCse30cESeFOsk6NIMUG/mMHf0n4kN9AxLVEJOG4lUNzVCuEv7cfQl8xg45GzKWH9O6nE0kDDAmMSeNw2itho+5sIzMkSXpBd/JB5V3ogN9CnJg/WjzkIkh0xtYZvofIS5jMphcsLIfsn5qtUeMWaqn+W7PVSoeCLuOjj3/p3AY3bFS3NtROBdYW+Nx7iLxH86/NmSaHNtiUUdo7TYbo235rhS2H3giLrSQCn3sPsVc8ZlpgMKylGWRmTOyGizS9zEKKsJRT+KzbYTcm1lGLPLdUjQRdwZ5+yZoPvWuxxdWabODno3ni9iVPDQg+b/tlU1JuTIs0Zt5yaPulQNAu1Nd5p0pjki1I9I97Dx5uH/x86pCC0Lt6DpQZt326FnR7Cz9BBgUp0xp8JE7uxx1pB1v+9MpuaJGq2PuokMCkpnVL0dZMHj9W6hM4f5HhslTywTyOhDy2E19t/Ed8Ju5RHikVsxJ3UanB8ZC8kOo+ebQaSgpcsdS70ppYKJR/VlpIVY4sY2vf8WmQ+gVwl1ulLEFnR43SwcOxvdAVdFpNqgPU3Q7x00a59odb6uOVlCM2G6jAw8LUyS+WpO10exWMTC0mZJVFjVCUjgeR9tZHksLtcSYQBKij7nMtZaWaP9RXlX5W7aLialcdsN76nTb90QCnizX0qjdf5/012qnWpr24WmJg2FQh5haE94G54oYqlB/1ojOxH1CoN1prZW5m0KMX4Bv3SrZAj5rYE6lbzyu93IK5nBS64dveY5Uis18SW3HqnAsJEurgYnY+rFbNbVtaMjuTndNSWhuds3l3m1Ra19lhR1Zvej1KQumm2eZiMlvdA5t5qT4r8446/rzbTjEPv3HR4gse2fbM3/V0tnWB18nkKyzqiY3z4rwi5FKmxcWVvR9bnT4O1oPTZck5sBDrbtaDKpP9ghZFoalCdFsFi7lc7L7rrZ/z7tb9QVjvXOCs2Mfuw9qoEH+tnuUeh+mxuKq70TYpKW9vjSy7Ck2O8b5LbKbH5rDvLqrurpxOqt4mJSGou7tm2POlxdTFXS7kaXO4HZpszLrfxztP8+PpkH5R7Pzwww8//PDDDz/88MMP/yv8B1Phw+igFbidAAAAAElFTkSuQmCC
That is the image, stored as a base64 encoded string.
So they're not giving you a link to the image, and are instead giving you the image data directly.
Copy and paste everything after the first comma into e.g. https://www.base64decode.org/ and you'll see the picture.
This article gives a very detailed breakdown on why someone might choose to do so. One of the main reasons is to cut down the number of requests to your webserver. (clicking that link did not make a request to google, as you had already downloaded the data)
this image is just encoded using base64.
why people do this ? depend on the project. This way your page will be a bit heavier, but your image will be inside the page. If you use an URL, to load your image the browser will need to make a call.
Maybe the best call to do that, is this way you don't depend on another website to save and keep your image
So this is an interesting one. I did a test of using the clown car technique for showing responsive images via svgs loaded via an object tag because I really like the approach.
Now this works all fine, except when you have a few of them on one page with the cache normally activated, you leave the site to go to anywhere else in the interwebs and then press the back button - suddenly all images are mixed up, even though the code is still correct, ie:
object 1 loads svg that shows image from object 3
object 3 loads svg that shows image from object 5
etc.
Totally random and I just can't explain how this can happen. And it only ever happens when I go back to the page via the back command of the browser (chrome).
Has anyone experienced anything like this before??
I guess I'll stick to good old normal images for now...
Just ran into the same bug. And so did Google!
I suppose we'll have to use inline SVGs as loading through <img> tags aren't a possibility for me.
If you only have a single page app, you could add target="_blank" to your <a> tags to ensure the back button will come into play far less.
Since some days I'm experiencing this problem.
Here is my debug
The image provided is bigger than 200x200 px, it has unique link and there is any redirection on that page.
Linter response is 200.
When I copy and past page's link on fb it give me the choice between 3 images that are smaller than 200x200px and the one I've provided is ignored.
But If I try to share it through "Like button" or "Send button" it works fine.
It sounds like a fb Bug.
Thx
I solved using informations from this and this posts.
You can try using an image that is bigger than 200x200, with dimensions multiple of 100, and squared.
Other useful stuffs are using jpg extension, host the image in the same server of the website and avoid any "strange" chars in filename.
I tried many of the suggestions on this post and others to no avail. The thing finally worked for me (which I have not seen elsewhere) was to add the correct prefix to the element which I previously was missing entirely.
<head prefix="og: http://ogp.me/ns#">
Not sure if that actually fixed the problem for good or it just jogged the debugger into re-scanning the image (properly) but hopefully it helps someone else.
I got it done by renaming the image and the og:image url. Give it a try.
I have been struggling with this for a while too. I have tried all shapes and size for the image, renaming it, adding specific og:image:height and :width tags, etc.
The way I 'solved' it is just putting the image I want to show up in the website's root directory and point in og:image to another (1500x1500, btw) image. Facebook linter then tells me that it will use the image in the root directory. And that just works fine ;-)
Even if your image size is not in multiples of 100, it should work if your image is in jpg or jpeg format.
If your image is in png format, no matter what the size is, it will not work. This is based on my tests only. I would like to hear from other devs here.
I use png's all the time. I always use 1920 x 1080 because they look so good on Facebook shares. 85% of the time they work, sometimes they don't. Sometimes I delete and reload the same photo without renaming or changing a thing and it all of a sudden works. I'm not a real dev so that's all I can offer.
I tried most of these suggestions - double-checked the <head> prefix, tried adding the javascript sdk, tried square images, sourcing from different locations, simplifying the file name...
What finally worked was making sure an <img> tag for the same image appears in the body! I hid it with CSS / inline style.
As of this morning (12th July) a server script we used to automatically add updates to a facebook page is including a thumbail of the website logo.
We add an image ourselves if there is a suitable one - but leave the picture variable as blank otherwise.
As of today Facebook grabs the image set in the webpage og:image setting (or the first off the page if that is disabled) and adds it to the post update.
Net result, every single post this morning has the site logo as an image, and it looks a right mess.
Question - how can I set the image variable to NULL (or equiv) so that it wont try to generate a thumbnail where one is not explicitly defined?
Thanks
(Every help search I make returns results explaining how to add a thumbail - I want to get rid of it!)
A slight workaround has been to define the thumbnail image as a 1x1 png file, which forces it to use that instead of grabbing the site logo off the linked webpage.
Would still prefer to find a way of forcing it to not use a thumbnail at all though - as was the default behaviour until a couple of days ago.