Is my disableHugoGeneratorInject config overridden by Congo?

[venteto]

What happened?

I have disableHugoGeneratorInject = true present in my config/_default/config.toml folder and yet the generator meta tag is still inserted both locally and in production.

Theme version

v2.1.1

Hugo version

v0.96.0+extended linux/amd64

What browsers are you seeing the problem on?

Firefox

Relevant Hugo log output

No response

[jpanther]

From what I understand, the config parameter you are referring to controls the behaviour when the generator meta tag isn't present at build time. Congo includes the Hugo generator variable in the theme by default and so it will always be present at build time.

Is there a particular reason why you don't want the generator tag in the page?

[venteto]

I personally don't feel it is anyone's business what I am using to generate the site, and I don't volunteer unnecessary data, even to various crawlers.

If you wanted to persuade people to use this item, couldn't you just handle it explicitly, via settings, rather than hardcode it into a layout partial and force people to use it? I mean having disableHugoGeneratorInject = false in the exampleSite/config/_default/config.toml makes it more discoverable and would be less pushy.

I mean I love this theme, but I've already had to use my own head partial† to override your own opinion on Google Analytics (as well as to have it load earlier than even Hugo's own GA template); to me, allowing people their own opinions, via inserting your own suggestions in config settings, seems more friendly than making people override partials to do basic things.

† I'd prefer not to be using custom layouts when I go to upgrade Congo to pull in your latest updates, at least not for this kind of basic stuff.

[jpanther]

I understand where you're coming from but a few points on this:

• disableHugoGeneratorInject is a fallback that's built-in to Hugo and not an option that is exposed to theme developers to be able to build logic upon - that means it isn't more discoverable.
• There's nothing pushy about this at all. You're acting like there's some sort of sinister intent behind the generator tag. It is included in many, many themes and is preferred to be included by the author of Hugo. It is a way of giving thanks for their contributions to the open source software you are choosing to use.
• That aside, if you still don't want this behaviour, you can set attribution = false in your theme configuration. It will remove all references to Congo and Hugo. I would prefer you didn't do this, as just like the Hugo contributors, I believe the hundreds of hours I've spent developing this theme deserve some sort of credit, but the option is there nonetheless.

I do want to understand more about your comments around analytics though... Can you please explain what you mean by "your own opinion on Google Analytics" because the theme is using Hugo's built-in GA template. There's no custom GA code in the theme at all and the analytics block is in its own partial for exactly the flexibility you are asking for - so you can override it without affecting anything else in the theme.

I strive to make Congo as flexible as possible and a key design intent is allowing it to be overridden in such a way that upgrades are straightforward. I hate it when I get bogged down in custom layouts that prevent upgrades and I don't want users of my theme to have this experience either. If you can explain what exactly it is you are overriding that is requiring a custom head.html partial I'm more than willing to see if there are adjustments that can be built-in to the theme to reduce this friction.

[venteto]

Generator and robots.txt

I'm not implying there is any sinister about attribution at all. I hate the BuiltWith site because it ignores my custom robots.txt directives, the very directives their own site docs say to use if you want their crawler to ignore your site. It's mainly their rogue crawler I wish to thwart in not volunteering any data I don't have to volunteer (I don't know if it will scrape the visible human-readable footer or not).

