Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

og:image meta tag not generated correctly with img_path #754

Closed
3 tasks done
joshjohanning opened this issue Nov 13, 2022 · 15 comments
Closed
3 tasks done

og:image meta tag not generated correctly with img_path #754

joshjohanning opened this issue Nov 13, 2022 · 15 comments
Labels
bug Something isn't working

Comments

@joshjohanning
Copy link
Collaborator

joshjohanning commented Nov 13, 2022

Checklist

  • I have read the tutorials and know the correct effect of the functional design.
  • There are no similar reports on existing issues (including closed ones).
  • I found the bug on the latest code of the master branch.

Describe the bug

It looks like the image post works when using img_path (ie: using the short path), but the og:image meta tag doesn't render correctly.

See my example post.

The title image shows up correctly in the post, but because I am using img_path, it doesn't seem that the og:image tag renders correctly.

Markdown:

img_path: /assets/screenshots/2022-10-12-using-github-checks-api
image:
  path: status-check.gif

If searching the source of the page, you will find:

<meta property="og:image" content="https://josh-ops.com/status-check.gif" />

The image should be:

https://josh-ops.com/assets/screenshots/2022-10-12-using-github-checks-api/status-check.gif

At least according to the docs, this should work:

In addition, the [img_path](https://chirpy.cotes.page/posts/write-a-new-post/#image-path) can also be passed to the preview image, that is, when it has been set, the attribute path only needs the image file name.

To Reproduce

Steps to reproduce the behavior:

  1. Use img_path
  2. Use short version of image for the post's image
  3. Search html to find the og:image tag

Expected behavior

Using correct version of image path

Screenshots

n/a

Environment

Command Version
ruby -v
gem -v
bundle -v
bundle exec jekyll -v
bundle info jekyll-theme-chirpy

Desktop

macOS latest
Chrome latest

Smartphone

n/a

Additional context

cc joshjohanning/joshjohanning.github.io#21 and credits to @ruzickap

@cotes2020
Copy link
Owner

Thanks for the report! The twitter:image in <head> will also be missing img_path.

@joshjohanning
Copy link
Collaborator Author

Hi @cotes2020! I deployed this update, but it still looks like the issue persists? My source still looking like this:

<meta property="twitter:image" content="https://josh-ops.com/status-check.gif" />
<meta property="og:image" content="https://josh-ops.com/status-check.gif" />

I'm not using a CDN, which differs from what you're using in your instance, I believe.

From this line:

{% if site.img_cdn and seo_tags contains 'og:image' %}

if I remove site.img_cdn and so that the line is now:

  {% if seo_tags contains 'og:image' %}

then it works:

<meta property="og:image" content="http://localhost:4000/assets/screenshots/2022-10-12-using-github-checks-api/status-check.gif" />
<meta property="twitter:image" content="http://localhost:4000/assets/screenshots/2022-10-12-using-github-checks-api/status-check.gif" />

This also worked

  {% if site.img_cdn != empty and seo_tags contains 'og:image' %}

Not really an expert in this, so not sure what the intent is with site.img_cdn here 😄

@cotes2020
Copy link
Owner

Ah, looks like I submitted a bad patch, thanks for testing.

After more in-depth debugging, the same problem will occur if the baseurl is set. I will rewrite the last commit to the master branch to perfect the fix.

cotes2020 added a commit that referenced this issue Nov 16, 2022
This issue occurs when setting the `img_path` of the post or the `baseurl` of the site configuration.
@joshjohanning
Copy link
Collaborator Author

joshjohanning commented Nov 16, 2022

Woot! It works, and image even shows when posting on Twitter now :)

image

@joshjohanning
Copy link
Collaborator Author

joshjohanning commented Nov 16, 2022

@cotes2020 okay maybe one minor thing left here that I noticed investigating my source:

image

image":{"width":"100%","height":"100%","alt":"Example of Status Checks in a Pull Request","url":"https://josh-ops.com/status-check.gif","@type":"imageObject"},"

It looks like there is one last reference to the site.baseurl/page.image.path pathing in the source. Not sure what this one might be used for, but I think that's the last hold out.

Nothing fails to load on the page, so it's more of a meta object/tag.

What do you think?

@cotes2020
Copy link
Owner

Are you confused by this line?

{% capture replacement %}<meta property="{{ prop }}" content="{{ site.url }}{{ page.img_path | relative_url }}{% endcapture %}

Also, how are these contents obtained?

image":{"width":"100%","height":"100%","alt":"Example of Status Checks in a Pull Request","url":"https://josh-ops.com/status-check.gif","@type":"imageObject"},"

@joshjohanning
Copy link
Collaborator Author

