Revise head-meta-opengraph.hbs

[mmattel]

Based on a discussion in an internal chat and audio.

Referencing: https://github.com/owncloud/docs-ui/blob/master/src/partials/head-meta-opengraph.hbs

Atm we do not use the og:image meta tag leading to a greay block when docs gets linked in social media:

Example and usage see:
https://kaydee.net/blog/open-graph-image/
https://moworks.com.au/moment/2021-04-13-open-graph-images-what-are-they-and-why-you-need-to-care

We could create some static product based images following social media rules and add them based on antora provided attributes like server, ocis, desktop, ios, android ect.
These images must be provided via https://github.com/owncloud/docs/tree/master/overlay to be linkable.

In addition, we should do a revision of the current og-tags if the output is as desired.

To check opengraph metadata use: https://opengraphcheck.com/
To preview opengraph content use: https://www.opengraph.xyz

@enbrnz @xoxys @EParzefall @michl19 @B3nWalter fyi

[mmattel]

We got from marketing a bunch of social media / owncloud conform images we can now use for og:image 😍

My idea is the following:

• Name the images in a way where we have a product identifyer and purpose in the name. The template scheme is product-opengraph.png where the name changes based on the product like:
  android-opengraph.png or server-opengraph.png or docs-opengraph.png
• Place the images in the docs repo into the overlay folder which is 1:1 copied to the web. This folder contains all files which are available on the webserver like eg the favicons ect.
• Add in docs a new global attribute in site.yml which contains the list of component names we have (individual doc repos, see uinque name in antora.yml). This attribute may then look like
  page-component-build-list: server, desktop, ios-app, android, ocis, user These names must 1:1 match the name in the corresponding antora.yml. From the technical pov, it is the heystack, see below
• Register a new handlebars helper which makes a query named contains available, see: https://stackoverflow.com/questions/15497794/handlebars-if-value-contains-x
• Note that we can use antora attibutes in handlebars as variable, see: https://docs.antora.org/antora/latest/page/attributes/
  In particular we will use page-component-name as needle to search for in the heystack created above
• Define the og:image used with a query like the following.
  Note that there is for sure an antora attribute we can use for the URL, I guess it is site-url
  See https://docs.antora.org/antora-ui-default/templates/#template-variables
  See: https://docs.antora.org/antora/latest/page/attributes/#custom-attributes

{{#contains {{page.component-name}} {{page.attributes.component-build-list}}}}
    <meta property="og:image" content="https://doc.owncloud.com/{{page.component-name}}-opengraph.png" />
{{else}}
    <meta property="og:image" content="https://doc.owncloud.com/docs-opengraph.png" />
{{/contains}}

The benefit of going this way would be, that we have to maintain docs-ui only once because docs-ui has no hardcoded values. All values are maintained in the corresponding repos.

Please share your thoughts

@xoxys can you help or advice how to implement the handlebars helper, so I could start testing the approach?

[mmattel]

Still missing: <meta property="og:description" content="" />

This property can only be filled by something coming from the page.

Proposal that we "attributize" the Introduction content of each page, at least a part of it and use the page attribute to fill the content variable.

Note that the same issue exists for google search short description where this approach can be reused.

ATM, this is rendered like this:

For the time being, I will add the page title as the content, so this does not look so weired.