I’ve tried to define an og:image with a square icon/logo to help the ‘cropped logo’ issue on posts with no images, but then if there are any other images within that we would prefer, the square og:image overrides any images contained in the post.
No, these are not my posts, I’ve just been experiencing the same issues.
Take for example:
Which is a post with a single image of 1280x720px, definitely enough to meet FB standards to pick it the image.
Running it through the Facebook object debugger you see the og:image set to the avatar (I’ve since removed the defined og:image logo as it was overriding all images) and the og:description set to only the image details in text form.
Perhaps we should rename this thread since I suppose the topic has returned to the Facebook issues. In any case, if there’s any way I can help I would be happy to, it is very much a top priority for my client right now who sees it as a barrier to promoting and really pushing the platform.
I’m not sure, but I feel like adding property="og:image" to the first or largest image in the topic post would be hugely beneficial along with og:description to a sanitized version of the excerpt to help ensure that shares are descriptive and also more interesting with topic-oriented images rather than the cropped logo or a pixelated avatar.
Do you think there might be any benefit in some kind of dynamic opengraph tag generation or is that not a good idea? I feel like the process could be somewhat simple along the lines of (in pseudocode):
Check requested URL if it is the topic post, or a deep link to a specific reply
Parse the appropriate topic or reply and inject the opengraph meta tags into the header accordingly
For each image in the topic or specified reply
Title of the topic
Excerpt from the topic or the specified reply
Thus the opengraph tags would only need to be set once on the initial load since that’s what Facebook would be parsing, and thus sharing a Topic versus a Reply would generate an accurate representation of what is being shared.
Unfortunately I’m a bit at a loss of where to start digging were I to be able to build something and make a pull request.
Originally I had been looking at /app/views/layouts/application.html.erb and tried manually inputting some og:image meta tags just to see if it would help things and was genuinely confused when I could see these tags in the source but not in the Facebook debugger.
After reading the thread above I realized there was code in /app/views/topics/show.html.erb:
The particular code in question being the crawlable_meta_data...
I don’t know why the reasoning behind this code is to set the small avatar as the og:image viewable to the crawler. Our topic could have plenty of rich images specific to the topic, but be completely ignored by the Facebook sharer because the og:image is being dynamically set to a small avatar that doesn’t even meet Facebook requirements and thus results in a share result with no image at all (when using the sharing button).
I setup a completely fresh instance of discourse to make sure it wasn’t just my install or me going crazy and setup a simple topic with some images and text:
The possibility of sharing any of the other images has been overridden by an incompatible small avatar og:image that itself can’t even be displayed because it itself is too small. The share popup and preview seems to grab the images, but they never make it through to the actual post.
When I remove this crawlable_meta_data, the site behaves exactly as I would hope as Facebook is able to properly infer what the images are:
Am I alone in believing that the second behaviour is more desirable and beneficial? If we are implementing opengraph tags for the images at all, it would make so much more sense if they actually pulled the image from the topic itself and not just the avatar that isn’t even compatible with Facebook to begin with. (I know opengraph != Facebook, but it is an important and relevant example of how opengraph is leveraged to bring users towards a discourse platform).
I feel, from my limited understanding, simply the task of populating image_url with images from the topic and not just with the avatar image. I would really appreciate your thoughts on this subject.
I didn’t make my current fix a PR because I figured the solution I had wasn’t exactly ideal – it is simply a complete removal of the opengraph tags that are set through the crawlable_meta_data function. I’m not sure how to go about the next step, but I feel like the proper solution would be parsing the topic and then setting image_url to one of these images rather than the avatar, but wanted to know if this was a reasonable suggestion?