This looks like it's by design but I'm curious as to why the internal open graph template only outputs if "series" is specified.
<!-- Open Graph -->
{{- if isset .Site.Taxonomies "series" }}
{{- if not (eq (len .Site.Taxonomies.series) 0) -}}
{{ template "_internal/opengraph.html" . }}
{{- end -}}
{{- end }}
@Xen-Echo The reason I checked the series before loading the Open Graph, is because it must be set or else the template fails. The documentation talks about the usage of the series parameter but does not mention it specifically. One downside of using taxonomies is that you would have to set all of them (tags and categories as well) through the config.toml, or else they wouldn't show up (see issue #151).
Please let me know if you need further explanation or have a better idea.
Cheers @lxndrblz, I have the following config locally and it seems to work if I move the "_internal/opengraph.html" template outside of the conditional. Maybe it's fixed in the core project now:
[taxonomies]
category = "categories"
tag = "tags"
Edit: Also seems to work if I remove the entire taxonomies block, but I'm pretty sure hugo defaults to the above.
@Xen-Echo Thanks for your feedback. I will need to check if issue #151 would come back.
Ignore that last one I missed, the extra bit about the multi-language.
The "series" taxonomy "should" only be needed to specify the see also open graph meta. According to the docs at least:
The series taxonomy is used to specify related “see also” pages by placing them in the same series.
Here's the actual internal template: https://github.com/gohugoio/hugo/blob/master/tpl/tplimpl/embedded/templates/opengraph.html
Testing locally the open graph template only fails to render if you have pages with "series" front matter and haven't also specified the corresponding "series" taxonomy. I personally don't think this should stop the open graph template rendering though as you lose the basic open graph fields like image etc. when you copy a page link somewhere that supports rich URLs.
The only "good" potential fix ideas I have are:
@Xen-Echo Thanks for pointing out our options and doing a bit more research. I will review these and do some more digging as soon as I have a little bit more time.