Hugo: Provide default values for .Site.Params used in a theme

[chipsenkbeil]

Is there a way to do this with the current setup? I am creating a theme where colors are injected from associated variable values. I'd like to be able to assume that there is always a value for a configuration (in same vein as Typesafe Config), rather than hard-coding a value every time I access the variable. If there is a best practice for doing this, please let me know!

[bep]

No, but it should be.

[chipsenkbeil]

@bep, did you have any thoughts on how you would do this? My thoughts were that you could either:

1. Make use of theme.toml to place any default values (downside is that some variables are already in use within theme.toml)
2. Add a config.toml in the theme's root directory that contains default values
3. Add a default.toml in the theme's root directory that contains default values

Any default value could be overridden in the user's config.toml (or other accepted file type).

E.g.
someTheme/defaults.toml

[Params]
    name = "Some default"
    color = "#FFF"

    [Params.Extra]
        size = "30px"

someSiteUsingTheme/config.toml

[Params]
    name = "Some user name"

    [Params.Extra]
        size = "45px"

Results in Params.name being _"Some user name"_, Params.color being _"#FFF"_, and Params.Extra.size being _"45px"_.

[bep]

I think config.toml etc. wold be in line with how the other theme overrides work, but there are issues here to consider, file paths etc. we maybe not that keen on setting. So maybe restrict it to custom params? @spf13

[spf13]

I like this idea. In the back of my mind I thought we would have this as a feature. I just didn't want to do too much with themes until we had a solid base and better understanding of how they would be used.

I'm ok with config.toml (or even a different format). One issue has been that Viper didn't have support for loading multiple config files with overriding. I believe that feature has just been added via PR and should be merged soon.

It still leaves a lot of questions about what config parameters can be defined & overridden and how to manage all of that without adding a lot of complexity to the code. These are the reasons I've punted on this.

[bep]

I think what will cover 99.9 percent of the use cases and doesn't require too much thinking is this:

If the theme in use has got a config.toml or config.yaml or config.json then the Params map, if present, and only the Params map, will be read before the site's own configuration.

[chipsenkbeil]

@bep, I think that would cover most of the use cases, although would there be any concern about the clarity of what could and could not be specified? Or should it be assumed that theme writers would have closely read the documentation and understand the limitation?

[bep]

@rcsenkbeil the thing is, theme authors will have to abide to some kind of specification in this matter (making all the params availabe is no go). Compare these two for clarity:

Theme authors can set default values for Params in config.toml

And:

Theme authors can set default values for Params, defaultextension, defaultlayout, footnoteanchorprefix, footnotereturnlinkcontents, languagecode, paginate, paginatepath,pluralizelisttitles, pygmentscodefences, pygmentsstyle, pygmentsuseclasses in config.toml

[chipsenkbeil]

@bep, makes sense. Obviously, I'm happy just to have defaults for Params.

[digitalcraftsman]

Theme creators could use data files to provide default values if they are not set in the config file, e.g.

{{ .Site.Params.color | default .Site.Data.default.color }}

In this case the default values are defined in data/default.{toml, json, yaml}

[bep]

@digitalcraftsman that is a great current workaround. But I think this issue has its own merits:

• It would make it symmetrical and intuitive to have the overrides in the params section of the theme's config.toml (or whatever)
• It would also be a good place to document the theme config (a template)

[bep]

This issue has been automatically marked as stale because it has not been commented on for at least six months.

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.