Implementation of automatic Open Graph image generation for collection pages

[tribal2]

I'm currently working on adding automatic Open Graph image generation for collection pages, inspired by the approach detailed in this post.

My progress can be seen in the branch: feat/docs-og:

I would greatly appreciate any feedback or suggestions on this implementation. If this aligns with our project goals, I'm eager to continue refining this feature.

[tribal2]

I have some questions:

1. Why is the docs collection not using a base path as the other collections? This might cause collisions with Astro pages published in the pages directory:

   http://localhost:4321/guides/getting-started          (actual)
   http://localhost:4321/docs/guides/getting-started     (suggested)
                       ^^^^

2. What do you think about requiring a title and description properties in all the collection schemas? Right now the products collection doesn't have any of this properties in the root of the schema

[mearashadowfax]

1. Why is the docs collection not using a base path as the other collections?

There is a hacky solution where we can nest the docs collection within a second docs folder like src/content/docs/docs to prefix all Starlight paths with /docs. So getting-started.md will be at src/content/docs/docs/guides/getting-started and display as http://localhost:4321/docs/guides/getting-started. I tried this at first, but then reverted back to the default option.

2. What do you think about requiring a title and description properties in all the collection schemas? Right now the products collection doesn't have any of this properties in the root of the schema

Yep, that's right. For the products collection, it would be main.title and main.subTitle. To be honest, I don't know; I just tried a different approach, plus reserved description for the actual long description, with its own title and subTitle.

I've read the post and checked the repo; it looks like if we are implementing automatic OG generation, the collection schemas should be identical across collections. I will refactor the products accordingly, so we can use

getImageOptions: (_path, page: (typeof pages)[number]) => {
    return {
      // Use the page title and description as the image title and description.
      title: page.data.title,
      description: page.data.description,
      // Customize various colors and add a border.
      ...
    }

from the post.

[newbeelearn]

for og image generation, this is also a good reference https://astro-paper.pages.dev/posts/dynamic-og-image-generation-in-astropaper-blog-posts/ This is another theme that has dynamic og https://github.com/chrismwilliams/astro-theme-cactus Library used by these guys is very good library for image generation https://github.com/vercel/satori with this library you can use existing html/css to generate the images. You can see the examples of input and output here https://og-playground.vercel.app/ . Please consider this approach as well.

[tribal2]

There is a hacky solution where we can nest the docs collection within a second docs folder

You are right, this is the only way according to the Starlight docs: https://starlight.astro.build/manual-setup/#use-starlight-at-a-subpath

In the future, we plan to support this use case better to avoid the need for the extra nested directory in src/content/docs/.

[tribal2]

@newbeelearn thanks for the references.. I'm using a similar approach in my portfolio site with @vercel/og. I followed this guide and this is the result:

A bit harder to set up but much more flexible

[newbeelearn]

i am unable to find the source code of this library https://www.npmjs.com/package/@vercel/og , it looks like it would be using vercel edge functions also refer to this https://github.com/vercel/og-image/issues/226#issuecomment-1278124064 . I am afraid this looks like a big limitation to force all the theme users to use some commercial service. It also seems to require setting up wasm, if all theme users are required to do this it would complicate the setup.

[mearashadowfax]

Well, if that's the case, I think it would be better to stick to Hideoo's implementation. We can always reference other options for users to decide which one to choose.