Add [param] section to modules config.toml

tips & tricks
,
1

I would like to add [params] to a module that contains shortcodes. Those shortcodes might need configuration for hosts or design elements. Right now this is not possible (I tested to add a [param] section to the modules config section and added there are namespaced parameter. Using it with a default in the template that uses that module resulted in the default to be echoed, so I assume it’s not possible).

I solve this currently by adding defaults to my shortcodes like the following:

{{ $disabled := $.Param "dnb.shortcodes.youtube.disabled" | default false }}

and add a note to the README.md that the shortcode can be configured by

[params.dnb.shortcodes.youtube]
disabled  = false

That works, but requires some more “use of brain” by the user and the developer of the module. Also overriding modules accidentally by having the same namespace name is easier.

Would it be possible to add a new [param] section to module config.toml that is available further down the line for instance by forcing the modulename in the resulting parameter?

Sample:

Modulename: username/modulename

config.toml in the module:

[params]
parameter1 = "something"

Results in the the following echoing “something”:

{{ $.Param "username.modulename.parameter1" }}
2

I had the same concern some months ago and if (if) i remember well, it was not possible, due (?) to the way params are merged thru the arbo.

[EDIT] This is what i talk about : "params" from config.toml in component seems not being merged

My only solution was to have my own namespace, and a README if people wants to override it.

You can have a look at https://github.com/divinerites/plausible-hugo and see how this works for me.

You can even have a partial for checking if all is correct (see plausible_check.html)

But when you add some [params.yournamespace.xxx], those [params.yournamespace] and al. in your theme are no more available. So you have to give them again (the default option is really helpfull tho in this case)

3

hmmm… I was thinking along the lines of namespaces, but I somehow expected, that I could work with one global namespace (dnb) for all my products and then a lower level namespace (shortcodes) for the module I am using. So probably in my testing the param.dnb.shortcodes was ignored, because i have a param.dnb.somethingelse in my global config.

I’ll test again if double brackets (aka “tables”) change anything… well, in the end param.dnb-shortcodes is ok too I guess.

4

Yes. For sure.

5

Ok, so I have looked over your module and the recent post and that is basically how I implemented it now, with a one-dimensional namespace, let’s call it that.

The problems (more or less not “real world” problems, but wannahaves or itwouldbenices) I am still having are two:

  1. (and I know Bep’s answer to this) is, that in an ideal world my module would define 10 parameters under it’s namespace and the user want to just change one single parameter. That one single parameter should overwrite it’s counterpart in the config below (from the theme or module used by the theme)

  2. I have many websites made with hugo and want to reuse module(s) because why re-inventing the wheel if it rolls the first time. So I really think that some kind of “level”-control should be possible. If I use params.dnb. for everything and then subsequent sublevels, I would not want to break each other if used concurrently. It makes sense to have many namespaces, but they tend to be long. Having for instance params.dnb as “everything done by davidsneighbour” and then subsequent “lokal” namespaces, maybe by defining something like paramnamespaces = ["dnb", "someothernamespace"] (on the other side, that again is work for the end-user).

So in the end… maybe it’s all just how you use it - one proper namespace per module. But let’s filter out one “side-idea” I had: How about giving a module a way to define a slug moduleslug = dnb (or path (moduleslug = "dnb.shortcodes")) in the config of the module (or done automatically by using the modules name) that is used inside of Hugo's params section as params.dnb.shortcodes.somethingelse` for further configuration? That’s a question for people understanding Hugos Go code. I tried diving into the config module this week and apart from that the config of modules is something different of the “normal” config I did not understand much. humbled.

6

Approaching from a different angle:

You could leverage /data/ files for really complex configurations. This way, you can split your params into multiple files instead of one main config: https://gohugo.io/templates/data-templates/#data-files-in-themes

So you would have:

data
└── _mymoduleparams
    ├── styles
    │   ├── typography.toml
    │   └── colours.toml
    └── options
        ├── one.toml
        └── two.toml
...

Then your user can customise one specific params sub-group while inheriting all others that are untouched.

3 Likes
7

That sounds perfect. And it removes everything that the end-user would have hassle with (like [params] headers and sorting of parameters). It might be exactly what I need, including all the overriding and segmentation features that I might require. I will sleep over it and test it out.

8

(I moved this into Tipps and Tricks instead of Feature section. sounds like the data-solution is what solves all wants/nicetohaves of mine)

9

This is clever. Using data for under the hood and params for the user stuff.
It is so obvious now :slight_smile: Thanks.

1 Like
10

Sorry for the off-topic question, but how do you generate the symbols (└,─,│) for the file structure? The hugo docs are filled with them. Do they do them by hand?

11

I don’t know about the docs, but I use tree on the command line on either an actual directory, or a similarly structured directory.

2 Likes
12

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.