Additional/alternate images not displayed in Facebook generated share previews

[spinks]

When using more than one image (logo), Facebook does not appear to generate the correct image. The secondary images are not added.

Facebook also does not use the correct first image (logo), instead using the default. This issue does not seem to be present for other sites like Twitter.

I am not sure what could be causing it.

Below are some examples, taken from the Next.js documentation pages about CMSs. They illustrate how the first icon is incorrect, (Vercel as opposed to Next.js) and the secondary ones are not present.

FB Generated	Actual	FB Sharing Debugger
		Prismic Example
		Wordpress Example

[styfle]

Looks like facebook is stripping the query string.

Did you try encoding the URI?

[spinks]

Yeah it would appear so. They seem to serve them through their own safe_image endpoint.

I tried encodeURI on the generated image link, but that broke the additional image content and text, and additionally was still ignored by Facebook. Unless you mean to encode at a different point.

[styfle]

What is safe_image?

Perhaps they assume the query string is malicious and strip it? Or maybe it is too long?

[spinks]

What is safe_image?

For example the Prismic image is served as

<img class="scaledImageFitWidth img" 
src="https://external-lht6-1.xx.fbcdn.net/safe_image.php?d=AQAj_z3s3CGmYiiP&amp;w=540&amp;h=282&amp;url=https%3A%2F%2Fog-image.now.sh%2FNext.js%2520Blog%2520Example%2520with%2520%2A%2APrismic%2A%2A.png%3Ftheme%3Dlight%26md%3D1%26fontSize%3D75px%26images%3Dhttps%253A%252F%252Fassets.zeit.co%252Fimage%252Fupload%252Ffront%252Fassets%252Fdesign%252Fnextjs-black-logo.svg%26images%3Dhttps%253A%252F%252Fi.imgur.com%252FGVmKYul.png%26widths%3Dundefined%26widths%3Dauto%26heights%3Dundefined%26heights%3D100&amp;cfs=1&amp;upscale=1&amp;fallback=news_d_placeholder_publisher&amp;_nc_hash=AQCdMzQI9yj5Tu8o" 
data-src="https://external-lht6-1.xx.fbcdn.net/safe_image.php?d=AQAj_z3s3CGmYiiP&amp;w=540&amp;h=282&amp;url=https%3A%2F%2Fog-image.now.sh%2FNext.js%2520Blog%2520Example%2520with%2520%2A%2APrismic%2A%2A.png%3Ftheme%3Dlight%26md%3D1%26fontSize%3D75px%26images%3Dhttps%253A%252F%252Fassets.zeit.co%252Fimage%252Fupload%252Ffront%252Fassets%252Fdesign%252Fnextjs-black-logo.svg%26images%3Dhttps%253A%252F%252Fi.imgur.com%252FGVmKYul.png%26widths%3Dundefined%26widths%3Dauto%26heights%3Dundefined%26heights%3D100&amp;cfs=1&amp;upscale=1&amp;fallback=news_d_placeholder_publisher&amp;_nc_hash=AQCdMzQI9yj5Tu8o" 
style="top:0px;" alt="" width="524" height="274" caption="">

Perhaps they assume the query string is malicious and strip it? Or maybe it is too long?

I've tested toggling the color theme from light to dark and additionally the font size. These both work fine and are reflected in the FB share. As these are after the query string it shows it is not being entirely stripped. Probably they're considering the URLs for the images malicious? and removing those parameters.

[spinks]

As an update, I have looked into it further, mostly just through trial and error.

It appears that FB processing operates on two fronts.

1. Removes parameters which have obvious (simple URI encoding) URLs in them. I have tested getting around this by simply reversing the URL string in parameter creation and again at parsing. This works and allows the parameter through.
2. Removes repeated parameters, leaving only the last instance of it. This came up only after I was able to get the URLs through via reversal or some other non-obvious URL encoding, as I found that FB was generating images with only the last image parameter.

This is just through my testing so may not be 100% accurate.

A solution I have come up with to get all the image information through FB involves creating an object of the urls, heights and widths. This is then JSON stringified and added as the image parameter. The JSON stringification is seemingly non-obvious enough that FB does not detect the URLs and strip the parameter. As this also allows for all information in one parameter it does not run into the repeated parameter removal issue.

Obviously this fix would be a breaking change going forwards, but it could be introduced as a new parameter which if present means the old images, widths and heights are ignored?

Would be interested to hear if you have any ideas on how to resolve these restrictions? @styfle

[styfle]

That might work, but a better solution for your use case is to fork this repo and make changes that suite your needs.

Likely any major change is going to take a long time to review.

[spinks]

Yep totally agree.

If you're interested I have an implementation here spinks/og-image@45439b7. For me this works with Facebook, and allows for falling back to the current parameter structure.

[styfle]

Thanks for investigating!

I'll circle back here when I have more time and I'll leave this issue open in case someone runs into the same problem.

Great work 🎉

[leerob]

Closing in favor of #226