Yeah, kind of! I wasn't expecting to see a reference to an unreachable image in the above snippet.

https://josh-ops.com/status-check.gif

when it should be

https://josh-ops.com/assets/screenshots/2022-10-12-using-github-checks-api/status-check.gif

Just like how we (well, you) cleaned up the og:image and twitter:image in the source, I thought that there was maybe one more that was missed.

@cotes2020
Copy link
Owner

{% capture replacement %}<meta property="{{ prop }}" content="{{ site.url }}{{ page.img_path | relative_url }}{% endcapture %}

The above code can generate the correct URL no matter whether site.baseurl is assigned or not.

... I wasn't expecting to see a reference to an unreachable image in the above snippet.

https://josh-ops.com/status-check.gif

when it should be

https://josh-ops.com/assets/screenshots/2022-10-12-using-github-checks-api/status-check.gif

Now I don't quite understand what you mean. Are you getting an incomplete URL path after testing 59b5562? If yes, please list the specific configuration: What are the values of site.baseurl, site.img_cdn, page.img_path respectively?

@joshjohanning
Copy link
Collaborator Author

joshjohanning commented Nov 16, 2022

Yes, I applied 59b5562, and that fixed the og:image and twitter:image.

However, go to my post: https://josh-ops.com/posts/using-github-checks-api/

If you right click and view the source, you'll find a similar issue with the image:

"url":"https://josh-ops.com/status-check.gif","@type":"imageObject"}

This is in the @context tag
Here's a quick video of what I mean. The first two results have the correct path of the image, per the patch in 59b5562. But the third result has the incorrect path for the post image.

Screen.Recording.2022-11-16.at.3.51.51.PM.mov

So, I think there is one more thing that needs to be patched to fully fix this. I can't find where in the codebase this is coming from though :(.

@cotes2020
Copy link
Owner

Like those SEO-related meta tags, the content inside <script type="application/ld+json">...</script> is also generated by the SEO plugin.

spec.add_runtime_dependency "jekyll-seo-tag", "~> 2.7"

Will fix it soon, thanks for the video demo. 👍

cotes2020 added a commit that referenced this issue Nov 16, 2022
This issue occurs when setting the `img_path` of the post or the `baseurl` of the site configuration.
@joshjohanning
Copy link
Collaborator Author

joshjohanning commented Nov 17, 2022

Ahhh - so actually, this made it worse for me, because I didn't have a / at the end of my img_path.

So now it renders as:

https://josh-ops.com/assets/screenshots/2022-10-12-using-github-checks-apistatus-check.gif

When it should be:

https://josh-ops.com/assets/screenshots/2022-10-12-using-github-checks-api/status-check.gif

I can fix this though in my posts - should I just plan to put a / at the end of my img_path property's in my posts?

- img_path: /assets/screenshots/2022-10-12-using-github-checks-api
+ img_path: /assets/screenshots/2022-10-12-using-github-checks-api/

I think the logic here 59b5562 was slightly more robust, but now that I know how it works I am good with the solution of appending a /. Your docs have the / at the end, too.

Thanks for all of the debugging 🎉

@cotes2020
Copy link
Owner

By now, img_path should end with /. Maybe some improvements will be added in the future to support it without forward slash.

@joshjohanning
Copy link
Collaborator Author

By now, img_path should end with /. Maybe some improvements will be added in the future to support it without forward slash.

Works for me, thank you for confirming!

Is there a way to update the post for something like this without modifying the "updated" time ?

@cotes2020
Copy link
Owner

cotes2020 commented Nov 18, 2022

You can use git to merge the post's temporary commit into the previous commit.

As a reminder, da7d7e2 supports img_path withou / at the end.

@joshjohanning
Copy link
Collaborator Author

Woot! It's all fixed now with da7d7e2 😄 🎉 Thanks @cotes2020!!

shihtiy-tw pushed a commit to shihtiy-tw/shihtiy-tw.github.io that referenced this issue Nov 26, 2022
This issue occurs when setting the `img_path` of the post or the `baseurl` of the site configuration.
songkg7 pushed a commit to songkg7/songkg7.github.io-legacy that referenced this issue Dec 10, 2022
This issue occurs when setting the `img_path` of the post or the `baseurl` of the site configuration.
sanjidnet pushed a commit to sanjidnet/sanjidnet.github.io that referenced this issue Jan 9, 2023
This issue occurs when setting the `img_path` of the post or the `baseurl` of the site configuration.
linkliu pushed a commit to linkliu/game-tech-post-old that referenced this issue Jan 9, 2023
This issue occurs when setting the `img_path` of the post or the `baseurl` of the site configuration.

(cherry picked from commit f6e9a3f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants