.Site vs $.Site vs site

support
1

What about $.Site? Isn’t that also supposed to work? I find, though, that it only works in certain places.

2

I recommend you use site instead to avoid context issues.

3

If the current context[1] is a Page, you can use .Site.

If the current context is not a Page and the template context[2] is a Page, you can use $.Site. The $ gets you to the template context.

If neither the current context nor the template context include a Page, use the global site function. For example, inside of a partial that receives a slice of integers.

https://gohugo.io/templates/introduction/

  1. The value of the dot at any point in the template. It is equivalent to the template context unless it is rebinded via a with or range statement. ↩︎

  2. The value of the dot at the top of the template, representing the context passed into the template. ↩︎

4

Thanks.

It sounds like $.Site and .Site can always be considered as bugs or bugs-in-waiting. They can be safely replaced with the site function.

Is there a legitimate reason to ever use either of those two instead of site? At the least, it sounds like site should be considered best practice. And only use the others if there’s a very good reason.

5

https://gohugo.io/functions/global/site/

image

Sure. If you’re ranging through .Page.AllTranslations or Page.Translations and want the Site object associated with language.

1 Like
6

Interesting. So there’s no single global site when there are translations. Each translation is considered a different site.

7

Correct. One site per language. See also .Site.Sites in the docs.

1 Like
8

Thanks. I found the text on site | Hugo to give conflicting advice. I submitted a PR to resolve the conflicting info.

9

Re: your PR…

“the current site” … that depends on what you mean by the current site.

10

I see. That entire paragraph and example code can also just be deleted. There’s the callout below that advises to prefer site.

11

Yeah, I’ll think on it a bit. Thanks for the PR.

1 Like