Open imsus opened 6 years ago
There is a couple of problems with this approach:
1) Keeping it up-to-date and correct (it is not correct as presented, source
isn't a config option). Which requires some kind of test harness. Not sure what.
2) Getting the defaults correct (watch = true doesn't make sense)
3) Hugo is all about sensible defaults. Me, personally, want as small a config as possible, so I don't set hasCJKLanguage: false
because 1) It's not relevant and 2) The default is correct.
We should improve in this area, but I'm not sure this is it. If I, as a new Hugoer, got this config in my face, I would have thought that Hugo was some really complex thing for developers only. And that is not the common case.
I agree with you with that.
Some Idea from me:
I just really like the way that Laravel handle their config. If you have time please take a look. https://github.com/laravel/laravel/blob/master/config/app.php
Here is my take on it:
We already have some "test helper generator" from code. And we have one place in the code where we set all the defaults.
So what we can do is to add some metadata there which can be used when
1) Generating the JSON for the documentation.
2) Generating the TOML config when doing hugo new site
.
The metadata should be:
The config created with hugo new site
should then have:
1) All the core config settings with default values + a comment with the description (if the config format supports it) 2) A comment section with all the other settings with a note that "this section can be safely deleted" or something.
That file should also be part of a automatic integration test.
Hi Sorry for jumping in (Let me know if you feel opening a new issue about it will serve better).
When trying to use different themes I found out that most of them will utilise just part of the settings (and will add of their own).
I think that while generating this config.toml it will make sense to have a different secondary theme-config.toml
This will allow to use different themes on the same website (not realy possible today) for A/B testing for example...
What do you think?
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master
branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
[params]
description = "add your sites description here"
index.html
file before you add all of this in the config file, as most paramaters aren't useful unless you know how to use themhugo server
and just hugo
commands, if this is done well then #10024 can be fixed as well, this is an alternative idea to https://github.com/gohugoio/hugo/issues/4165#issuecomment-351984978My proposal is either to create a new file with hugo new site
that shows all the default (and/or most used) configuration options with comments for each entry or to create a command that the user can run to see these options.
Problem
When starting out a new site, we sometimes find the config does not explain directly. Instead we go to the docs and find out there. Even in the docs, some of the config keys are not documented yet. Leading to confusion.
In this issue, I propose a new format for default config file with Categorization and Explanation for each key.
Current
config.toml
file:Solution
In this case, I'm using
yaml
.Proposed default config file. If there is no comment on some key, then it means it's not documented on the docs.