Config: is `services.googleAnalytics.id` an alias for `googleAnalytics`?

I don’t see a section on services under Configure Hugo | Hugo and yet it seems that adding the following to my project’s Docsy-based config.toml

[services.googleAnalytics]
id = "UA-00000000-0"

has the same effect as adding a top-level googleAnalytics param like this:

googleAnalytics = "UA-00000000-0"

That is, in either case, the ID’s value is accessible via .Site.GoogleAnalytics.

So my questions are:

  • Are services.googleAnalytics.id and googleAnalytics config aliases?
  • Where are services config details documented?
  • Which other params can I define under services.googleAnalytics?

Maybe services.googleAnalytics is historical and has been superseded by a top-level param? It seems to show up in some tests: Search · services.googleAnalytics · GitHub

Thanks!

For context, I stumbled on this behavior while investigating the following issue:

https://github.com/gohugoio/hugo/blob/master/config/services/servicesConfig.go#L83-L87

If it can’t find services.googleAnalytics.id it falls back to googleAnalytics (in the root) to provide backwards compatibility for a change that was made 4 years ago.

The only documentation reference that I could find to the services configuration key is:
https://gohugo.io/about/hugo-and-gdpr/

1 Like

Thanks @jmooring. Just to be clear: which parameter should be considered the new canonical one?

services.googleAnalytics.id

Oh! So, in your opinion, should the docs be updated to say, for example, that the top-level googleAnalytics param is:

  • Deprecated in favor of services.googleAnalytics.id (while adding a section about the new services parameters)?
  • Or at least mention that it is a shorthand?
  • Warning to not set both (otherwise strange behavior can result)?

I’d be glad to open an issue to that effect if you think it would be helpful.

1 Like

Yes, please create an issue in the docs repository. We should fully document the services key, and note the preferred way to configure the Google Analytics ID, the Disqus Shortname, and the RSS limit.

I’m not sure I would use the term deprecated, because programmatically the root settings have not been deprecated—that’s a separate issue that would affect a lot of sites and themes.

I also wouldn’t describe the root settings as shorthand—the values are stored separately.

2 Likes

Done. I’ve created two issues because I think that it will be better to address them separately:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.