I read in the description that the devs behind Hugo would like to know the popularity of Hugo based on a special meta tag as described in the docs:
.Hugo.Generator Meta tag for the version of Hugo that generated the site. Highly recommended to be included by default in all theme headers so we can start to track Hugo usage and popularity. e.g.
I use it, so yes. Not widespread usage, but that will not happen until we force-feed that line into every theme …
Or we could just inject it into the html head dynamically on render. I know a few other tools do that. Is that too intrusive?
@spf13 the injection would be a nice approach since it takes time until every theme implements the meta tag and theme users need to update too.
Intrusive? Maybe, but you could add a boolean field in the configs. But the question is still, what the default setting is. Either it’s opt-in or opt-out.
Chiming in, I don’t think it’s intrusive. I enable it in my sites because it’s only right. Some thoughts, probably obvious:
- it’s a small price to pay, to advertise the project - it’s only fair, and you can always get your money back (oh wait)
- some projects have you pay to “white box”
- it should be “inject but allow opt out”
- if a particularly OCD user already has it positioned how they like it in the
<head> don’t mess with the position :-}
- if it’s already in the
<head> don’t inject another
- if opting out, you could make Hugo kind of jokingly complain in the
hugo server log.
What! I see your opting out of plugging me. That’s ok, but I’m calling your Siri.
But hopefully way more humorous than that.
Maybe it would be better to say “We considered this, but as it would add 32 nanoseconds to the build time, we rejected the idea.”
I think it should be injected with the ability to opt-out.
You need to be aware that putting the generator in a meta tag is perceived as a clear security violation by many people because it allows potential attackers to exploit known weaknesses in the site structure (i.e., they no longer have to attack 100 possible avenues; by telling them how the site is generated, you let them focus on a single attack vector). In addition, a lot of website builders do not want to show their dependencies. For example, if you’re a web developer, you might want to let people think that you hand-tooled all the HTML.
On a personal basis, I’ve tried using .Hugo.Generator but it merely returns an empty string on my system (OS X) so it’s not much use.
Being a static site generator, the only vulnerabilities are in the way content is served. Basically, this would just advertise that the site is (99%) unbreakable so the exploiter would just move on.
@gecampbell that is a weakness of some dynamic CMS systems but I don’t see the issue with HTML. They have to be in the server anyway to do any harm ( and anything else like a PHP form or JS comments would be non-Hugo anyway) so it I don’t think it would make a difference.
In my opinion, the key thing is to make it clear this was being injected so people aren’t surprised and get suspicious. I know that sounds dramatic, but I think any issues with it will be like that. Info that it happens and an opt out seems fair.
One other idea. Is there a way to do it so it is less obvious what generated the site, or even that it was generated? I am thinking about devs with clients who may not understand what it means, they might think it means it’s from one of those online site builders. Just a thought.
Did someone already created some statistics about it?
News: Wappalyzer Chrome addon which detects technologies behind websites now correctly recognizes Hugo generator tag:
What’s best, CMS icon overtakes all other icons and it is visible with menu off!
Wappalyzer should be able to provide statistics once there’s enough data gathered from everybody who has plugin installed. This will be the report page (not activated yet): https://wappalyzer.com/applications/hugo
Thank you for sharing this tool. It will be interesting to see usage statistics of Hugo in the wild.