As an aside, if I follow the Congo docs and have enableRobotsTXT = false in my config (which is the opposite of what I've always done), my own custom robots.txt file in layouts doesn't seem to get included, so I reverted to setting this to true.

I went back to search your documentation site again to see if I overlooked attribution = false, but using both your onsite search feature, and in limiting Google to search only your domain, I still can't find this. I hate to think I overlooked it but thusfar I cannot find it. Nevertheless, in trying to test it in params.toml I see it does remove the visible stuff in the footer, but doesn't seem to affect the <meta name="generator" ... /> tag injected into the source. So it looks like I would still need to create a custom <head> partial to truly get rid of the generator tag?

I've never attempted to hide Congo attribution from the footer, nor wanted to because thusfar it's been the nicest theme I've found. I would be tempted to ask you to split attribution up into discreet Congo footer attribution and 1 or 2 additional discreet parameters for Hugo in the footer and in the <meta> tag.

Google Analytics

I didn't realize you include the Hugo internal GA template. I didn't dig through your templates deep enough to see because I skimmed this elsewhere in your writings (via your exampleSite when I test it locally), and based solely on that I assumed it would not be included. That external link sample in your exampleSite is where my flawed allusion to your "opinion" on GA comes from.

I see now that you do include the GA template. It's still loading further down in the source than what I had always read was desirable, in order for GA to not miss recording any visits. Maybe I am mistaken, but I thought I'd always read that Google advises placing the GA immediately after the opening <head> tag to ensure that you don't miss any visits. I will revisit this to see if it's still a best practice, and if it's not, I will use the built-in GA template as it is.

Being Able To Test Production Settings Locally (Without Deploying)

I was also going to test using the normal googleAnalytics config setting just to verify how far down in the source it would load on my site, but I soon found I couldn't do this. Normally I would do something like ...

hugo server -p 1314 -e production

... because in my <head> partial I typically have something like this ...

{{ if hugo.IsProduction }} GA stuff {{ end }}

... but in your layouts I see you instead have ...

{{ if not .Site.IsServer }} analytics stuff {{ end }}

I also minify the site using a config/production/config.toml file so I'm used to double-checking that that works on my laptop before actually deploying to the host.

Is there any particular reason you did it the way you do, which seems to prevent me testing locally?

[jpanther]

As an aside, if I follow the Congo docs and have enableRobotsTXT = false in my config (which is the opposite of what I've always done), my own custom robots.txt file in layouts doesn't seem to get included, so I reverted to setting this to true.

I think this is probably because the docs aren't as clear as they could be. When I say set the param to false to include your own file, I mean if you wanted to include your own robots.txt in the static directory. If you want to provide your own template in the layouts directory, you will need to keep this param set to true. I'll adjust the docs to better explain this.

I went back to search your documentation site again to see if I overlooked attribution = false, but using both your onsite search feature, and in limiting Google to search only your domain, I still can't find this.

This feature is intentionally undocumented.

I see now that you do include the GA template. It's still loading further down in the source than what I had always read was desirable, in order for GA to not miss recording any visits.

I'm not entirely sure why they would suggest placing it so high up the page when modern best practices suggest deferring scripts to later in the load cycle. Deferring these as much as possible helps considerably with performance. Perhaps it's something to do with not missing out if people navigate away from the page too soon but I'm not sure counting them adds any benefit anyway. I'm not a GA user as I don't believe it promotes good privacy practices but if you have any documentation on this, I'm happy to review it.

Is there any particular reason you did it the way you do, which seems to prevent me testing locally?

I can't remember why I did it this way... It may have been to avoid having to rely on whether the environment is being set correctly. From doing some more reading on this it looks like hugo sets these parameters automatically based upon how the command is invoked so it is probably a non-issue to change it to use hugo.IsProduction.

[jpanther]

I should have mentioned too - I suspect that by including attribution = false you are now under the control of the default Hugo behaviour. That is, it will automatically include the generator tag unless you additionally specify the disableHugoGeneratorInject parameter. You will probably have to specify both in order to completely remove it from your generated site.

[baalajimaestro]

I would also love the control of the generator through a switch. Specifically when I keep my site not updated for quite a while, I would prefer it say generator : Hugo rather than generator : Hugo 0.96.0. If i have not updated for quite a while, this makes it very evident to the threat actor on the exact version, and makes things much easy for them to attack.

I see this just like the server_tokens in nginx. Where disabling it makes it show as nginx without any version.

Even if removal to the level of just generator is not possible, i would prefer removing it all together rather than having it and causing a mishap later on

I would preferably not use attribution = false and go about this, since i would like to add that as way of respecting the amount of work in creating and maintain this awesome theme

[jpanther]

I would also love the control of the generator through a switch.

Is a switch the best solution to this though? You are saying you'd be happy to switch off the generator tag but still keep the "Hugo" in the site footer?

I would prefer it say generator : Hugo rather than generator : Hugo 0.96.0

This is one you should raise with the Hugo team. The generator tag is created using a Hugo variable and so it's not possible to override it without the version. The only way around this would be hard-coding it and then you'd come up against the auto-inserting default behaviour of Hugo and likely end up with the version number anyway.

What is the solution?

I want to find a way to solve this that can keep everyone happy. I'd be interested in opinions on this... perhaps a cleaner solution is to move the generator logic into its own partial and that way it can be overridden it however the site owner sees fit. If you don't want it at all, simply override it with nothing, or customise it to include as much or as little as you like.

[venteto]

Thank you for updating the robots.txt docs and using hugo.IsProduction.

---

I suspect that by including attribution = false you are now under the control of the default Hugo behaviour. That is, it will automatically include the generator tag unless you additionally specify the disableHugoGeneratorInject parameter. You will probably have to specify both in order to completely remove it from your generated site.

I have both of those set and yet I still see it generated in the source, in both the development environment locally, as well as after pushing to the host and no longer using hugo server commands.

---

As far as the issue brought up by @baalajimaestro, for people who just want a simple toggle switch, without heavily customizing partials, again I would mention my proposal of possibly breaking up ...

attribution = false

... into ...

attributionFooter = false
attributionSource = false

... with the respective modifications to the layouts looking for those now separate parameters.

I no longer see much point in going beyond that, to this idea, though ...

attributionCongoFooter = false
attributionHugoFooter = false
attributionHugoSource = false

... since reading "Congo" on the footer would pretty much give away that it's a Hugo-based site.

As you suggested, I agree that also moving the generator logic to its own partial would be a nice touch (regardless if a user opts to use the toggle switch paramter or do some sort of unique customization to the partial).

[jpanther]

I have both of those set and yet I still see it generated in the source, in both the development environment locally, as well as after pushing to the host and no longer using hugo server commands.

I'm not seeing this behaviour. Are you setting attribution in the theme params and then disableHugoGeneratorInject in the Hugo config? They have to go into different config files for it to work. This is one of the reasons I don't think having these params is a clean way to solve this problem.

I think the change I'm going to make is to simply remove the generator tag from the theme altogether. The default Hugo behaviour works in essentially the same way and then if you want to disable it, the Hugo config param will work in accordance with the standard Hugo docs.