first things first: both screenshots are taken from the exact same article.
this screenshot shows the result from hexo generate (contains only static meta tags) => og:image is hardcoded here:
this screenshot shows the result from hexo server - for some reason after "!upgrading! hexo from 3.3.2 to 3.3.1 (after npm ugrade hexo)" it does not work properly anymore with og:image - there are four images within my post, but the img-urls are incorrectly pointing to the logo-pic most likely taken from the config file),
❗️ but as you can see it still works somehow with twitter:image ❗️
@NoahDragon
cc: @WeAthFoLD
previous (incorrectly closed) ticket: #2454
as you can see, there are a lot of tags not rendered from hexo generate at all!!! (i.e. description, title, keywords, etc.) => must be a context issue, when running with hexo g (a lot of "variables" are not filled the same way, as when running with hexo s)
version: hexo 3.3.1
theme: adapted version of hueman
when using
hexo server
at least twitter:image meta tags are somehow rendered properly, but og:image now is even wrong with hexo s. (was correct with previous version 3.3.2 <= which is anyway strange how an upgrade reduces the version number)
when using
hexo generate
og:image meta tags are not rendered at all
expectation: it should take all pictures from the post (not from the frontmatter, even if this would be a fallback, which could be acceptable) and render it for og:image as well as all other missing meta information (i.e. description, title, keywords, etc.)
link to my live page: http://hebammenzentrum-graz.at/2016/01/01/Babymassage/ (check the < head > section)
❗️ if og:image does not exist, facebook does not show article-photos anymore, which is really bad ❗️
it would be really good, if this could get some prio, because this fucks up sharing to facebook totally since facebook started to be very strict with open_graph and a lot of other service started to rely on fb-open_graph tags => example, how a shared posting looks like with this bug (no photo, no description, no keywords, no nothing) => (!)and this totally destroys the benefit of hexo in a real world use case(!):
more ideas about og:image:
it would be good to add
❗️❗️❗️❗️og:image:secure_url❗️❗️❗️❗️
to open_graph.js as well, as it is wanted from facebook if the website is running with https: <= which is the case in my world. (og:image:secure_url is so far not doing any harm, if the page is not running with https:)
❗️ as far as i can see, og:image is missing in the open_graph test case. ❗️
from my point of view open_graph (for images) should work in this order:
use a picture, if it is configured in front-matter (can be photos, thumbnail, opengraph_pictures, whatever - somebody needs to decide what is the best name)
if no photo is configured in frontmatter - use all photos, which are used within the body (works with hexo s)
if post/page does not contain a photo use config.logo (or similar)
at the end it is important, that at least some picture is connected to the post/page via og:image ... could be even a hexo-logo as a final fallback.
let me know, if you need more information, please.
first things first: both screenshots are taken from the exact same article.
this screenshot shows the result from hexo generate (contains only static meta tags) => og:image is hardcoded here:
this screenshot shows the result from hexo server - for some reason after "!upgrading! hexo from 3.3.2 to 3.3.1 (after npm ugrade hexo)" it does not work properly anymore with og:image - there are four images within my post, but the img-urls are incorrectly pointing to the logo-pic most likely taken from the config file),
❗️ but as you can see it still works somehow with twitter:image ❗️
@NoahDragon
cc: @WeAthFoLD
previous (incorrectly closed) ticket: #2454
as you can see, there are a lot of tags not rendered from hexo generate at all!!! (i.e. description, title, keywords, etc.) => must be a context issue, when running with hexo g (a lot of "variables" are not filled the same way, as when running with hexo s)
version: hexo 3.3.1
theme: adapted version of hueman
when using
hexo server
at least twitter:image meta tags are somehow rendered properly, but og:image now is even wrong with hexo s. (was correct with previous version 3.3.2 <= which is anyway strange how an upgrade reduces the version number)
when using
hexo generate
og:image meta tags are not rendered at all
expectation: it should take all pictures from the post (not from the frontmatter, even if this would be a fallback, which could be acceptable) and render it for og:image as well as all other missing meta information (i.e. description, title, keywords, etc.)
link to my live page: http://hebammenzentrum-graz.at/2016/01/01/Babymassage/ (check the < head > section)
❗️ if og:image does not exist, facebook does not show article-photos anymore, which is really bad ❗️
it would be really good, if this could get some prio, because this fucks up sharing to facebook totally since facebook started to be very strict with open_graph and a lot of other service started to rely on fb-open_graph tags => example, how a shared posting looks like with this bug (no photo, no description, no keywords, no nothing) => (!)and this totally destroys the benefit of hexo in a real world use case(!):
more ideas about og:image:
it would be good to add
❗️❗️❗️❗️og:image:secure_url❗️❗️❗️❗️
to open_graph.js as well, as it is wanted from facebook if the website is running with https: <= which is the case in my world. (og:image:secure_url is so far not doing any harm, if the page is not running with https:)
❗️ as far as i can see, og:image is missing in the open_graph test case. ❗️
from my point of view open_graph (for images) should work in this order:
use a picture, if it is configured in front-matter (can be photos, thumbnail, opengraph_pictures, whatever - somebody needs to decide what is the best name)
if no photo is configured in frontmatter - use all photos, which are used within the body (works with hexo s)
if post/page does not contain a photo use config.logo (or similar)
at the end it is important, that at least some picture is connected to the post/page via og:image ... could be even a hexo-logo as a final fallback.
let me know, if you need more information, please.