og:meta-tags not rendered in hexo generate / works in hexo server

[kirkcameron]

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.

[NoahDragon]

Reference to the #2451

[benc-uk]

I'm seeing similar behavior I've modified the default landscape theme to take a custom icon variable from each post and render it in the header, it falls back to a default icon set in the theme config as follows:

<%- partial('_partial/header', {bannerIcon: page.icon || theme.default_icon || ''}, {cache: !config.relative_link}) %>

When running under hexo serve it works exactly as I'd expect, when I run hexo gen and serve static content I never get the icon value from the page variable (which I set in the front matter of course)

[NoahDragon]

@benc-uk We are aware the difference between hexo g and hexo s, but haven't come up a solution yet. The plan is to fix it in the next build.

[kirkcameron]

can you approx say, when the next release is available?

…

Am 20.04.2017 um 16:39 schrieb Abner Chou ***@***.***>: @benc-uk <https://github.com/benc-uk> We are aware the difference between hexo g and hexo s, but haven't come up a solution yet. The plan is to fix it in the next build. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2503 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZN_pqRn7X4f8FbqIbtCZEsNIDFdC_G8ks5rx24TgaJpZM4M3-du>.

[geedew]

@kirkcameron @benc-uk Can you confirm whether you have a layout file that is using the {cache:true} option set on the partial that loads the open_graph tag? I had the same issue, and then realized I was caching the partial that was loading my header which then caused this issue. Take a look, that might also have been your issue! hexo s must not respect the cache:true?

[curbengh]

hexo s must not respect the cache:true?

According to #3756 (I wasn't aware of the caching behavior), seems like hexo g uses fragment cache, but not hexo s. That PR would enable it for both mode, so probably can fix the render difference caused by caching (which might not be relevant to this issue).

[dailyrandomphoto]

If a partial template that contains like 'open_graph', it should set the cache option as false or omit cache option.
e.g.

{{ partial('_partials/header.swig', {}, {cache: theme.cache.enable}) }}

=>

{{ partial('_partials/header.swig', {}) }}

see #3756 (comment)

[stevenjoezhang]

Looks like this issue is caused by the fragment cache.
I'm closing this issue. Please join the discussion in #2451