Split between site.Config and site.Params

support
1

Hello everyone,

I’m currently encountering an issue with the following Hugo error:

execute of template failed: template: partials/head/analytics.html:6:64: executing “partials/head/analytics.html” at : can’t evaluate field AnonymizeIp in type privacy.GoogleAnalytics.

This happens when I attempt to add the following configuration:

privacy:
  googleAnalytics:
    disable: false
    respectDoNotTrack: true
    anonymizeIP: true

If I move the anonymizeIP parameter to another section, like so:

privacy:
  googleAnalytics:
    disable: false
    respectDoNotTrack: true

params:
  privacy:
    googleAnalytics:
      anonymizeIP: true

the error disappears, and everything works as expected.

However, I’m not satisfied with this solution because it results in a fragmented configuration structure, where similar settings are scattered across different places:

  • site.Config.Privacy.GoogleAnalytics.RespectDoNotTrack
  • site.Params.Privacy.GoogleAnalytics.AnonymizeIP

Additionally, the situation becomes even more confusing when your configuration is split across multiple files. For example, in my case, some Google Analytics settings are in config.yaml, while others are in params.yaml.

And this is just one example, but I’ve also encountered a similar issue when trying to add configuration for Google Tag Manager, which results in:

  • Some settings for Google Analytics in site.Config
  • Other settings for Google Analytics in site.Params
  • All settings for Google Tag Manager (which logically should be similar) in site.Params

This structure feels confusing and inconsistent. I’m wondering if there is a cleaner way to manage such configurations to maintain a more organized and centralized setup.

Has anyone else run into this issue? Any suggestions would be appreciated.

2

The error you get has nothing to do with how you configure things.

We deprecated and removed the AnonymizeIp field at some point (it’s no longer relevant in GA >= v4).

So the fix needs to be applied in partials/head/analytics.html.

1 Like
3

A related tip would be to use the Hugo built-in template for this:

4

Thank you for clarifying. However, my main concern isn’t specifically about this particular parameter or its relevance. What bothers me more is that the configuration for a single service is spread across two separate sections — and, in my case, across two different files, since I maintain configuration in separate files.

As mentioned in my example above, the configuration for Google Tag Manager only works in site.Params. For instance, I’m literally using site.Params.Privacy.GoogleTagManager.Disable to control its state, while other services like Google Analytics are managed through site.Config.Privacy.<service>.Disable.

Even if I wanted to add new settings to Google Analytics, I would be forced to place this configuration separately, at site.Params, not site.Config, which feels messy and inconsistent to me. Maybe I’m being a bit too nitpicky, but I think a cleaner solution would make the configuration more intuitive.

5

What you you ask for isn’t … intuitive for me.

We have 1 and only 1 site config, defined in hugo.toml*:

  • User defined configuration is defined below params
  • Hugo defined configuration is defined either as top level config options (e.g. baseURL) or in config sections (e.g. build).

So when you say site.Params.Privacy.GoogleTagManager.Disable, I have no idea what you mean. That’s not a thing. privacy is one of the Hugo config sections, see

  • Or config.toml (to keep backwards compability) or in a /config folder.
6

Well, this is exactly what I was trying to understand. It seems that if I want to extend the configuration for Google Analytics, it will end up in two different places — some settings at the root, accessible via site.Config, and others under params, accessible via site.Params.

We have 1 and only 1 site config, defined in hugo.toml.

I’m not quite sure what you mean by that, since Hugo allows using multiple files like config/_default/config.{toml,yaml} and config/_default/params.{toml,yaml}, which doesn’t really look like “1 and only 1 site config” to me. I understand that they are merged into a single configuration internally, but physically they are still in different locations and even in separate files. Please correct me if I’m misunderstanding something.

Overall, my question is more about design than a technical problem. As I mentioned earlier, I was able to make it work. I just find it counterintuitive to have, say:

  • site.Config.Privacy.GoogleAnalytics.RespectDoNotTrack
  • site.Params.Privacy.GoogleAnalytics.SomeCustomSetting

In my opinion, having the configuration for the same entity split between two places (and in my case, also across two different files) looks messy and inconsistent.

But it seems that this is how this design is intended to work, so I appreciate your explanation. Thank you for helping me understand it better.

7

It is not really that complicated. To use an example, when I recently began testing Hugo and Jekyll for a multilingual project, I wondered why description was a default config in Jekyll, but user defined in Hugo (under Params). So {{ site.description }} in Jekyll became {{ site.Params.description }} in Hugo. But this statement clarifies it for me now. :point_down:

I would assume that’s because Google Tag manager is a user defined configuration. If you need to use the built-in config, you would need to override the inbuilt templates.

You are!

1 Like
8

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