Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Optional externalize site config #3090

Closed
bep opened this issue Feb 23, 2017 · 5 comments
Closed

proposal: Optional externalize site config #3090

bep opened this issue Feb 23, 2017 · 5 comments

Comments

@bep
Copy link
Member

bep commented Feb 23, 2017

This relates to #3088 -- re. @digitalcraftsman comment:

This proposal defines the authors in the config file instead of using data files as in #1850 . What advantages do you see here? I would rather try to keep the config file flat.

So author configuration is site configuration, but because it may potentially be lots of them, we should put them in some special place.

Sure, site params must be configured in config.toml ... Oh, expect author params, which must be put in files below /data in a special folder starting with double dash ...

I suggest rather that we make this a general thing:

Site config belongs in config.toml and cousins, but it can optionally be put in files below /data/_config/. Keys in config.toml will always win.

@digitalcraftsman this one is open for discussion.

@digitalcraftsman
Copy link
Member

I like this generic and flexible approach - it's optional can be done as you like. Putting thinks like author profiles, menu definitions etc. in different data files can definitely improve the maintenance of a large config file.

But how do you distinguish between data/_config/language/en.toml and data/_config/language.en.toml?

@bep
Copy link
Member Author

bep commented Feb 24, 2017

But how do you distinguish between data/_config/language/en.toml and data/_config/language.en.toml?

The last one does not make sense the way we parse data files. It will be an object with key "language.en".

But in general, we have a "last key will win" approach (with warning or error logging on duplicates).

I have not analyzed every corner of this proposal, but I think it should be doable.

@bep
Copy link
Member Author

bep commented Feb 24, 2017

Also note that all of the site config that we, for some reason, put in external data files, will have to logically follow the same life cycle as the site config (think live reload), so making it "one thing" makes sense.

@stale
Copy link

stale bot commented Dec 6, 2017

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.

@stale stale bot added the Stale label Dec 6, 2017
@stale stale bot closed this as completed Dec 27, 2017
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants