OG Image Reworks

[tanishqmanuja]

PR for reworking OG image generation and routing logic

[tanishqmanuja]

Also made SITE.ogImage optional, if not provided a fallback (generated) image we be used instead.

[tanishqmanuja]

@satnaing, can you test the OG generation on your setup. Just to be extra sure :)

[satnaing]

Love it. Much simpler now.
Do you think there are any edge cases we might have missed?

I've checked special character issues and it all works well.

[tanishqmanuja]

It's difficult for a dev to find their own bugs 😅, So no edge cases that i can think of for now. I have tested the following cases:

• No ogImage tag provided in frontmatter of blog will create and use png from the endpoint
• ogImage works both when providing relative path like ./_images/foobar.png using astro image sourcing and absolute path in public folder /assets/foobar.png
• Using an external url like https://xyz.com/foobar.png (haven't tested this case on a deployed site but it should work just like before ig)

[satnaing]

@tanishqmanuja
I tested the following

• special characters in title
• relative path
• alias path
• absolute path
• external images

Relative Path

# image is `src/assets/example.png`
ogImage: "../../assets/example.png"

Alias Path

# image is `src/assets/example.png`
ogImage: "@assets/example.png" 

Absolute Path

# image is `public/example.png`
ogImage: /example.png

Everything seems to be okay.
I'm gonna merge your PR now. Thanks for your contribution. ✌🏻

[satnaing]

BTW @tanishqmanuja
Since you're familiar with these changes, would you be interested in collaborating on documenting the upgrade guide? However, it's okay if you have a busy schedule.

I'm planning to create a PR for the documentation tomorrow or on Saturday.

[tanishqmanuja]

Sure, I would help. Btw generally speaking I do not know for myself if there would be any easy migration path.

Case 1 - Template Repo:
If the user has made their repo using the "template" button on github. All the git history is wiped and merging unrelated history can be daunting, also considering they would have made some changes unique to their specific needs .. ITS A NIGHTMARE!

Case 2 - Forked Repo:
If the user has forked the repo and made some changes, It should be a matter of hours assuming they can handle merge conflict bc some commits will go straight for sure without any merge-conflict

Case 3 - A Fresh Start:
This option would be best if the user has done only minor/handful of changes to the actual repo source (excluding content). So then they could just fork/clone the updated repo, change some basic settings and copy their content folder over to version 3 and redeploy to their existing hosting.

BTW those are my thoughts, how are you planning to write the migration?

[satnaing]

Yep, agree with you. Mostly Case 3 would be the easiest approach.
However, there will be many users who can't do the second and third options (case 2/3).

For Case 1, I can't think of any approach other than using Git. I've also written an article about that.

If they don't want to do that, they can store/backup their changes and customizations. Those files and directories would probably be src/content/blog/, src/config.ts, src/pages/about.md, public/ and maybe src/styles/base.css. Then, replace anything else with the newer version of AstroPaper.

I think these are the only ideal ways to upgrade AstroPaper.
This v3 upgrade might be a little bit painful since I couldn't keep up to date with Astro versions regularly.
Gotta try harder for frequent minor updates in the future.