Social share preview doesn't work when sharing `http://project.example.com` instead of `http://project.example.com/latest`

[pekkaklarck]

Social share preview is controlled by meta tags such as description and og:image that Material for MkDocs social plugin can generate. When using mike, they don't work if you share a URL pointing to the project root like http://project.example.com, because the /index.html generated by set-version doesn't contain these meta tags. Only the target page contains them, so when sharing something like http://project.example.com/latest everything works fine. At least I prefer sharing shorter URLs so preview not working is a bit annoying.

Luckily the situation is easy to fix by copying relevant meta tags from /latest/index.html (or whatever is the default version) to /index.html. As an example, you can see the index.html file or the project I'm setting up. After these changes the preview works fine as seen here.

Although fixing the issue manually is easy, it would be great if set-default would copy the relevant meta tags automatically. It would have two main benefits:

• Everything would work fine automatically when versioning is set up. Users didn't need to think about this.
• It would be possible to run set-default again later if information has changed. Possibly mike could even keep /index.html it has generated updated automatically.

If this isn't considered worth the effort, adding a note about the problem to mike's docs would be good. Then those who care could fix their /index.html manually.

[jimporter]

You can change the template used to generate the default-version redirect via -T/--template, and include the relevant bits in your template. If you want to do some preprocessing to add dynamic values into the template that should be straightforward as well; in fact, mike is primarily designed as a "plumbing" tool (to use the Git terminology) that you can use in scripts to do what makes sense for your project.

Given that we probably don't want to copy over literally every meta tag (for a simple counterexample, we probably don't want viewport), and that the exact set of meta tags you would want depends on the theme, I don't think it would be wise to just pull them from the redirect target.

I could see some more general solution for this where mike passes a larger set of variables to the redirect template (beyond just the URL), and then a sufficiently-fancy redirect template could add all the relevant meta tags on its own.

[pekkaklarck]

The problem with using a template is that if the social share meta tags change, I'd need to update the template and then run set-default. That would work, but directly modifying /index.html is probably easier. The main problem is remembering updated if there are changes. Dynamically modifying the template would avoid that problem, but I could as easily dynamically modify /index.html as well.

I acknowledge it's not a good idea to copy all meta tags (that would actually be a really bad idea), but it would be easy to list the subset of meta tags to copy. For social share previews to work, that list would only contain meta tags matching patterns name="description" , property="og:.*" and name="twitter:.*", and I'm not sure is the last even relevant anymore. If there would be needs to copy meta tags for other usages, it would then be easy to extend the list.

Anyway, this isn't too important for me as I can maintain these meta tags myself and they don't change too often. I mainly wanted to notify about the problem, so that you can decide what to do to it. Just a note about the problem in documentation would be enough to let users know about it.

[jimporter]

That would work, but directly modifying /index.html is probably easier.

Well, perhaps. The benefit of using mike set-default is that you don't need to check out your gh-pages branch. It'll just fast-import the change onto that branch while you stay on your default branch.

I acknowledge it's not a good idea to copy all meta tags (that would actually be a really bad idea), but it would be easy to list the subset of meta tags to copy. For social share previews to work, that list would only contain meta tags matching patterns name="description" , property="og:.*" and name="twitter:.*", and I'm not sure is the last even relevant anymore. If there would be needs to copy meta tags for other usages, it would then be easy to extend the list.

My goal is to avoid having to add extra scaffolding that handles just this one scenario. Since the exact set of tags to copy isn't set in stone, that would mean adding more configuration options and likely adding another thing for me to maintain as people propose this or that meta tag to copy. However, if there's a more-general way that can support this, as well as other useful things (e.g. by providing more template variables to the redirect template), that makes it a more attractive proposition.

In particular, I want to avoid adding extra complexity to mike unless it's a very high-impact change, since this project is already significantly more complex than I had originally intended.