I want to use a static site generator to have full control over the output, and after reading about Hugo and trying it out, I fell in love. However, one design decision bothers me, and I wonder if it’s already intended to change it in the future, or if not, what you do think about changing it.
By default, Hugo automatically creates a feed and a sitemap.
I think it should not do that, because:
Not every site needs a feed and/or a sitemap.
Not everyone wants to use the default file names for these.
Not everyone wants to use the default markup for these.
Not everyone wants to use the default file types (there are various feed and sitemap formats).
And most importantly, I think Hugo should not be “clever” and create something I don’t explicitly want to have.
Instead I’d prefer a way to add these manually if needed. Just let me create a template, which gives me 100% control over the markup. I’m not sure if it’s already possible, but for that purpose, Hugo should allow creating different file types than just HTML (namely XML, maybe plain text, etc.).
For users that don’t want to dig into creating these (XML) files, Hugo could come with default templates for a feed and a sitemap, which would allow deleting (if you don’t need them at all) or editing them easily.
The goal of Hugo as I’m aware is to fit the needs of 80% of use cases out of the box, while allowing the flexibility to overwrite defaults where needed. There are very few sites who shouldn’t be providing an XML sitemap & RSS feeds, so I agree with the defaults. The templates are easy to overwrite as laid out in the documentation - http://gohugo.io/templates/sitemap/, http://gohugo.io/templates/rss/.
You can also set DisableRSS and DisableSitemap in config.toml (or whatever format you chose).
I disagree with you that every site “does not need a sitemap”; this is considered a best practice by Google, and I see no downside to providing a sitemap.
@DerekPerkins: Yes, I agree that it’s a sensible default, and that’s why I proposed to provide (and ship with) a “real” default template for these two files, instead of creating these files internally and allow overwriting them.
One problem with the current approach is, for example, that Hugo enforces file names for them; so the sitemap is automatically called sitemap.xml.
Another problem is that you can’t provide several sitemaps (with different entries) this way (linking them via sitemap index file).
@halostatue: Ah, thanks, I wasn’t aware of these config settings. So this a good solution for sites that don’t want a feed and/or sitemap.
In light of DisableRSS and DisableSitemap, my feature request would then become: Allow to create non-HTML files with Hugo templates (i.e., XML, plain text), for example for enabling to (re)create a sitemap/feed. – I’ll research if there are already similar proposals for Hugo.
As I understand it, and I could be wrong, DisableRSS either turns feed generation off for everything or on for everything.
What I would find useful is if DisableRSS could be reconfigured so that it only disabled use of the internal template not the generation of feeds altogether. If a real template was provided for a particular section then an RSS feed would still be created even if DisableRSS was set to true.
If DisableRSS = true and no templates are provided no feeds will be created.
If DisableRSS = true and a blog template is provided a blog feed will be created.
If DisableRSS = false it would operate exactly as it currently does.
I think that would need to be handled differently. I would deprecate DisableRSS and DisableSitemap and replace them with something like Generate.RSS and Generate.Sitemap (other options to be added later) with possible values of: true (the default), false, or external. We could use different names if preferred (always, never, external suggest themselves).
true/always would generate RSS/Sitemap from either external or internal templates. This would be the default behaviour (as it is now).
false/never would work the same as the current disable flags.
external would only generate if there are external templates.
In general, I prefer explicit configuration rather than multiple-value inferred configuration, but I also want the behaviour to make sense by default.